RP 040046

Presentation of Specification to TSG RAN
Presentation to: TSG RAN Meeting # 23

Document for presentation: TR25.896, Version 2.0.0
Presented for: Approval
Abstract of document:
This document is a technical report titled 'Feasibility Study for Enhanced Uplink for UTRA FDD'
for the Release 6 study item “Uplink Enhancements for Dedicated Transport Channels"
Changes since last presentation to TSG RAN:

TR25.896 version 1.0.0 was presented for information for TSG RAN meeting #21. Since then the
TR has grown from 63 pages to 180 pages long. Among very many other things the conclusions
and recommendations chapter has been completed. More detailed descripton in [1].
Outstanding Issues:
No Outstanding Issues.
Contentious Issues:
No Contentious Issues.
References:
[1] RP-040021, Status Report for SI on Uplink Enhancements for Dedicated Transport Channels
3GPP TR 25.896 V2.0.0 (2004-03)
Technical Report
3rd Generation Partnership Project;

Technical Specification Group Radio Access Network;
Feasibility Study for Enhanced Uplink for UTRA FDD;
(Release 6)
The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification.
Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.
Release 6 2 3GPP TR 25.896 V2.0.0 (2004-03)
Keywords
UMTS, radio, packet mode, layer 1
3GPP
Postal address
3GPP support office address

650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Internet
http://www.3gpp.org
Copyright Notification
No part may be reproduced except as authorized by written permission.

The copyright and the foregoing restriction extend to reproduction in all media.
© 2003, 3GPP Organizational Partners (ARIB, CCSA, ETSI, T1, TTA, TTC).
All rights reserved.
3GPP
Release 6 3 3GPP TR 25.896 V2.0.0 (2004-03)
Contents
Foreword............................................................................................................................................................ 8
1 Scope ....................................................................................................................................................... 9
2 References ............................................................................................................................................... 9
3 Definitions, symbols and abbreviations................................................................................................. 10
4 Introduction ........................................................................................................................................... 10
5 Requirements ......................................................................................................................................... 10
6 Reference Techniques in Earlier 3GPP Releases .................................................................................. 11
6.1 DCH Setup Mechanisms ....................................................................................................................................... 11
6.1.1 Uplink/Downlink Synchronization .................................................................................................................. 12
6.2 Uplink TFCS Management with RRC Signalling ................................................................................................. 13
6.3 Transport Format Combination Selection in the UE ............................................................................................. 13
6.3.1 Description of TFC selection method.............................................................................................................. 13
6.3.2 TFC selection method as a reference case for Enhanced Uplink DCH ........................................................... 16
6.4 RNC controlled scheduling: DRAC and TFCS Restriction .................................................................................. 17
7 Overview of Techniques considered to support Enhanced Uplink........................................................ 17
7.1 Scheduling <NodeB controlled scheduling, AMC>.............................................................................................. 17
7.1.1 Node B Controlled Rate Scheduling by Fast TFCS Restriction Control ......................................................... 19
7.1.1.1 Purpose and General Assumptions .................................................................................................................. 19
7.1.1.2 General Principle ............................................................................................................................................. 19
7.1.1.3 Restricting the Allowed Uplink TFCs in a TFCS by L1 Signalling ................................................................ 20
7.1.1.4 Issues Requiring Further Studying .................................................................................................................. 20
7.1.1.5 Signalling to Support Fast TFCS Restriction Control ..................................................................................... 21
7.1.1.5.1 L1 signaling ............................................................................................................................................... 21
7.1.1.5.2 RRC signalling........................................................................................................................................... 21
7.1.1.5.3 Iub/Iur signalling........................................................................................................................................ 21
7.1.2 Method for Node B Controlled Time and Rate Scheduling............................................................................. 21
7.1.2.1 Purpose and General Assumptions ................................................................................................................. 21
7.1.2.2 General Principle ............................................................................................................................................ 21
7.1.2.3 Controlling UE TFCS and transmission time ................................................................................................. 22
7.1.2.4 Issues Requiring Further Study ...................................................................................................................... 23
7.1.2.5 Signalling to Support Fast Node-B Time and Rate Control ........................................................................... 23
7.1.2.5.1 L1 Signalling.............................................................................................................................................. 23
7.1.2.5.1.1 Uplink Signalling of Scheduling Information Update ............................................................................... 24
7.1.2.5.1.1.1 Explicit scheduling information update signaling ................................................................................ 24
7.1.2.5.1.1.2 Other ways of conveying scheduling information update to Node B................................................... 25
7.1.2.5.2 RRC Signalling (TBD).............................................................................................................................. 25
7.1.2.5.3 Iub/Iur Signalling (TBD) .......................................................................................................................... 25
7.1.3 Scheduling in Soft Handover........................................................................................................................... 25
7.1.4 Node B Controlled Rate Scheduling by Persistence Control........................................................................... 25
7.1.4.1 Issues Requiring Further Studying .................................................................................................................. 26
7.1.4.2 Signalling to Support Fast Rate Scheduling by Persistence Control ............................................................... 26
7.1.4.2.1 L1 signaling ............................................................................................................................................... 26
7.1.5 Brief Overview of Different Scheduling Strategies......................................................................................... 26
7.1.5.1 Node B Controlled Rate Scheduling by Fast TFCS Restriction Control ......................................................... 26
7.1.5.2 Node B Controlled Time and Rate Scheduling ............................................................................................... 26
7.2 Hybrid ARQ .......................................................................................................................................................... 26
7.2.1 General ............................................................................................................................................................ 26
7.2.2 Transport Channel Processing ......................................................................................................................... 27
7.2.3 Associated Signaling ....................................................................................................................................... 28
7.2.4 Operation in Soft Handover............................................................................................................................. 28
7.3 Fast DCH Setup Mechanisms................................................................................................................................ 29
7.3.1 Background...................................................................................................................................................... 29
7.3.2 Reducing Uplink/Downlink Synchronization Time ........................................................................................ 29
3GPP
Release 6 4 3GPP TR 25.896 V2.0.0 (2004-03)
7.4 Shorter Frame Size for Improved QoS.................................................................................................................. 31

7.5 Signalling to support the enhancements ................................................................................................................ 32
7.5.1 Downlink signalling ........................................................................................................................................ 32
7.5.1.1 Basic considerations ........................................................................................................................................ 32
7.5.1.2 Downlink signalling multiplexed on existing channel..................................................................................... 32
7.5.1.3 Downlink signalling on a new code channel ................................................................................................... 33
7.5.2 Uplink signalling ............................................................................................................................................. 33
7.5.2.1 Basic considerations ........................................................................................................................................ 33
7.5.2.2 Coding, multiplexing and mapping options..................................................................................................... 33
7.5.2.2.1 Mapping on (E-)DPDCH ........................................................................................................................... 34
7.5.2.2.1.1 Mapping on DPDCH using a TrCH ........................................................................................................... 34
7.5.2.2.2 Mapping on DPCCH.................................................................................................................................. 34
7.5.2.2.3 Mapping on a new code channel................................................................................................................ 35
7.6 Miscellaneous enhancements ................................................................................................................................ 35
7.6.1 Support for enhanced channel estimation ........................................................................................................ 35
8 Physical Layer Structure Alternatives for Enhanced Uplink DCH ....................................................... 36
8.1 Relationship to existing transport channels ........................................................................................................... 36
8.1.1 Transport Channel Structure............................................................................................................................ 36
8.1.1.1 Number of E-DCHs ......................................................................................................................................... 37
8.1.1.2 TTI .............................................................................................................................................................. 37
8.2 TTI length vs. HARQ physical channel structure ................................................................................................. 38
8.3 Multiplexing alternatives in general...................................................................................................................... 39
8.3.1 Reuse of current physical layer structure......................................................................................................... 40
8.3.2 Allocating a separate code channel for Enhanced uplink DCH....................................................................... 40
8.4 Multiplexing alternatives in detail......................................................................................................................... 40
8.4.1 Physical layer structures in time domain (TS25.212 ) ..................................................................................... 41
8.4.1.1 General structures describing only how to multiplex DCH and E-DCH ......................................................... 41
8.4.1.1.1 Physical Layer Structure Supporting minimum TTI of 10ms .................................................................... 41
8.4.1.1.1.1 Code multiplexing between DCH and E-DCH .......................................................................................... 41
8.4.1.1.1.2 Time multiplexing between DCH and E-DCH .......................................................................................... 42
8.4.1.1.2 Physical Layer Structure Supporting minimum TTI of 2ms ...................................................................... 43
8.4.1.1.2.1 Code multiplexing between DCH and E-DCH .......................................................................................... 43
8.4.1.1.2.2 Time multiplexing between DCH and E-DCH .......................................................................................... 44
8.4.1.2 More detailed structures defining how to multiplex L1 signaling (HSDPCCH, DPCCH, EDPCCH) with
DCH and E-DCH............................................................................................................................................. 46
8.4.2 Physical layer structures in code domain......................................................................................................... 46
8.4.2.1 Case 1: Structure when using code multiplexing for all channels ................................................................... 47
8.4.2.2 Case 2: Structure when E-DCH, DCH and EDPCCH are time Multiplexed................................................... 48
8.4.2.3 Case 3: Structure when E-DCH , DCH and EDPCCH and HS-DPCCH are time multiplexed ....................... 49
8.4.2.4 Case 4: Structure when E-DCH, EDPCCH and HSDPCCH are time multiplexed ......................................... 50
8.4.2.5 Case 5: Structure similar to case 2, but with 8PSK included........................................................................... 51
8.4.2.8 Case 8: Structure when using code multiplexing for all channels ................................................................... 52
8.5 E-DCH timing ...................................................................................................................................................... 53
9 Evaluation of Techniques for Enhanced Uplink.................................................................................... 54
9.1 Scheduling <NodeB controlled scheduling, AMC>.............................................................................................. 54
9.1.1 Performance Evaluation .................................................................................................................................. 54
9.1.1.1 Comparison of Centralized and Decentralized Scheduler ............................................................................... 54
9.1.1.1.1 Results with Full Buffer ............................................................................................................................. 54
9.1.1.1.2 Results with Mixed Traffic Model............................................................................................................. 56
9.1.1.1.3 Discussion .................................................................................................................................................. 57
9.1.2 Complexity Evaluation <UE and RNS impacts> ............................................................................................ 58
9.1.3 Downlink Signalling........................................................................................................................................ 58
9.1.4 Uplink Signalling............................................................................................................................................. 58
9.1.5 8PSK link performance ................................................................................................................................... 58
9.2 Hybrid ARQ .......................................................................................................................................................... 59
9.2.1.1 Hybrid ARQ performance with and without soft combining .......................................................................... 59
9.2.1.2 Hybrid ARQ performance in soft handover .................................................................................................... 63
3GPP
Release 6 5 3GPP TR 25.896 V2.0.0 (2004-03)
9.2.1.3 HARQ Efficiency ............................................................................................................................................ 65

9.2.2.1 Buffering complexity....................................................................................................................................... 66
9.2.2.1.1 Soft buffer at Node B ................................................................................................................................. 66
9.2.2.1.2 Reordering buffer in radio network............................................................................................................ 67
9.2.2.1.3 Retransmission buffer in UE...................................................................................................................... 67
9.2.2.2 Encoding/decoding and rate matching complexity.......................................................................................... 68
9.2.2.3 UE and RNS processing time considerations .................................................................................................. 68
9.2.2.4 HARQ BLER operation point and complexity................................................................................................ 68
9.2.4.1 E-TFC signalling ............................................................................................................................................. 68
9.2.4.1.1 Summary of results .................................................................................................................................... 69
9.2.4.1.1.1 Case 1 results ............................................................................................................................................. 69
9.2.4.1.1.2 Case 2 results ............................................................................................................................................. 70
9.2.4.1.1.3 Case 3 results ............................................................................................................................................. 71
9.2.4.1.2 Simulation assumptions ............................................................................................................................. 72
9.3 Fast DCH Setup Mechanisms.............................................................................................................................. 72
9.4 Shorter Frame Size for Improved QoS.................................................................................................................. 72
9.4.1.1 Data only, Full buffer ...................................................................................................................................... 72
9.4.1.2 Data only, Traffic models ................................................................................................................................ 75
9.4.1.3 Voice & Data, Full buffer................................................................................................................................ 82
9.5 Physical layer structures........................................................................................................................................ 86
9.5.1 Complexity evaluation..................................................................................................................................... 86
9.5.1.1 PAR analysis ................................................................................................................................................... 86
9.5.1.1.1 Total number of channel bits from both E-DCH and DCH that can be accommodated one BPSK
code channel with SF=4............................................................................................................................. 88
9.5.1.1.2 Total number of channel bits from both E-DCH and DCH that can be accommodated in two BPSK
code channels with SF=4 ........................................................................................................................... 89
9.5.1.1.3 Total number of channel bits from both E-DCH and DCH that can be accommodated in three BPSK
9.5.1.1.4 Total number of channel bits from both E-DCH and DCH that can be accommodated in four BPSK
9.5.1.1.5 Total number of channel bits from both E-DCH and DCH that can be accommodated in five BPSK
9.5.1.1.6 Total number of channel bits from both E-DCH and DCH that can be accommodated in six BPSK
9.5.1.1.7 Total number of channel bits from both E-DCH and DCH that can be accommodated in three 8PSK
streams with SF=4...................................................................................................................................... 95
9.5.1.2 Considerations on PAR analysis...................................................................................................................... 95
9.5.1.2.1 Example based on case 2/5 and parameter set 1 ........................................................................................ 95
9.5.1.2.2 Example based on case 1,2 (BPSK vs 8-PSK)........................................................................................... 96
9.5.1.2.3 Example for multi-code ............................................................................................................................. 97
9.5.1.2.4 Discussion .................................................................................................................................................. 98
9.6 Results including multiple techniques................................................................................................................... 98
9.6.1 Results with HARQ, shorter TTI, time & rate scheduling............................................................................... 98
9.6.1.1 Full Buffer results............................................................................................................................................ 98
9.6.1.2 Mixed traffic model results............................................................................................................................ 105
9.6.2 Results with HARQ, 10ms TTI, rate scheduling with persistence ................................................................ 113
9.6.2.1 Full Buffer results.......................................................................................................................................... 113
9.6.2.2 Mixed traffic model results............................................................................................................................ 114
9.7 Compatibility of the enhancements with existing releases.................................................................................. 120
9.7.1 Compatibility at the edge of coverage ........................................................................................................... 120
9.7.1.1 Non transparent functionality ........................................................................................................................ 120
3GPP
Release 6 6 3GPP TR 25.896 V2.0.0 (2004-03)
9.7.1.2 Transparent functionality............................................................................................................................... 120

9.7.2 Legacy UE ..................................................................................................................................................... 121
9.7.3 Link budget.................................................................................................................................................... 121
9.7.4 DL capacity ................................................................................................................................................... 121
9.7.5 Design re-use ................................................................................................................................................. 122
9.7.6 Conclusion..................................................................................................................................................... 122
10 Impacts to the Radio Interface Protocol Architecture ......................................................................... 122
10.1 Protocol Model .............................................................................................................................................. 122
10.1 Introduction of new MAC functionality ........................................................................................................ 122
10.1.1 Introduction of an enhanced uplink dedicated transport channel (E-DCH)................................................... 123
10.1.2 HARQ functionality ...................................................................................................................................... 123
10.1.3 Reordering entity ........................................................................................................................................... 123
10.1.4 TFC selection................................................................................................................................................. 123
10.2 RLC .............................................................................................................................................................. 123
10.3 RRC .............................................................................................................................................................. 123
11 Impacts to Iub/Iur Protocols ................................................................................................................ 124
11.1 Impacts on Iub/Iur Application Protocols...................................................................................................... 124
11.2 Impacts on Frame Protocol over Iub/Iur........................................................................................................ 124
12 Conclusions and Recommendations .................................................................................................... 124
12.1 Conclusions ................................................................................................................................................... 124
12.2 Recommendations ......................................................................................................................................... 125
Annex A: Simulation Assumptions and Results........................................................................................ 126

A.1 Link Simulation Assumptions ............................................................................................................. 126
A.1.1 Interface between link level and system level ............................................................................................... 126
A.1.2 Link level parameters .................................................................................................................................... 127
A.1.3 Channel models ............................................................................................................................................. 127
A.1.4 Description of Short Term FER and ECM Metod ......................................................................................... 128
A.1.4.1 Short-term FER method: ............................................................................................................................... 128
A.1.4.2 ECM method: ................................................................................................................................................ 129
A.1.4.3 Comparison between short term and ECM method ....................................................................................... 130
A.2 Link Simulation Results ...................................................................................................................... 132
A.2.1 HARQ Performance Evaluation .................................................................................................................... 132
A.2.1.1 HARQ Efficiency and Number of Retransmissions ...................................................................................... 132
A.2.2 Link Performance of E-DCH for System Simulations.................................................................................. 135
A.2.2.1 Short-term Link Performance with 2 ms TTI ................................................................................................ 135
A.2.2.2 Short-term Link Performance with 10 ms TTI .............................................................................................. 144
A.2.3 Link Performance with Different Pilot Overhead.......................................................................................... 149
A.2.3.1 Assumptions .................................................................................................................................................. 149
A.2.3.2 Results ........................................................................................................................................................... 150
A.2.4 Link Performance of Release-99 for System Simulations ............................................................................. 153
A.3 System Simulation Assumptions ......................................................................................................... 153
A.3.1 System Level Simulation Modelling and Parameters .................................................................................... 153
A.3.1.1 Antenna Pattern ............................................................................................................................................. 153
A.3.1.2 System Level Parameters............................................................................................................................... 154
A.3.1.3 Signaling Errors............................................................................................................................................. 157
A.3.1.4 Downlink Modeling in Uplink System Simulation ....................................................................................... 157
A.3.2 Uplink measurement accuracy....................................................................................................................... 157
A.3.2.1 Uplink power control..................................................................................................................................... 157
A.3.3 System Simulation Outputs and Performance Metrics .................................................................................. 158
A.3.3.1 Output metrics for data services .................................................................................................................... 158
A.3.3.2 Mixed Voice and Data Services .................................................................................................................... 159
A.3.3.3 Voice Services and Related Output Metrics .................................................................................................. 159
A.3.3.3.1 Voice Model............................................................................................................................................. 159
A.3.3.4 Packet Scheduler ........................................................................................................................................... 159
A.4 System Simulation Results .................................................................................................................. 160
A.4.1 Release-99 Performance ................................................................................................................................ 160
3GPP
Release 6 7 3GPP TR 25.896 V2.0.0 (2004-03)
A.4.1.1 Release-99 Performance With Full Buffer .................................................................................................... 160

A.4.1.1.1 System Setup............................................................................................................................................ 160
A.4.1.1.2 Performance Without TFC Control in AWGN ........................................................................................ 160
A.4.1.1.3 Performance With TFC Control in AWGN ............................................................................................. 161
A.4.1.2 Release-99 Performance With Mixed Traffic Model .................................................................................... 163
A.4.1.2.1 System Setup............................................................................................................................................ 163
A.4.1.2.2 Performance Without TFC Control in AWGN ........................................................................................ 164
A.4.1.3 Release-99 Voice Capacity............................................................................................................................ 166
A.4.1.3.1 System Setup............................................................................................................................................ 166
A.4.1.3.2 Voice Capacity......................................................................................................................................... 167
A.5 Traffic Models ..................................................................................................................................... 167
Annex B: Lognormal description ............................................................................................................... 175
Annex C: Uplink Rise Outage Filter .......................................................................................................... 176
Annex D: Speech Source (Markov) Model ................................................................................................ 176
Annex E: Modeling of the effect of channel estimation errors on Link performance........................... 177
Annex F: Change history ............................................................................................................................ 178
3GPP
Release 6 8 3GPP TR 25.896 V2.0.0 (2004-03)
Foreword
This Technical Report has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
3GPP
Release 6 9 3GPP TR 25.896 V2.0.0 (2004-03)
1 Scope
This present document is the technical report for the Release 6 study item “Uplink Enhancements for Dedicated
Transport Channels”(see [1]).
The purpose of this TR is to help TSG RAN WG1 to define and describe the potential enhancements under
consideration and compare the benefits of each enhancement with earlier releases for improving the performance of the
dedicated transport channels in UTRA FDD uplink, along with the complexity evaluation of each technique. The scope
is to either enhance uplink performance in general or to enhance the uplink performance for background, interactive and
streaming based traffic.
This activity involves the Radio Access work area of the 3GPP studies and has impacts both on the Mobile Equipment
and Access Network of the 3GPP systems.
This document is intended to gather all information in order to compare the solutions and gains vs. complexity, and
draw a conclusion on way forward.
This document is a ‘living’ document, i.e. it is permanently updated and presented to TSG-RAN meetings.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TD RP-020658: "Study Item Description for Uplink Enhancements for Dedicated Transport
Channels ".
[2] 3GPP RAN WG1 TDOC R1-00-0909, “Evaluation Methods for High Speed Downlink Packet
Access (HSDPA)”, July 4 2000
[3] Hämäläinen S., P. Slanina, M. Hartman, A. Lappeteläinen, H. Holma, O. Salonaho, ”A Novel

Interface between Link and System Level Simulations”, Proceedings of ACTS summit 1997,
Aalborg, Denmark, Oct. 1997, pp. 509-604.
[4] 3GPP RAN WG1#29 TDOC R1-02-1326, “Link Prediction methodology for System Level
Simulations”, Shanghai China, November 5 2002.
[5] Ratasuk, Ghosh, Classon, “Quasi-Static Method for Predicting Link-Level Performance” IEEE
VTC 2002.
[6] 3GPP TR 25.942 V3.3.0 (2002-06), RF System Scenarios, June 2002.
[7] 3GPP TR 25.853 V4.0.0 (2001-03), “Delay Budget within the Access Stratum”, March 2001.
[8] 3GPP TS 25.133 V3.11.0 (2002-09), “Requirements for support of radio resource management
(FDD) (Release 99)”, September 2002.
[9] Hytönen, T.; “Optimal Wrap-around Network Simulation”, Helsinki University of Technology
Institute of Mathematics Research Reports, 2001, www.math.hut.fi/reports/, Report number A432
3GPP
Release 6 10 3GPP TR 25.896 V2.0.0 (2004-03)
[10] “Source Models of Network Game Traffic", M. S. Borella, Proceedings, Networld+Interop '99
Engineer's Conference, May 1999.
[11] 3GPP RAN WG1#30 TDOC R1-03-0083, “Link Prediction Methodology for System Level
Simlations,” Lucent Technologies, San Diego, USA, January 7-10, 2003.
[12] 3GPP2, 1xEV-DV Evaluation Methodology.
[13] ETSI TR 101 12, Universal Mobile Telecommunications System (UMTS); Selection procedures
for the choice of radio transmission technologies of the UMTS (UMTS 30.03 v3.2.0)
[14] TS 25.214, v5.3.0, “Physical layer procedures (FDD)”, December 2002
[15] TS 25.331, v5.4.0, "Radio Resource Control (RRC); Protocol Specification", March 2003
[16] TS 25.321 v.5.5.0: ”Medium Access Control (MAC) Protocol Specification", June 2003
3 Definitions, symbols and abbreviations

E-DCH Enhanced DCH, a new dedicated transport channel type or enhancements to an
existing dedicated transport channel type (if required by a particular proposal)
E-DPCCH Enhanced DPCCH, a physical control channel associated with the E-DPDCH (if
required by a particular proposal)
E-DPDCH Enhanced DPDCH, a new physical data channel or enhancements to the current
DPDCH (if required by a particular proposal)
4 Introduction
At the 3GPP TSG RAN #17 meeting, SI description on “Uplink Enhancements for Dedicated Transport Channels” was
approved [1].
The justification of the study item was, that since the use of IP based services becomes more important there is an
increasing demand to improve the coverage and throughput as well as reduce the delay of the uplink. Applications that
could benefit from an enhanced uplink may include services like video-clips, multimedia, e-mail, telematics, gaming,
video-streaming etc. This study item investigates enhancements that can be applied to UTRA in order to improve the
performance on uplink dedicated transport channels.
The study includes, but is not restricted to, the following topics related to enhanced uplink for UTRA FDD to enhance
uplink performance in general or to enhance the uplink performance for background, interactive and streaming based
traffic:
- Adaptive modulation and coding schemes
- Hybrid ARQ protocols
- Node B controlled scheduling
- Physical layer or higher layer signalling mechanisms to support the enhancements
- Fast DCH setup
- Shorter frame size and improved QoS
5 Requirements
- The overall goal is to improve the coverage and throughput as well as to reduce the delay of the uplink
dedicated transport channels.
3GPP
Release 6 11 3GPP TR 25.896 V2.0.0 (2004-03)
- The focus shall be on urban, sub-urban and rural deployment scenarios. Full mobility shall be supported, i.e.,
mobility should be supported for high-speed cases also, but optimisation should be for low-speed to medium-
speed scenarios.
- The study shall investigate the possibilities to enhance the uplink performance on the dedicated transport
channels in general, with priority to streaming, interactive and background services.
- Features or group of features should demonstrate significant incremental gain, with reasonable complexity.
The value added per feature should be considered in the evaluation.
- The UE and network complexity shall be minimised for a given level of system performance.
- The impact on current releases in terms of both protocol and hardware perspectives shall be taken into account.
- It shall be possible to introduce the new features in the network which has terminals from Release’99, Release
4 or Release 5.
6 Reference Techniques in Earlier 3GPP Releases
6.1 DCH Setup Mechanisms

A fundamental concept in WCDMA is the connection state model, illustrated in Figure 6.1.1. The connection state
model enables optimization of radio and hardware resources depending on the activity level of each UE.
- Users with high transmission activity (in either uplink, downlink or both) should be in CELL_DCH state,
where power-controlled dedicated channels are established to/from the UE. In CELL_DCH state, the UE is
assigned dedicated radio and hardware resources, which minimizes processing delay and allows for high
capacity.
- Users with low transmission activity should be in CELL_FACH state, where only common channels are used.
The major advantages with CELL_FACH state are the possibility for low UE power consumption and that no
dedicated hardware resources in the Node B are needed.
- Users with no transmission activity are in CELL_PCH or URA_PCH states, which enable very low UE power
consumption but do not allow any data transmission. These states are not discussed further in this section.
Switching between CELL_DCH and CELL_FACH are controlled by the RRC based on requests from either the
network or the UE. Entering CELL_DCH implies the establishment of a DCH, which involves a physical layer random
access procedure, NBAP and RRC signaling, and uplink and downlink physical channel synchronization.
Clearly, it is desirable to switch a UE to CELL_FACH state when there is little transmission activity in order to save
network resources and to reduce the UE power consumption. Switching between CELL_DCH and CELL_FACH is
especially useful in scenarios with a large number of bursty packet data users, where there is a risk that the system
becomes code limited if users temporarily not receiving/transmitting any packets are not switched to CELL_FACH.
When the activity increases, the UE should rapidly be switched back to CELL_DCH and a dedicated channel be
established.
3GPP
Release 6 12 3GPP TR 25.896 V2.0.0 (2004-03)
CELL_FACH CELL_DCH
CELL_PCH, URA_PCH
Low transmission activity. No High transmission activity.
No transmission activity.
dedicated channels established. Dedicated channels established.
TrCh/PhyCh
reconfiguration
Figure 6.1.1: Connection states.
6.1.1 Uplink/Downlink Synchronization

The DCH setup procedure in Rel99/4/5 is illustrated in Figure 6.1.2. At time t1, downlink data arrives to the RNC and a
decision to establish a DCH is taken at time t2. The decision is sent to the UE via the S-CCPCH, which starts to
establish synchronization to the downlink DPCCH at time t4, using the standardized procedure described in [14].
The downlink synchronization procedure is divided into two phases: The first phase starts when higher layers in the UE
initiate physical dedicated channel establishment and lasts until 160 ms after the downlink dedicated channel is
considered established by higher layers. During this time, out-of-sync shall not be reported and in-sync shall be reported
using the CPHY-Sync-IND primitive if the downlink DPCCH quality exceeds a threshold for at least 40 ms. The second
phase starts 160 ms after the downlink dedicated channel is considered established by higher layers. During this phase,
both out-of-sync and in-sync are reported, depending on the situation in the UE. As the UE is not allowed to report in-
sync until at least 40 ms after the start of the first synchronization phase, the interval T4 equals at least 40 ms.
Once the UE has detected the in-sync condition for the downlink DPCCH, the UE starts transmitting the uplink power
control preamble at time t5. The length of the power control preamble, T5, is set by higher layer signaling. During this
period, the Node B establishes synchronization with the UE on the uplink. Once the power control preamble is finished,
at t6, the UE uplink/downlink DPCH is established and data transmission may begin.
switching
Power decision (RRC/SRNC)
DPCCH
downlink DPCH
switching DPCH
command
SCCPCH
confirm
uplink DPCH
T1 T2 T3 T4 T5 T6
Cell_FACH Cell_DCH
t1 t2 t3 t4 t5 t6 t7
Figure 6.1.2: Rel99/4/5 procedure for DCH establishment. Note that T6 is optional and data transmission may
start already at t6.
3GPP
Release 6 13 3GPP TR 25.896 V2.0.0 (2004-03)
6.2 Uplink TFCS Management with RRC Signalling

There are following TFCS reconfiguration messages available in current specifications [15]:
- Complete reconfiguration, in which case UE shall remove a previously stored TFCS set, if it exists
- Addition, in which case UE shall insert the new additional TFC(s) into the first available position(s) in
ascending order in the TFCS.
- Removal, in which case UE shall remove the TFC indicated by “IE” TFCI from the current TFCS, and regard
this position (TFCI) as vacant.
- Replace, in which case UE shall replace the TFCs indicated by “IE” TFCI and replace them with the defined
new TFCs.
In addition to those, there is also Transport format combination control message defined in [15], with which the
network can define certain restrictions in the earlier defined TFCS set, as described below.
- Transport Format Combination Subset in the TFC control message can be defined in the format of TFCS
restriction; for downgrading the original TFCS set. There are several different formats possible. The message
can define the minimum allowed TFC index in the original TFCS set. Or it can define that a certain TFC subset
from the original TFCS set is either allowed or not. One possible way to define the message is to list what
Transport channels have restrictions, and then list the allowed TFIs for the restricted Transport channels.
- Transport Format Combination Subset in the TFC control message message can be defined in the format of
canceling the earlier TFCS restriction; i.e. defining that the original TFCS set is valid again.
Transport format combination control message includes activation time. The activation time defines the frame number
/time at which the changes caused by the related message shall take effect. The activation time can be defined as a
function of CFN, ranging between 0…255, the default being “now”.
Transport format combination control message can also include an optional parameter of TFC control duration, which
defines the period in multiples of 10 ms frames for which the defined restriction, i.e. TFC subset , is to be applied. The
possible values for this are (1,2,4,8,16,24,32,48,64,128,192,256,512).
In [15], in chapter 13.5, it is defined separately for each RRC procedure, what kind of delay requirements there are for
UE. For TFCS control messages there are following delay requirements:
- TRANSPORT FORMAT COMBINATION CONTROL : N1 = 5 . This defines the upper limit on the time
required to execute modifications in UE after the reception of the RRC message has been completed. This
means that after receiving the TFCS control message, the UE shall adopt the changes in the beginning of the
next TTI starting after N1*10ms .
- TRANSPORT FORMAT COMBINATION CONTROL FAILURE: N2=8. This defines the number of 10 ms
radio frames from end of reception of UTRAN -> UE message on UE physical layer before the transmission of
the UE -> UTRAN response message must be ready to start on a transport channel with no access delay other
than the TTI alignment. The UE response message transmission from the physical layer shall begin at the latest
(N2*10)+TTI ms after completion of the reception of the last TTI carrying the triggering UTRAN -> UE
message. When Target State is CELL_DCH, the UE response message transmission from the physical layer
may be additionally delayed by the value of IE "SRB delay".
6.3 Transport Format Combination Selection in the UE

6.3.1 Description of TFC selection method
The TFC selection is a MAC function that the UE uses to select a TFC from its current TFCS whenever it has
something to transmit. The TFC is selected based on the need for data rate (i.e. UE buffer contents), the currently
available transmission power, the available TFCS and the UE’s capabilities. The details of the TFC selection function
are covered in [8] and [16].
3GPP
Release 6 14 3GPP TR 25.896 V2.0.0 (2004-03)
The most important parameters governing the behavior of the TFC selection function are called X,Y and Z, and their
values have been agreed to be static in the current specifications. Table 6.3.1 below shows the values of these
parameters.
Table 6.3.1: X, Y, Z parameters for TFC selection
X Y Z
15 30 30
Based on these parameters, the UE shall continuously evaluate based on the Elimination, Recovery and Blocking
criteria defined below, how TFCs on an uplink DPDCH can be used for the purpose of TFC selection. The following
diagram illustrates the state transitions for the state of a given TFC.
Elimination criterion is met Blocking criterion is met
2.
Supported Excess-power Blocked
state state state
Recovery criterion is met
Recovery criterion is met
Figure 6.3.1: State transitions for the state of a given TFC
The evaluation shall be performed for every TFC in the TFCS using the estimated UE transmit power. The UE transmit
power estimation for a given TFC shall be made using the UE transmitted power measured over the measurement
period, defined in section 9.1.6.1 of [8] as one slot, and the gain factors of the corresponding TFC. Table 6.3.2 below,
extracted from [8], shows the specified accuracy requirements for measuring UE transmit power over the one slot
measurement period, as a function of the current transmit power level relative to maximum output power.
Table 6.3.2: UE transmitted power absolute accuracy
Accuracy [dB]
Parameter Unit
PUEMAX PUEMAX
24dBm 21dBm
UE transmitted power=PUEMAX dBm +1/-3 ±2
UE transmitted power=PUEMAX-1 dBm +1.5/-3.5 ±2.5
UE transmitted power=PUEMAX-2 dBm +2/-4 ±3
UE transmitted power=PUEMAX-3 dBm +2.5/-4.5 ±3.5
PUEMAX-10≤UE transmitted power<PUEMAX-3 dBm +3/-5 ±4
NOTE 1: User equipment maximum output power, PUEMAX, is the maximum output power level without tolerance
defined for the power class of the UE in TS 25.101, section 6.2.1.
The UE shall consider the Elimination criterion for a given TFC to be detected if the estimated UE transmit power
needed for this TFC is greater than the Maximum UE transmitter power for at least X out of the last Y successive
3GPP
Release 6 15 3GPP TR 25.896 V2.0.0 (2004-03)
measurement periods immediately preceding evaluation. The MAC in the UE shall consider that the TFC is in Excess-
Power state for the purpose of TFC selection.
MAC in the UE shall indicate the available bitrate for each logical channel to upper layers within Tnotify from the
moment the Elimination criterion was detected.
The UE shall consider the Recovery criterion for a given TFC to be detected if the estimated UE transmit power needed
for this TFC has not been greater than the Maximum UE transmitter power for the last Z successive measurement
periods immediately preceding evaluation. The MAC in the UE shall consider that the TFC is in Supported state for the
purpose of TFC selection.
MAC in the UE shall indicate the available bitrate for each logical channel to upper layers within Tnotify from the
moment the Recovery criterion was detected.
The evaluation of the Elimination criterion and the Recovery criterion shall be performed at least once per radio frame.
The UE shall consider the Blocking criterion for a given TFC to be fulfilled at the latest at the start of the longest uplink
TTI after the moment at which the TFC will have been in Excess-Power state for a duration of:
(Tnotify + Tmodify+ TL1_proc)
where:
Tnotify equals 15 ms
Tmodify equals MAX(Tadapt_max,TTTI)
TL1 proc equals 15 ms
Tadapt_max equals MAX(Tadapt_1, Tadapt_2, ..., Tadapt_N)
N equals the number of logical channels that need to change rate
Tadapt_n equals the time it takes for higher layers to provide data to MAC in a new supported bitrate,
for logical channel n. Table 6.3.3 defines Tadapt times for different services. For services where no codec
is used Tadapt shall be considered to be equal to 0 ms.
Table 6.3.3: Tadapt

Service Tadapt [ms]
UMTS AMR 60
UMTS AMR2 60
TTTI equals the longest uplink TTI of the selected TFC (ms).
Before selecting a TFC, i.e. at every boundary of the shortest TTI, the set of valid TFCs shall be established. All TFCs
in the set of valid TFCs shall:
1. belong to the TFCS.
2. not be in the Blocked state.
3. be compatible with the RLC configuration.
4. not require RLC to produce padding PDUs
5. not carry more bits than can be transmitted in a TTI (e.g. when compressed mode by higher layer
scheduling is used and the presence of compressed frames reduces the number of bits that can be
transmitted in a TTI using the Minimum SF configured).
The UE may remove from the set of valid TFCs, TFCs in Excess-power state in order to maintain the quality of service
for sensitive applications (e.g. speech). Additionally, if compressed frames are present within the longest configured
TTI to which the next transmission belongs, the UE may remove TFCs from the set of valid TFCs in order to account
for the higher power requirements.
3GPP
Release 6 16 3GPP TR 25.896 V2.0.0 (2004-03)
The chosen TFC shall be selected from within the set of valid TFCs and shall satisfy the following criteria in the order
in which they are listed below:
1. No other TFC shall allow the transmission of more highest priority data than the chosen TFC.
2. No other TFC shall allow the transmission of more data from the next lower priority logical channels.
Apply this criterion recursively for the remaining priority levels.
3. No other TFC shall have a lower bit rate than the chosen TFC.
The above rules for TFC selection in the UE shall apply to DCH, and the same rules shall apply for TF selection on
RACH and CPCH.
UE shall consider that the Blocking criterion is never met for TFCs included in the minimum set of TFCs (see [15]).
6.3.2 TFC selection method as a reference case for Enhanced Uplink

DCH
The important parameters to be included to the simulation assumptions for TFC selection method in the reference case
are:
a) Accuracy of the UE transmit power estimate. See table 6.3.2 in the previous section as a reference. This will have
an effect how fast UE moves a certain TFC to excess power state. Since the accuracy depends on the currently used
transmit power level, it is noted for the purpose of general understanding, that the accuracy is thus in average worse
with a bursty traffic model, in which quite often only DPCCH is transmitted, than with more real-time type of
application in which transmission of DPDCH is more continuous. Also the location in the cell will effect to the
accuracy due to the same reason. It is however seen that for the sake of simplicity, it would be appropriate to define
only one value for this parameter used in all simulations.
It is thus proposed that the accuracy defined for the maximum Ptx power level, ±2 dB, is used in all cases, for the
sake of simplicity of the simulations. This is to be modelled so that the error is lognormally distributed with zero
mean and std=1.2159 dB, which has the effect of causing 90% of the errors to occur within ±2 dB of the zero mean.
It is noted that the accuracy requirements in [8] are also defined for 90% probability.
b) Delay between the moment when elimination criterion is met in L1 and when the TFC is moved into blocked state.
See the previous section as a reference, together with the Annex A.6.4.2.1 from [8], defining the maximum delay to
be Tnotify + Tmodify+ TL1_proc + Talign_TTI. In addition to this , if criterion is met with a maximum misalignment between
the frame boundary, an extra 14 slots (9.33 ms) will need to be added to this delay. It is proposed that in the
simulation assumptions the assumption is that there is no codec (e.g. AMR) involved, the rate of which should be
adjusted and that the longest TTI in the selected TFC is TTTI =10 ms= Tmodify. This will result in a maximum delay
of (9.33 ms + Tnotify + Tmodify+ TL1_proc + Talign_TTI ) = (9.33 + 15 + 10 + 15 + 10) ms= 59.33 ms.
c) Delay between the moment recovery criterion is met and when TFC is moved back to supported state. See the
previous section as a reference, together with the Annex A.6.4.2.1 from [8], defining the maximum delay to be
Tnotify + Tmodify+ TL1_proc + Talign_TTI. In addition to this , if criterion is met with a maximum misalignment between
the frame boundary, an extra 14 slots (9.33 ms) will need to be added to this delay. It is proposed that in the
simulation assumptions the assumption is that there is no codec (e.g. AMR) involved, the rate of which should be
adjusted and that the longest TTI in the selected TFC is TTTI =10 ms= Tmodify. This will result in a maximum delay
of (9.33 ms + Tnotify + Tmodify+ TL1_proc + Talign_TTI ) = (9.33 + 15 + 10 + 15 + 10) ms= 59.33 ms.
d) TFCS ; i.e. the set of allowed user bit rates allocated to the UE. These are the bit rates that UE can use in the TFC
selection algorithm. There should be enough steps in the TFCS to allow the UE to decrease the used data rate in a
flexible fashion at the cell edge. It is proposed that there are two TFCS sets used in the reference case: [8, 16, 32,
64, 128, 256, 384] kbit/s and [8, 16, 32, 64, 128, 256, 384, 768, 1000] kbit/s . The idea why to have 2 sets is to
allow to study different peak data rate in the proposed schemes with a sensible TFCS set in the reference case to be
compared with.
The parameters and parameter values explained above are inserted to the Annex A.3, System simulation assumptions,
Table A - 8 - System Level Simulation parameters used in the reference rel99/rel4/rel5 case.
3GPP
Release 6 17 3GPP TR 25.896 V2.0.0 (2004-03)
It is noted that TFC selection method should be modelled also in the new schemes proposed for Enhanced Uplink DCH,
if there is no clear reason why it can not/should not be included into the proposed scheme. The parameters used should
be the same, or at least similar (e.g. TFCS set), as defined in the reference case.
6.4 RNC controlled scheduling: DRAC and TFCS Restriction

In R99/R4/R5, the uplink scheduling and rate control resides in the RNC. UE transmission can be controlled using
DRAC and TFCS Restriction.
The DRAC (Dynamic Resource Allocation Control) procedure is used by the network to dynamically control the
allocation of resources on an uplink DCH. The method is based on statistical scheduling. In each TTI, the UE
determines whether it can transmit or not based on the DRAC static parameters which have been determined by the
RNC ("Transmission Time Validity" and "Time duration before retry").
DRAC parameters are broadcasted in SIB 10. The UE determines the most stringent DRAC parameters from the last
received values from each cell of its active set. It also determines the allowed subset of TFCS according to the selected
maximum bit rate value.
Rules have been defined so that the UE always know which DRAC static parameters to use: in case several SIB10
messages from different cells are scheduled at the same time, the UE shall only listen to the SIB10 broadcast in the cell
of its Active Set having the best CPICH measurements.
7 Overview of Techniques considered to support

Enhanced Uplink
7.1 Scheduling <NodeB controlled scheduling, AMC>

The term “Node B scheduling” denotes the possibility for the Node B to control, within the limits set by the RNC, the
set of TFCs from which the UE may choose a suitable TFC. In Rel5, the uplink scheduling and rate control resides in
the RNC. By providing the Node B with similar tools, tighter control of the uplink interference is possible which in
turn, may result in increased capacity and improved coverage. Two fundamental approaches to scheduling exist:
- Rate scheduling, where all uplink transmission occur in parallel but at a low enough rate such that the desired
noise rise at the Node B is not exceeded.
- Time scheduling, where theoretically only a subset of the UEs that have traffic to send are allowed to transmit
at a given time, again such that the desired total noise rise at the Node B is not exceeded.
The usage of either rate or time scheduling is of course restricted by available power as the E-DCH will have to co-exist
with a mix of other transmissions by that UE and other UEs in the uplink. A hybrid of these two approaches is also
possible, where different proposals will tend to favor one or other of the fundamental approaches.
The scheduling schemes can all be viewed as management of the TFC selection in the UE and mainly differs in how the
Node B can influence this process and the associated signaling requirements. Hence, this section aims at describing the
commonalities among the scheduling schemes. Whether one or multiple methods for the Node B to influence the UE
TFC selection process is to be supported is FFS.
The set of TFCs from which the UE may choose a suitable TFC is denoted “Node B controlled TFC subset” in the
following. The UE selects a suitable TFC from the “Node B controlled TFC subset” employing the Rel5 TFC selection
algorithm (or modifications thereof if applicable). Any TFC in the Node B controlled TFC subset might be selected by
the UE, provided there is (1) sufficient power margin, (2) sufficient data available, (3) TFC is not in the blocked state.
The Node B controlled TFC subset relates to the TFCS and minimum set defined in Rel5 as
- “TFCS”. This is identical to the TFCS in Rel5 and is the set of all possible TFCs as configured by the RNC.
- “Node B controlled TFC subset”. The TFC selection algorithm in the UE selects a TFC from the “Node B
controlled TFC subset”. Note that the “Node B controlled TFC subset” is equal to or a subset of the TFCS and,
at the same time, equal to or a superset of the minimum set, i.e.. “Minimum set” ⊆ “Node B controlled TFC
subset” ⊆ “TFCS”.
3GPP
Release 6 18 3GPP TR 25.896 V2.0.0 (2004-03)
- “Minimum set”. This is identical to the minimum set in Rel5 as specified in [15]. The UE can always select a
TFC from the minimum set as TFCs in the minimum set never can be in blocked state.
In Figure 7.1, the different (sub)sets are illustrated. Setting the “Node B controlled TFC subset” equal to the TFCS
would result in behavior identical to Rel5. Furthermore, note that the smallest possible “Node B controlled TFC subset”
may be larger than the minimum set, i.e., “Node B controlled TFC subset” ⊃ “minimum set”.
TFC
TFC
TFC TFCS configured
TFC
by RNC
TFC
TFC
Node B controlled
TFC
TFC TFC subset
TFC Minimum Set

TFC
Figure 7.1 : Illustration of different sets of TFCs.

The ideas behind the ”Node B controlled TFC subset” are similar to the use of transport format combination control
specified in [15]. This signaling is typically used to allow the RNC to control the allowed uplink transport formats by
specifying a "TFC subset" along with an optional duration under which the “TFC subset” is valid. Node B scheduling
can be viewed as providing the Node B with similar tools, but allowing for faster adaptation to interference variations.
The interaction between RNC TFC control and Node B TFC control is FFS, although a preferable solution is to require
the UE not to choose a TFC outside any of these restrictions.
The main difference between scheduling strategies is how updates to the “Node B controlled TFC subset” are
controlled. In principle, an update needs to specify
- The new “Node B controlled TFC subset”
- The start time and the duration for which the update is valid
- The “Node B controlled TFC subset” to use when the scheduling period has expired.
This information can either be signaled, deduced from rules mandated in the specifications, or combinations thereof.
The main difference between different scheduling approaches therefore lies in the signaling and the rules associated
with the signaling. For example, simplistic implementations of rate scheduling and time scheduling could be as follows:
- Rate scheduling results if the “Node B controlled TFC subset” of different UEs are updated such that data
transmission from different UEs may overlap in time, regardless of the data rates used. The new “Node B
controlled TFC subset” is valid until the next time it is updated.
- Time scheduling results if the “Node B controlled TFC subset” of different UEs are updated such that only a
small set of the UEs have the possibility to transmit using TFCs outside the minimum set. The updated “Node
B controlled TFC subset” have a relatively short validity, typically in the order of milliseconds, where after the
“Node B controlled TFC subset” reverts to the situation prior to the scheduling interval or to the minimum set.
Depending on the scheduling scheme, the signaling may take different forms. Typically, both downlink and uplink
signaling is required.
Downlink signaling is required to command the UE to update the “Node B controlled TFC subset”. The start time and
the duration for which the update is valid may either be signaled explicitly or deduced from rules mandated in the
specifications. The signaling can either be dedicated for a certain UE, or common for several UEs. Furthermore, the
signaling can either be absolute, i.e., directly specify the “Node B controlled TFC subset”, or relative, i.e., specify the
3GPP
Release 6 19 3GPP TR 25.896 V2.0.0 (2004-03)
new “Node B controlled TFC subset” as an update of the previous subset. The former typically allows for more rapid
changes to the “Node B controlled TFC subset”, while the latter may imply less signaling overhead in the downlink
direction.
In the uplink, signaling is typically required to indicate to the Node B that the UE has data to transmit. Additional
information may be provided to the Node B, e.g., the amount of data, an indication of the power availability in the UE,
channel quality etc.
If E-DCH utilizes the HARQ, the possible operations for scheduling considering retransmission are as follows.
- Autonomous retransmission by UE: UE sends the retransmission at subsequent retransmission timing without
allowance of Node-B if UE receives no ACK. In this case, UE does not need to monitor the scheduling related
channel for retransmission. But UE could cause unexpected interference in the cell if Node B does not reserve
the noise rise of this UE for retransmission.
- Scheduled by Node B for retransmission: UE sends the retransmission if UE receives no ACK and Node B
allows retransmission at retransmission timing. In this option, one possibility is that UE may be allowed to
retransmit only if the TFC of initial transmission is within the allowed TFC subset assigned by Node B. In this
case, retransmission could be delayed if Node B assigns the lower TFC subset than TFC of initial
transmission. Another possibility is that even if the assigned TFC subset doesn’t include the TFC of initial
transmission, UE is allowed to retransmit with the same TFC of initial transmission at a transmit power
derived appropriately from the assigned TFC subset.
Considering above relationship, the design of scheduling scheme needs to take into account HARQ operation.
7.1.1 Node B Controlled Rate Scheduling by Fast TFCS Restriction

Control
7.1.1.1 Purpose and General Assumptions

The purpose of the studied technique is to enable more efficient use of the uplink power resource of the cell in order to
provide a higher cell throughput in the uplink and a larger coverage area for higher uplink data rates for streaming,
interactive and background class services. These goals are to be reached by fast Node B controlled uplink scheduling
which provides a better control to uplink noise rise and enables better control to noise rise variance.
In the existing Rel'99/Rel'4/Rel'5 system the uplink scheduling and data rate control resides in the RNC, which is not
able to respond to the changes in the uplink load as fast as a control residing in Node B could. Thus the Node B control
is seen to be requiring less UL noise rise headroom for combatting overload conditions. Node B control is also seen
capable of smoothing the noise rise variance by allocating higher data rates quickly when the uplink load decreases and
respectively by restricting the uplink data rates when the uplink load increases.
This enhancement technique is a method which itself does not require changes to the uplink DCH structure but rather
introduces new L1 signalling to facilitate fast UL scheduling by means of transport format combination control. Hence
the method does not require a new transport channel to be defined, but does not forbid it either. The method can be
applied with or without other enhancements such as for example HARQ and Fast DCH Setup.
7.1.1.2 General Principle

The basic principle of the technique is to allow Node B set and control a new restriction to the TFC selection
mechanism of the UE by fast L1 signalling. From the UE point of view the scheduling principle is the same than in
existing Rel'99/Rel'4/Rel'5 system with the modification that there would be additional L1 control over a new restriction
to its TFC selection mechanism. In the UTRAN side, a new scheduling by the means of fast TFCS restriction control is
introduced in Node B.
All the same functions considered for the enhancement technique can be achieved with already existing RRC
procedures for TFCS configuration and transport format combination control. However, by allowing the Node B to
have control over TFCS restrictions (i.e. provide a mechanims for transport format combination contorol in L1)
enhances the speed of which the UTRA can adapt to the changes in the UL load. In Rel'99/Rel'4/Rel'5, restricting the set
of alowed TFCs in a TFCS is done using an RRC signalling procedure called transport format combination control.
3GPP
Release 6 20 3GPP TR 25.896 V2.0.0 (2004-03)
7.1.1.3 Restricting the Allowed Uplink TFCs in a TFCS by L1 Signalling

In the subsequent chapters, a new mechanism and related L1 signalling are introduced. The purpose is to enable the
Node B to have a fast control over the TFC subset allowed to be used by the TFC selection algorithm of the UE. This is
to be achieved by defining two TFC subsets of the TFCS (A "Node B allowed TFC subset" and a "UE allowed TFC
subset"), and control signalling for adjusting these subsets.
Node B provides UE with an allowed TFC subset" from which the UE's TFC selection algorithm selects a TFC to be
used by employing the TFC selection method defined in Rel'99/Rel'4/Rel'5 specifications. This TFC subset provided by
the Node B is is named the “UE allowed TFC subset”.
In order to give RNC efficient control over the "UE allowed TFC subset" primarily controlled by the Node B, the RNC
provides the Node B with a second TFC subset named “Node B allowed TFC subset”. Node B defines and freely
reconfigures the "UE allowed TFC subset" as a subset of the "Node B allowed TFC subset". It is expected that with the
“Node B allowed TFC subset” RNC is able to do similar TFC restrictions as done in Rel'99/Rel'4/Rel'5 by using
Transport Format Combination Control procedure defined in RRC signalling. Both subsets are defined individually for
each UE.
The “UE allowed TFC subset” and the “Node B allowed TFC subset” may be signalled in the form of TFC pointers
pointing to the TFCS of the UE, if the TFCs can be arranged in an order that corresponds to the TFC restriction rule (or
scheduling strategy) that the Node B would be willing to apply. The ordering rule may be explicit or implicit.
In a example illustrated in the Figure7.1.1 below the Node B may want to restrict the TFCs is the order of Tx power for
the CCTrCH. In Figure 7.1.1, the TFCs in a TFCS are shown ordered in descending order (with respect to the power
required) starting from zero. Both TFC pointers are initialised to both the Node B and to the UE by the RNC in the
beginning of the connection. After initialisation the Node B can command the UE pointer up/down with the restriction
that UE pointer may not exceed Node B pointer. The TFC selection algorithm in the UE may select any TFC up to the
TFC indicated by the UE pointer. The purpose here is to control the UE's power usage by restricting it's TFC (i.e. data
rate) selection.
TFCS
TFC0
Node B pointer TFC1
TFC2
(assigned to Node B by RNC)
TFC3
TFC4 Required Power of
TFC5 CCTrCH
UE pointer TFC6
(commanded up/down TFC7
TFC8
to UE by Node B)
TFC9
TFC10
Figure 7.1.1: Depiction of the TFC pointers

The UE and Node B allowed TFC subsets should not restrict the use of the TFCs in the minimum TFC set guaranteed to
be available for UE's TFC selection at all times unless the minimum TFC set definition in the already existing
specifications is changed. (Minimum TFC set is defined in Rel'99/Rel'4/Rel'5 specifications)
7.1.1.4 Issues Requiring Further Studying

It is FFS, how a DCH controlled with this method could be multiplexed with DCHs controlled with Rel'99/Rel'4/Rel'5
methods, especially keeping in mind that simultaneous conversational traffic should be possible. Methods for using
separate code channel and TFCS, as well as multiplexing the Node B controlled DCH with e.g. a DCH carrying voice in
the same CCTrCH are to be studied. Naturally, if a DCH carrying e.g. conversational traffic is multiplexed with a DCH
carrying streaming, interactive or background traffic, the first DCH carrying conversational traffic still represents the
non-controllable load and only the second DCH could be controlled by the proposed method.
It is FFS how the method should work in different reconfiguration cases, such as physical channel and transport channel
reconfigurations, TFCS reconfiguration for the UE, Node B allowed TFC subset reconfiguration for the Node B. E.g. in
TFCS reconfiguration it should be defined whether UE continues the transmission with the new “UE allowed TFC
subset”, or continues with the old one. To allow flexible update of “Node B allowed TFC subset" to the Node B, and
3GPP
Release 6 21 3GPP TR 25.896 V2.0.0 (2004-03)
simultaneously minimise the amount of RRC signaling, one possibility is that “Node B allowed TFC subset" is not
informed to the UE at all.
It is also FFS how the method should work in soft handover. One possibility in the event the use of two pointers is
applicable is to use the same kind of method as defined for TPC commands. I.e. each cell in the active set receives L1
signalling from the UE and transmits L1 signalling to the UE independently from the other cells. Only if all the cells in
the active set command the UE pointer increment, the UE increases the UE pointer with one step. Respectively, if at
least one Node B in the active set commands the UE pointer decrement, the UE decreases the UE pointer (and therefore
the maximum power that can be transmitted) with one step. Also other possibilities exist and should be investigated.
The impacts of L1 signalling errors (including possible error accumulation) is FFS. This includes possible mitigation
techniques. Both the non-SHO and the SHO cases need to be considered.
7.1.1.5 Signalling to Support Fast TFCS Restriction Control
7.1.1.5.1 L1 signaling
Two new L1 messages are introduced in order to enable the transport format combination control by L1 signalling
between the Node B and the UE.
- Rate Request (RR), sent in the uplink by the UE to the Node B. With the RR the UE can ask the Node B to
change the set of the allowed uplink transport format combinations within the transport format combination
set.
- Rate Grant (RG), sent in the downlink by the Node B to the UE. With RG, the Node B can change the allowed
uplink transport format combinations within the transport format combination set.
7.1.1.5.2 RRC signalling
7.1.1.5.3 Iub/Iur signalling
7.1.2 Method for Node B Controlled Time and Rate Scheduling
7.1.2.1 Purpose and General Assumptions

Current UMTS R99/R4/R5 DCH specifications support autonomous UE transmission and UE TFCS control using
Radio Resource Control (RRC) messaging to establish and manage a per UE Transport Format Combination Set
(TFCS). TFCS reconfiguration latency and update rate is restricted by the communication delay between the RNC and
Node-B since the TFCS reconfiguration function is centralized in the RNC. Besides using more frequent and lower
latency TFCS updates to better manage uplink interference, additional advantages are possible by controlling the time at
which UEs transmit compared to allowing autonomous UE transmissions. If TFCS control is to be shared between the
RNC and Node B to enable fast TFCS control and higher UE uplink data rates are to be supported, then controlling time
of UE transmissions may also be necessary to most efficiently and correctly control uplink intereference levels for
maximizing throughput.
7.1.2.2 General Principle

The basic principle of the technique is to allow Node B control of UE TFCS and UE transmission time by fast L1
signalling. The difference to existing R99/R4/R5 systems is that the UE would receive additional L1 control over its
TFC selection and L1 control of its transmission time. From the UTRAN’s perspective, scheduling by means of TFCS
indicator and transmission time control is introduced at the Node B. A UE is sent a scheduling assignment by a
scheduling Node B. The UE transmits during the time interval specified by the downlink scheduling assignment using a
restricted TFCS, which is determined from a TFCS indicator in the scheduling assignment. It is possible to make use of
existing RRC procedures for TFCS configuration and transport format combination control and utilize them at the Node
B for determining a TFC. RNC and Node B control of UE TFCS and transmission time allows the UTRAN to control
the changes in the UL load.
In order to achieve a better QoS and fairer scheduling decisions, Node B may also create relative Comparative Metric
(CM) for UE using, for example, a combination of the following:
3GPP
Release 6 22 3GPP TR 25.896 V2.0.0 (2004-03)
- It employs buffer status information received from UEs to create another comparative metric. This metric explains
how much congestion is faced by each UE at uplink. Each UE is aware of buffer filling status of other UEs.
- It may also employ information for each UE such as the achieved QoS or latency to the destination and use such
information to create a comparative metric for each UE. This comparative metric reveals how well each UE is
doing the term of QoS provisioning comparing to other UEs.
Node B sends CM along side the TFCS to each UE for determining the UL scheduling events. In addition, it is also
useful to utilise historical information and trend for each UE to determine the CM and control scheduling events for a
better QoS and UL load balance.
7.1.2.3 Controlling UE TFCS and transmission time

In the subsequent chapters, a new mechanism for scheduling and related L1 signalling is introduced. The purpose is to
enable the Node-B to explicitly determine when and which UE’s should transmit data on the uplink and to control the
TFCS at each scheduled UE to control the uplink interference level and variation.
Instead of a Node-B continously controlling each UE’s TFCS by sending up/down adjustments to a pointer, the Node-B
sends a TFCS indicator (which could be a pointer e.g.) in the signaled scheduling assignment. The scheduling
assignment also indicates the scheduling time interval over which the UE must transmit given it has non-zero buffer
occupancy. The TFCS indicator specifies the TFC(s) corresponding to the highest rate/power level the UE is allowed to
transmit at during the specified time interval. After the scheduled time interval has elapsed, the TFCS reverts back to
the set that existed prior to the scheduled time interval. A scheduled UE is allowed to choose among the TFCs in the
restricted TFCS in terms of rate and power as determined by the TFCS indicator and based upon its own status e.g.
actual available power and latest buffer status. In addition, UE may also choose rate, power and transport format based
on CM. CM gives UEs information about their standing among other UEs in terms of relative congestion of buffer data
and relative QoS or latency to the destination. The rates used by the UE could be signaled on the associated uplink
signalling channel e.g. E-DPCCH at the time of transmission. Uplink power control information received by each UE
may be used to effectively adjust the TFCS indicator over the scheduling interval.
The Node B may decide which UE(s) are allowed to transmit and the corresponding TFCS indicators on a per TTI basis
based on, for example, some knowledge of the following:
- Buffer status of each UE
- Power status of each UE1
- Local Node B measured channel quality estimate for each UE2 or maximum UE power capability at Node B.
- Available interference Rise Over Thermal (RoT) margin (or threshold level) at the Node B
- Comparative Metric (CM) for each UE
The RoT margin may be computed by taking into account the thermal noise, other cell interference (Ioc), the Eb/No
requirements for power controlled (e.g. voice) channels (see Figure 7.1.2) and information provided by the RNC.
Node B Controlled Time and Rate scheduling may have several advantages. Reduced latencies in rate control,
exploitation of fast channel quality variations, more precise RoT control (i.e., better interference management), and
consequently, better efficiency for a given RoT constraint are enabled through such Node B controlled scheduling.
Downlink signaling overhead is only required for a small number of scheduled UEs, rather than for all UEs in the case
of a continuously updated TFCS. Furthermore, the scheduled mode can more precisely control how many UEs transmit
data on their respective enhanced uplink channel in a given time interval. In the uplink of CDMA systems, simultaneous
transmissions always interfere with each other and therefore, the scheduled mode can even ensure that always, for
example, only one UE transmits data on its enhanced uplink channel at a time. Under certain conditions, this is likely to
enhance throughput.
1 Note that power status is also effectively updated at the serving Node B(s) by each uplink data transmission from the accompanying TFCI or TFRI
information. It also may be advantageous to include buffer occupancy updates at the time of each uplink transmission in addition to periodic or
triggered updates.
2 Note that UE maximum power capability along with knowledge of the UE DPCCH power can be used for determining the TFCS indicator.
Equivalently, Ec/Nt for the DPCCH measured at the Node B along with UE power margin to DPCCH power ratio can be used for determining
the TFCS indicator.
3GPP
Release 6 23 3GPP TR 25.896 V2.0.0 (2004-03)
RoT threshold
Allowable Noise rise from E- PUL_data
DCH (i.e., amount of
headroom or margin)
Power requirements of …
active power controlled
channels (e.g. voice)
Ioc (Other cell

Interference)
N0W (thermal noise)
Figure 7.1.2: Noise Rise Bin for Node B controlled scheduling.
7.1.2.4 Issues Requiring Further Study

It is FFS how the method should work in soft handover. One problem is that scheduling UEs in soft handoff without
any coordination between Node Bs in the active set could lead to RoT violations that significantly impact power
controlled channels. However, one possibility is to simply send TFCS indicators that restrict UEs power level in soft
handoff to control their interference impact on adjacent non-scheduling cells. The Node B would need to be made aware
of a UEs soft handoff state in this case. Alternatively or additionally, TFC determination by the UE can include using
soft handoff state information. Another limitation of scheduling a UE in soft handoff is that if the UE simply follows the
scheduling command of either Node B, then the active set Node B(s) for the UE that do not schedule the user, may not
attempt to decode its data. Therefore, the UE transmission will not derive any macro-diversity benefit. Yet another
possiblility FFS is to use only TFCS control for UEs during soft handoff and allow autonomous transmissions. This
alternative may avoid the complexity that could result in the operation of the Time and Rate scheduling in SHO.
Finally, it is possible that each active set serving cell uses its knowledge of link imbalance (e.g. based on uplink
DPCCH SNR consistently below the RNC defined outer loop power control threshold) to help limit scheduling
activities for a given UE in soft handoff.
It is also FFS to minimize the number of scheduling information status update messages that are sent or alternatively
how often scheduling information requests are made. Similarly, it needs to be determined whether UEs should
autonomously report scheduling information (periodically and/or triggered on events) or whether they should only be
requested by the Node B.
Finally, it is also for FFS on how to support both TFCS controlled autonomous transmissions and TFCS controlled and
transmission time controlled scheduling for both the enhanced uplink DCH and along with the Rel’99/Rel’4/Rel’5
DCHs. The co-existence of the different modes may provide flexibility in serving the different traffic types. For
example, traffic with small amount of data and/or higher priority such as TCP ACK may be sent using only a rate
control mode with autonomous transmissions compared to using time and rate control scheduling as the former would
involve lower latency and lower signaling overhead. It also may be desirable to confine autonomous transmissions to
specific time intervals different than when scheduled transmissions occur.
7.1.2.5 Signalling to Support Fast Node-B Time and Rate Control
7.1.2.5.1 L1 Signalling
Two new L1 messages are introduced in order to enable fast time and rate control between the Node B and the UE.
- Scheduling Information Update (SI), sent in the uplink by the UE to the Node B. With the SI the UE can
provide the Node B buffer occupancy and rate or power information so its scheduler(s) can maintain fairness
and determine the UEs TFCS indicator and appropriate transmission time interval.
3GPP
Release 6 24 3GPP TR 25.896 V2.0.0 (2004-03)
- Scheduling Assignment or Grant (SA), sent in the downlink by the Node B to the UE. With SA, the Node B
can set the TFCS indicator and subsequent transmission start time(s) and time interval(s) to be used by the UE.
7.1.2.5.1.1 Uplink Signalling of Scheduling Information Update
7.1.2.5.1.1.1 Explicit scheduling information update signaling
With the explicit scheduling information update, the UE can provide the Node B with either the amount of data in its
buffer or the supportable data rate as well as the transmit power status.
Since Node B cannot predict data occurrence in the UE buffer, a possible method to save uplink RoT resource would be
that the UE autonomously starts transmitting the scheduling information update when the amount of data in the UE
buffer exceeds a predefined threshold. The threshold can be defined by taking into account the amount of data, which
can be autonomously transmitted within the delay requirement without acquiring the scheduling grant. Attaching CRC
to the scheduling information update could help the Node B to detect it.
If signalling of the supportable data rate is employed, the UE could get the scheduling grant only after sending the
supportable data rate to the Node B, since the Node B cannot estimate the data rate that can be accommodated by the
UE.
If the data amount reporting is employed, the Node B can estimate the amount of data remaining in the UE buffer from
its knowledge of amount of data received after the previous report. This provides a possibility to reduce the signalling
overhead. However, it should be noted that the Node B cannot take into account new data, which has occurred after the
previous report.
Possible options for data amount reporting are listed as follows:
- Periodic reporting: Amount of data in the UE buffer is reported periodically after the initial reporting. It would
be worthwhile noting that the data amount reporting may be useless if no new data has occurred after the
previous report. It is also noted that each UE could have different timing offset for the data amount reporting to
spread out the uplink interference as done in CQI reporting in HSDPA.
- Event-triggered reporting: After the initial reporting, amount of data in the UE buffer can be reported at any
time if new data occurs at the UE buffer after the previous report. How frequently it will be reported would
depend on realistic traffic situation.
- Event-triggered reporting at periodic timings: After the initial reporting, amount of data in the UE buffer can
be reported at the predefined periodic timings only if there is new data occurred after the previous report. The
maximum reporting frequency is limited by the predefined reporting period.
Exact definition of the data amount report is FFS.
Regarding the report timing of the transmit power status, a possible option could be to send the transmit power status at
the same time as the supportable data rate or the data amount report. However, another possible option could be to
allow different report timing due to the following reasons:
- For efficient scheduling operation between multiple UEs, the Node B may need periodic reporting of the
transmit power status from each UE.
- The data amount report timing may depend on the traffic situation as discussed above.
Exact definition of the transmit power status report is FFS. It could be a short-term measurement if instantaneous
information about the transmit power status is needed. On the other hand, considering that the short-term variation in
uplink channel condition can be overcome by the power control to a certain extent, it could be a long-term
measurement. It is noted that it may be possible for the Node B to calculate the long-term measurement by taking
average of the short-term measurements.
3GPP
Release 6 25 3GPP TR 25.896 V2.0.0 (2004-03)
7.1.2.5.1.1.2 Other ways of conveying scheduling information update to Node B
7.1.2.5.2 RRC Signalling (TBD)
7.1.2.5.3 Iub/Iur Signalling (TBD)
7.1.3 Scheduling in Soft Handover

When more than one Node B control the cells present in the UE active set, there are several alternatives as to the
location of the scheduling entity which controls the UE. Possible solutions are:
- The Node B controlling the best downlink cell (as defined by RRC for DSCH/HS-DSCH operation) is
identified as the sole scheduling entity.
- The Node B controlling the best uplink cell (the meaning of best uplink cell would have to be defined
precisely) is identified as the sole scheduling entity for the UE.
- All Node Bs controlling one or more cells in the UE active set are identified as valid scheduling entities. This
approach requires an additional decision procedure in the UE when the UE receives the scheduling
assignments from multiple Node Bs.
It is noted that the E-DCH transmission of the UEs in soft handover may have an effect on the RoT variation of the
multiple cells in the active set. If one Node B is identified as a sole scheduling entity, scheduling of a UE in SHO
without consideration of non-scheduling cells in the active set could lead to an unexpected variation of the RoT in those
cells. To control the RoT variation, it is possible that a Node B uses information from the network, for example, a
scheduling weight for each UE in soft handover.
If multiple Node Bs are identified as valid scheduling entities, a UE in a SHO region may receive different scheduling
assignments from multiple Node Bs and hence UE operation upon receiving the scheduling assignments should be
defined. Possible UE operations are as follows:
- UE chooses the scheduling assignment from the ones indicated by the controlling Node Bs. For example,
either the best scheduling assignment or the worst one can be chosen.
- UE combines the scheduling assignments from the controlling Node Bs based on a certain algorithm. For
example, UE generates a single scheduling assignment by applying weighting factor (determined by the
network) to each scheduling assignment.
Various options have to be considered in terms of system performance in particular in presence of link imbalance and in
terms of overall system complexity. Reliability of downlink signalling in soft handover, e.g., the scheduling
assignment(s) from the controlling Node B(s), should be taken into account in further evaluation.
If the Node B controlled scheduling in soft handover is not seen as feasible, then one possibility would be to turn off the
Node B controlled E-DCH scheduling in soft handover.
7.1.4 Node B Controlled Rate Scheduling by Persistence Control

The basic principle of the technique is to allow fast control of the number of UEs that can transmit while fast control of
their TFCS restriction is still taking place. Fast control of the number of UEs is enabled by use of a persistence
parameter which works in a similar way to that used for RACH or DRAC in R99/4/5. In each TTI the UEs may transmit
data with a probability given by the persistence parameter. The persistence (p) is controlled and periodically updated by
the Node B within constraints determined by the RNC (unlike the case of DRAC where only the RNC determined the
persistence parameter).
The method is beneficial in rate control mode because one can control the interference in a system by using a single
persistence value since the UE's are transmiting asynchronously. The persistence represents the available interference
the system can tolerate and thus prevent's UE's in rate control mode to introduce additional interference. This in turn
improves uplink capacity.
3GPP
Release 6 26 3GPP TR 25.896 V2.0.0 (2004-03)
7.1.4.1 Issues Requiring Further Studying

It is FFS to determine how rate scheduling with persistence control would work in soft handoff. One possibility is to
send persistence information from all Active Set cells. Another possibility to avoid uplink interference management
problems from soft handoff is for a UE in soft handoff to further restrict its TFCS based on its soft handoff state.
Alternatively, the persistence parameter could be modified by UEs when in soft handoff. The persistence information
would apply to the rate controllable load [composed of non signaling and non-conversational data] of a CCTrCH. It is
for further study on how persistence would be used in the case of multiple CCTrCHs.
7.1.4.2 Signalling to Support Fast Rate Scheduling by Persistence Control
7.1.4.2.1 L1 signaling
The persistence parameter p needs to be signaled on the DL to the UE from the Node-B. The persistence parameter can
be different for different users.
7.1.5 Brief Overview of Different Scheduling Strategies

The purpose of this subsection is to provide a brief overview of the different scheduling strategies currently listed in the
TR to simplify the understanding and highlight similarities between different proposals.
7.1.5.1 Node B Controlled Rate Scheduling by Fast TFCS Restriction Control

The basic mechanism used in this approach allows the Node B to expand/reduce the “Node B controlled TFC subset”
e.g. one step at a time by differential up/down commands sent on the downlink from the Node B. The update is valid
until the next update received from the Node B. Transmissions from different UEs may overlap in time.
7.1.5.2 Node B Controlled Time and Rate Scheduling

The basic mechanism used in this approach allows the Node B to update the “Node B controlled TFC subset” to any
allowed value through explicit signaling specifying the new “Node B controlled TFC subset”, the start time and the
validity period. The validity period is short, in the order of milliseconds, where after the “Node B controlled TFC
subset” reverts to the value prior to the scheduling period. Updates of the “Node B controlled TFC subsets” for different
UEs are coordinated by the Node B in order to avoid transmissions from multiple UEs overlapping in time to the extent
possible.
For UEs with low delay tolerance services, a deterministic cooperative approach for time and rate scheduling may be
possible for example utilising congestion-based Comparative Metric (CM) described in Section 7.1.2 to decide which
UE should transmit ,when and at what data rate.
7.2 Hybrid ARQ

7.2.1 General
Node B controlled hybrid ARQ allows for rapid retransmissions of erroneously received data units, thus reducing the
number of RLC retransmissions and the associated delays. This can improve the quality of service experienced by the
end user. As a Node B controlled retransmission is less costly from a delay perspective, the physical channel can be
operated with somewhat higher error probability than in Rel 5, which may result in improved system capacity. The
retransmission probability for the initial transmission is preferably in the order of 10-20% when evaluating hybrid ARQ
as closed loop power control is used for the uplink, maintaining a given quality level. Significantly higher
retransmission probabilities may lead to considerably reduced end user throughput, while at very small retransmission
probabilities the Node B controlled hybrid ARQ will not provide any additional gains compared to R99/4/5. Soft
combining can further improve the performance of a Node B controlled hybrid ARQ mechanism.
Not all services may allow for retransmissions, e.g., conversational services with strict delay requirements. Hybrid ARQ
is thus mainly applicable to interactive and background services and, to some extent, to streaming services.
Thus, the major targets from a performance point of view with hybrid ARQ to consider in the evaluation of uplink
hybrid ARQ are
3GPP
Release 6 27 3GPP TR 25.896 V2.0.0 (2004-03)
- reduced delay
- increased user and system throughput
The design of an uplink hybrid ARQ scheme should take the following aspects into account:
- Memory requirements, both in the UE and the Node B. Rapid retransmissions reduce the amount of buffer
memory required in the Node B for buffering of soft bits when a retransmission has been requested.
- Low overhead. The overhead in terms of power and number of bits required for the operation of the hybrid
ARQ protocol should be low, both in uplink and downlink. Note that, unlike the HS-DSCH, the number of
simultaneous users employing hybrid ARQ for transmitting data in the uplink may be significant, stressing the
fact that the overhead for each user needs to be kept at a minimum.
- In-sequence delivery. The RLC requires in sequence delivery of MAC-d PDUs. Note that the in sequence
delivery mechanism can be located either in the Node B or the RNC, depending on the scheme considered.
- Operation in soft handover. In soft handover, data is received by multiple Node Bs and alignment of a user’s
protocol state among different Node Bs needs to be considered. This problem is not present for the HS-DSCH,
were reception occurs at a single node, the UE. Therefore, the feasibility of different modes of hybrid ARQ in
conjunction with soft handover needs to be studied and, if found feasible, the cost of the required signaling
investigated.
- Multiplexing of multiple transport channels. Hybrid ARQ cannot be used by all transport channels and
multiplexing of transport channels using hybrid ARQ and those not using hybrid ARQ needs to be considered.
In the downlink, there is a separate CCTrCh carrying the HS-DSCH, while the assumption of a separate
CCTrCh is not necessarily true in the uplink scenario. In R99/4/5, only a single uplink CCTrCh is allowed.
- UE power limitations. The operation of the UE controlled TFC selection for R99/4/5 channels need to be taken
into account in the design. In particular, UE power limitations in conjunction with activity on other transport
channels with higher priority should be considered.
- Complexity. The hybrid ARQ schemes studied should minimize as much as possible the additional
implementation complexity at all involved entities.
7.2.2 Transport Channel Processing

A protocol structure with multiple stop-and-wait hybrid ARQ processes can be used, similar to the scheme employed
for the downlink HS-DSCH, but with appropriate modifications motivated by the differences between uplink and
downlink. The use of hybrid ARQ affects multiple layers: the coding and soft combining/decoding is handled by the
physical layer, while the retransmission protocol is handled by a new MAC entity located in the Node B and a
corresponding entity located in the UE.
ACK/NAK signaling and retransmissions are done per uplink TTI basis. Whether multiple transport channels using
hybrid ARQ are supported and whether there may be multiple transport blocks per TTI or not are to be studied further.
The decision involves e.g. further discussion whether the current definition of handling logical channel priorities by the
UE in the TFC selection algorithm remains as in R99/4/5 or if it is altered. It also involves a discussion on whether
different priorities are allowed in the same TTI or not. The R99/4/5 specifications require a UE to maximize the
transmission of highest priority logical channel in each TTI. If this rule is maintained, the delay for different logical
channel priorities could be different, depending on whether the TFCS contains one or several transport channels.
Channel coding can be done in a similar way as in the R99/4/5 uplink. Transport blocks are coded and rate matching is
used to match the number of coded bits to the number of channel bits. If multiple transport channels are multiplexed,
rate matching will also be used to balance the quality requirements between the different transport channels. Note that
multiplexing of several transport channels implies that the number of bits may vary between retransmissions depending
on the activity, i.e., the retransmission may not necessarily consist of the same set of coded bits as the original
transmission.
Unlike the downlink, the uplink is not code limited and initial transmissions typically use a lower code rate than is the
case for HS-DSCH. Incremental redundancy with multiple redundancy versions is mainly beneficial at a relatively high
initial code rate. Thus, the need for support of multiple redundancy versions may be smaller in the uplink than for the
HS-DSCH. Explicit support for multiple redundancy versions, if desired, can be incorporated in the rate matching
process as was done for HS-DSCH.
3GPP
Release 6 28 3GPP TR 25.896 V2.0.0 (2004-03)
7.2.3 Associated Signaling

Associated control signaling required for the operation a particular scheme consists of downlink and uplink signaling.
Different proposals may have different requirements on the necessary signaling. Furthermore, the signaling structure
may depend on other uplink enhancements considered.
The overhead required should be kept small in order not to waste power and code resources in the downlink and not to
create unnecessary interference in the uplink.
Downlink signaling consists of a single ACK/NAK per (uplink) TTI from the Node B. Similar to the HS-DSCH, a well-
defined processing time from the reception of a transport block at the Node B to the transmission of the ACK/NAK in
the downlink can be used in order to avoid explicit signaling of the hybrid ARQ process number along with the
ACK/NAK. The details on how to transmit the ACK/NAK are to be studied further.
The necessary information needed by the Node B to operate the hybrid ARQ mechanism can be grouped into two
different categories: information required prior to soft combining/decoding (outband signaling), and information
required after successful decoding (inband signaling). Depending on the scheme considered, parts of the information
might either be explicitly signaled or implicitly deduced, e.g., from CFN or SFN.
The information required prior to soft combining consists of:
- Hybrid ARQ process number.
- New data indicator. The new data indicator is used to control when the soft combining buffer should be cleared
in the same way as for the HS-DSCH.
- Redundancy version. If multiple redundancy versions are supported, the redundancy version needs to be
known to the Node B. The potential gains with explicit support of multiple redundancy versions should be
carefully weighted against the increase in overhead due to the required signaling. Note that, unlike the HS-
DSCH, the number of users simultaneously transmitting data in the uplink using hybrid ARQ may be
significant.
- Rate matching parameters (number of physical channel bits, transport block size). This information is required
for successful decoding. In R99/4/5, there is a one-to-one mapping between the number of physical channel
bits and the transport block size, given by the TFCI and attributes set by higher layer signaling. This
assumption does not hold for hybrid ARQ schemes if the number of available channel bits varies between
(re)transmissions, e.g., due to multiplexing with other transport channels. Hence, individual knowledge of
these two quantities is required in the Node B.
The information required after successful decoding can be sent as a MAC header. The content is similar to the MAC-hs
header, e.g., information for reordering, de-multiplexing of MAC-d PDUs, etc.
The information needed by UE necessary to operate the hybrid ARQ mechanism is either explicitly signaled by Node B,
or decided by the UE itself, depending on the scheme. It is noted that whether the UE will decide the parameter values
or the Node B will signal them, could affect the round trip time for HARQ retransmissions.
7.2.4 Operation in Soft Handover

The support of hybrid ARQ in different forms in soft handover requires careful consideration. In one possible scheme,
all Node Bs serving the UE process the received data and transmit ACK or NAK to signal the result. If the UE does not
receive an ACK from any of the involved Node Bs, it will schedule a retransmission. Otherwise, the transport block(s)
will be considered as successfully transmitted and the UE will increment the new data indicator to signal to all involved
Node Bs that the new data should not be soft combined with previous transmissions. To ensure that all involved Node
Bs have the possibility to decode the transmission, regardless of the result from earlier transmissions, self-decodable
transmissions are preferable.
A major problem with Node B controlled hybrid ARQ in soft handover is the link imbalance. Since the associated up-
and downlink signaling does not benefit from the soft handover gain, it might be error-prone and/or require significant
power offsets. Therefore, the feasibility of hybrid ARQ in soft handover situations should be investigated, taking the
power required for control signaling into account. Protocol robustness in presence of signaling errors needs to be
considered and additional protection of the control signaling may be required.
3GPP
Release 6 29 3GPP TR 25.896 V2.0.0 (2004-03)
In the downlink direction, the UE may not be able to receive the ACK/NAK signals from all involved Node Bs. The
consequences of downlink ACK/NAK errors are similar to the uplink ACK/NAK errors studied for HS-DSCH and it
should be studied whether solutions similar to those used for HS-DSCH are applicable.
In the uplink direction, not all involved Node Bs may be able to receive the associated control signaling from the UE,
which may lead to unsynchronised soft buffers between different Node Bs. This could result in erroneous combining of
new packets with previously stored packets that have not been flushed. One possibility to reduce the occurrence of
erroneous combining could be to increase the reliability of the uplink HARQ control signaling. This could be for
example done by power offsets or by increasing the number of bits for the New Data Indicator thus making a wrap
around of the NDI less likely. An alternative could be to operate without soft combining in soft handover situations,
removing the need for reliable outband signaling of the new data indicator and the hybrid ARQ process number. More
robust inband signaling can be used for these quantities instead. Node B controlled ARQ without soft combining could
be considered in non-soft-handover as well, if clear gains are seen only from the ARQ mechanism and not from the soft
combining itself. Another possibility, preserving support for hybrid ARQ with soft combining in soft handover, could
be to synchronize the NodeB's soft buffer content via additional network signalling or to locate the soft buffer in the
Node B and the final ACK/NAK decision in the RNC. This technique allows the RNC to align the soft buffer status in
each Node B and may benefit from the soft handover gain for the related hybrid ARQ control signaling, but the delays
will be larger than for a pure Node B controlled scheme.
7.3 Fast DCH Setup Mechanisms

7.3.1 Background
Possible enhancements include, but are not limited to, the physical layer random access procedures, NBAP/RRC
signaling, and uplink/downlink synchronization procedures. Any enhancement, or combination of enhancements, to the
procedures for fast DCH establishments should fulfill the following requirements:
- Allow for significant reduction in switching delays.
- Fit into the connection state model and, to the extent possible, reuse existing procedures and techniques.
- Allow for unaffected operation of existing UEs and Node Bs
7.3.2 Reducing Uplink/Downlink Synchronization Time

Establishing a DCH requires the UE and Node B to synchronize the physical up- and downlink channels as briefly
described in Section 6.1.1. Techniques to reduce the downlink and/or uplink synchronization time should be studied as
a part of the overall goal of reducing the delays associated with DCH establishment.
The overall delay from t1 to t7 in Figure 6.1.2 depends both on the implementation, the performance requirements on the
UE, and the procedures in the 3GPP specifications. T1 and T2 mainly depend on network implementation. T3 depends
on the TTI used for FACH, which could be shortened at the cost of a reduced interleaving gain, and the UE processing
delays. In this section, a technique for reducing T4, accounting for 40+(N312-1)*10 ms delay, where N312=(1, 2, 4, 20,
50, 100, 200, 400, 600, 800, 1000) and T5, accounting for 10-70 ms delay, by using an improved synchronization
scheme is proposed.
The proposed enhancement is illustrated in Figure 7.3.1. The basic idea is to replace the presently defined DPCCH
uplink and downlink synchronization scheme requiring a time interval T4+T5 (specified in [14]) with an enhanced
scheme reducing this time to 10 ms. A power ramping procedure is used, where the power of the uplink DPCCH is
ramped up from a calculated initial power level by sending power up commands from the Node B until the Node B has
obtained synchronization to the uplink signal. Acquisition of the uplink signal is indicated to the UE on the downlink
DPCCH simply by sending power down commands. In the radio frame following the power control preamble, data
transmission on both uplink and downlink DPDCH can start.
InFigure 7.3.2, the power ramping phase is illustrated in more detail. Downlink and uplink DPCH transmission shall
start at the same frame number, which shall be indicated in the switching message to the UE. Note that the UE already
has received data on the S-CCPCH and thus is synchronized to the network, and the relative timing between downlink
DPCH and S-CCPCH is known from L3 signaling, In Figure 7.3.2, downlink transmission starts at time instant t1
(which corresponds to t4 = t5 in Figure 7.3.1), with some offset relative to the frame timing of the CPICH. The offset is
indicated to the UE in the switching command. Uplink transmission shall start with a timing offset relative to the
3GPP
Release 6 30 3GPP TR 25.896 V2.0.0 (2004-03)
downlink DPCH, i.e., at t1+T0+τ, where τ is the delay of the first detected path measured on CPICH and T0 = 1024 chip
intervals, as specified in [14]
For uplink ramping, a predefined setting of all DPCCH bits is preferably used to make it possible to collect all
transmitted energy for initial synchronization in the Node B receiver without caring on modulation. Uplink DPCCH
power is ramped up with one step per slot. In the ramping phase, downlink TPC bits from the Node B should be set to
“up”. As soon as the Node B receiver has been reliably synchronized to the uplink, the Node B shall enter power
control operation, i.e., transmit up/down power control commands and evaluate the TPC information received on the
uplink DPCCH (time instant t2 in Figure 7.3.2). In-sync detection is tested in Node B similarly as for PRACH
preambles based on thresholds. The UE is informed when Node B obtains in-sync through the TPC pattern received on
the downlink.
Note that the Node B uplink receiver can collect the energy for the entire ramping phase, not only the energy of the last
slot. Furthermore, as there is no modulation present on the DPCCH, it is possible to achieve a very large processing
gain at the receiver, equal to all 2560 chips (34 dB). This allows for very power efficient, highly secure detection of the
DPCCH transmission in the Node B. One possibility is to use peak detection in long-term delay power spectrum
estimations, which for instance can be calculated with a matched filter.
The initial downlink DPCCH power level is determined in the same fashion as in the present procedure, i.e., by using
the initial downlink DPCH power level IE present in the “Radio Link Setup/Addition Request” messages. Setting of the
initial power is implementation dependent. If prior information on the distance between UE and Node B or a path loss
measurement is available in the RNC, this can be used for more tight setting of the initial downlink DPCCH power
level. If no distance or path loss information is available, a “broadcast power level” needs to be employed. To secure
reception of the downlink DPCCH, its initial power should in any case be chosen somewhat higher than needed
according to pre-calculations. This means that as soon as the inner power control loop starts operation (time instant t2 in
Figure 7.3.2), it is very likely that downlink power is ramped down first. In the proposed fast synchronization scheme,
setting of initial downlink power is much less critical than in the Rel99/4/5 scheme as a somewhat too high power
would be employed only for a very short time interval.
DPCH setup failure in the Node B is identified when no uplink synchronization is obtained within the preamble period.
In the case, the downlink DPCCH transmission should be stopped at the end of the preamble interval. Stop of downlink
transmissions shall be identified in the UE by means of a fast DL DPCCH synchronization status detection scheme and
stop further uplink transmissions. Further handling of DPCH setup failure could be done in several ways. For instance, a
new attempt could be made a predefined time after the first try. Alternatively, the physical channel reconfiguration
failure procedure as defined in [15]. could apply also for this new scheme.
Introducing enhancements such as those described above can be done by defining “Synchronization Procedure C” in
addition to procedures A and B already specified in [14]. The impact on higher layers, the interaction with power
control, and in which scenarios a new synchronization procedure may be applied are for further study.
3GPP
Release 6 31 3GPP TR 25.896 V2.0.0 (2004-03)
switching
Power decision (RRC/SRNC)
DPCCH
downlink DPCH
switching DPCH
command
SCCPCH
confirm
uplink DPCH
T4=
T1 T2 T3 T5 T6
Cell_FACH Cell_DCH
t1 t2 t3 t4 = t6 t7
t5
Figure 7.3.1: Enhanced procedure for DCH establishment.
closed-loop power controlled transmission

data transmission
power ramping DPDCH
UL DPCH
DPCCH
slot
(0.667 ms)
10 ms-radio frame (SFN ) 10 ms-radio frame (SFN + 1)
PCCH at DL DPCH
nitial power
evel
DL-UL offset
t1 T0 + τ t2 t3
start of first acquisition of UL DPCH, end of first
frame start of power control frame
Figure 7.3.2: Illustration of the enhanced uplink/downlink synchronization scheme.
7.4 Shorter Frame Size for Improved QoS

Reducing the minimum TTI supported from the 10 ms in Rel5 to a lower value may reduce the transfer delay through a
reduced Uu transfer delay and reduced delays due to TTI alignment (incoming data to be transmitted has to wait until
the start of the next TTI). A reduced TTI may also allow for reduced processing time as the payload sizes are reduced
compared to a larger TTI, a shortened roundtrip time in Node B controlled hybrid ARQ protocols and reduced latencies
in some scheduling schemes. Reduced delays may also result in a higher system throughput and better resource
utilization.
3GPP
Release 6 32 3GPP TR 25.896 V2.0.0 (2004-03)
Thus, the major targets from a performance point of view with a reduced uplink TTI are:
- improved end-user quality
- increased user and system throughput
- significant delay reduction
The introduction of a reduced TTI should take the following aspects into account:
- End-user delay. Any reduced TTI considered should result in the possibility for a significant reduction in
uplink delay while still support reasonable payloads.
- Choice of shorter TTI. It is preferable if the Rel5 minimum TTI of 10 ms is a multiple of the reduced TTI
considered. The obvious choice is a 2 ms TTI, which also is an alignment to the short TTI adopted for HS-
DSCH.
- Link performance. The influence of a short TTI on link performance need to be considered.
- Channel structure. Support of services and applications using Rel5 channels should be considered. The
operation of UE controlled TFC selection need to be taken into account. Any increase in UE peak-to-average
ratio should be analyzed and kept low.
- Complexity. Any complexity increase due to a reduced TTI should be clearly motivated by a corresponding
performance gain.
7.5 Signalling to support the enhancements

7.5.1 Downlink signalling
7.5.1.1 Basic considerations

It can be assumed that the operation of enhanced uplink DCH requires some new signalling in downlink direction.
Whether this would be (hybrid) ARQ related, scheduling related, or something else is for further discussion.
There are some requirements for the physical channel structure for L1 signalling in downlink:
− The L1 signalling in downlink should be independent from HS-DSCH operation: UE should not be required to
support HS-DSCH operation at the same time with E-DCH in uplink, but it should be possible to have E-DCH
in uplink and HS-DSCH in downlink at the same time.
− Delays should be kept low.
− Signalling should be possible also when the UE's DCH is in SHO. The support of E-DCH in SHO is FFS.
− Signalling reliability and overhead should be considered.
− Signalling peak power and average power requirements in the downlink should be considered.
7.5.1.2 Downlink signalling multiplexed on existing channel

Embedding the enhanced uplink signaling bits into an existing downlink code channel could be done e.g. by:
− Puncturing DPDCH bits
− Introducing a new downlink DPCH slot format (e.g. by creating a separate DPCCH field)
− Other means introducing space for the signalling bits in the DPCH
Multiplexing the signalling on the existing channel does not consume additional downlink codes or require the UE to
receive any additional code channels. However, additional DPDCH power is required in order to compensate the lost
energy of the DPDCH bits stolen for signaling which may result in additional downlink interference. Further, all the
3GPP
Release 6 33 3GPP TR 25.896 V2.0.0 (2004-03)
designs typically face a tradeoff between the required power for the signalling bits and number of DPCH bits used for
signalling.
7.5.1.3 Downlink signalling on a new code channel

The enhanced uplink signaling bits could be sent on a new downlink code channel e.g. by:
− Introducing a new dedicated code channel for each UE for the signalling
− Introducing a new shared code channel(s) for the signalling
Introducing a new dedicated or shared code channel(s) does not require modification of the existing channel structure.
However, it consumes additional downlink code(s) as well as requires the UE to receive additional code channel(s). On
a shared code channel, signalling for multiple UEs could be multiplexed on a same shared code channel. One method of
the multiplexing is to allocate mutually orthogonal symbol patterns to identify and carry signaling for each UE (i.e.
code multiplexing). The other method is to allocate different time periods to identify and carry signaling for each UE
(i.e. time multiplexing). Combination of both time and code multiplexing is also possible. Transmission of the signaling
in new code channel(s) also requires additional downlink transmit power and hence may result in additional downlink
interference.
7.5.2 Uplink signalling
7.5.2.1 Basic considerations

Operation of enhanced uplink DCH may also require signalling in the uplink direction. Whether this would be (hybrid)
ARQ related, scheduling related, or something else is for further discussion.
There are some requirements for the physical channel structure for L1 signalling on uplink:
- The L1 signalling in uplink should be independent from HS-DSCH operation: UE should not be required to
support HS-DSCH operation at the same time with E-DCH in uplink, but it should be possible to have E-
DCH in uplink and HS-DSCH in downlink at the same time.
- Delays should be kept low.
- Signalling should be possible also when the UE's DCH is in SHO. The support of E-DCH in SHO is FFS.
- The effect of PAR needs to be taken into consideration when designing signalling channel for the uplink.
- The relative power offsets between various uplink channels needs to be set appropriately so as to achieve
reliable signalling while at the same time optimising peak and average power requirements at the UE.
- Signalling reliability should be balanced with minimizing overhead.
- Signalling channel can be sent time aligned or not time-aligned with the enhanced uplink DCH. The effect
of time aligned or not time aligned control channel on Node-B decoding time, sector throughputs etc.
should be considered.
7.5.2.2 Coding, multiplexing and mapping options

Table 7.5.2 provides a list of parameters and possible options related to coding, multiplexing and mapping of the UL
signalling. All of these options can be combined and the value of each combination could be evaluated. Some of the
resulting combinations are described and evaluated in section 9.2.4
3GPP
Release 6 34 3GPP TR 25.896 V2.0.0 (2004-03)
Table 7.5.2: UL signalling coding, multiplexing and mapping options

Parameter Options Comments
TTI 10 ms / 2 ms 2 ms is to illustrate a shorter TTI value
Transmission prior to E-DCH transmission provides
Timing relative to possibility for early decoding procedure, but implies
Aligned / prior
E-DCH transmission longer HARQ delays or reduced processing time in
the UE
CRC Yes / no
Repetition coding allows for early UL signalling
CC / Block / Repetition /
Coding decoding and may reduce buffering requirement in
Hybrid
the Node B
(E-)DPDCH and DPCCH mapping are described in
section 7.5.2.2.1 and 7.5.2.2.2 respectively.
(E-)DPDCH / DPCCH /
Mapping Mapping the control bits on a new code channel is
E-DPCCH
described in section 7.5.2.2.3; using SF=256 allows
mapping of UL signalling bits with either 2 ms or
10 ms TTI.
7.5.2.2.1 Mapping on (E-)DPDCH

The UL signalling bits could be mapped on the DPDCH or E-DPDCH using one of the approaches described in table
7.5.3.
Table 7.5.3: UL signalling mapping options on DPDCH

Mapping option Applicable Backward Payload Comments
TTI compatible
Described in section 7.5.2.2.1.1.
Implies that the UL signalling
DPDCH as a TrCH 10 Yes Large
transmission is frame aligned with the
DPCH.
This approach is described in section
(E-)DPDCH with TDM 2/10 (Yes) Large
8.4.1.1.2.2.
7.5.2.2.1.1 Mapping on DPDCH using a TrCH
Assuming 10 ms TTI, the UL signalling bits can be mapped on the DPDCH using an in-band signalling approach. UL
signalling is therefore considered as a regular transport channel and is multiplexed with other transport channels and
mapped on the DPDCH. The UL signalling error rate can be controlled by adjusting the rate matching parameter and
adding a CRC.
The Node-B procedure for E-DCH decoding is hierarchical in the sense that the Node B first has to decode the DPDCH
to have access to the UL signalling bits and subsequently decode the E-DPCH. From a layering point of view this
approach implies that a transport channel would be terminated at the Node-B. The only new requirement on the Iub is a
mean to signal that a particular TrCH contains the UL signalling bits.
One significant benefit with this approach is the backward compatibility with earlier releases. Indeed the UL signalling
bits are received as any other TrCH by the legacy Node B and the RNC can simply discard the data or even use it for
resource management.
7.5.2.2.2 Mapping on DPCCH

The UL signalling bits could be mapped on the DPCCH using one of the approaches described in table 7.5.4.
3GPP
Release 6 35 3GPP TR 25.896 V2.0.0 (2004-03)
Table 7.5.4: UL signalling mapping options on DPCCH

TTI compatible
Straightforward approach. Implies that
Rel-5 TFCI approach 10 (Yes) <8 bits the UL signalling transmission is frame
aligned with the DPCH.
Replication of downlink approach in
Split mode TFCI 10 No <8 bits the uplink. May not need frame
alignment with DPCH (FFS)
Impacts performance of DPCH and
Bit stealing (e.g. FBI) 10 (Yes) Small may prevent use of existing features
(e.g. closed loop diversity or SSDT)
Offers the most flexibility at the price
New slot format(s) 2/10 No Unlimited
of backward compatibility.
7.5.2.2.3 Mapping on a new code channel

This approach consist in mapping the UL signalling bits on a new physical code channel. Table 7.5.5 provides a
summary of the key aspects of such approach.
Table 7.5.5: UL signalling mapping options on new code channel
TTI compatible
Straightforward approach which offers
a maximum of flexibility and is fully
New code channel 2/10 Yes Unlimited
backward compatible. Potential PAR
issues.
7.6 Miscellaneous enhancements

7.6.1 Support for enhanced channel estimation
Degraded performance of channel estimation leads to an increased SNR requirement for the same BLER target. For the
higher data rates conceived for E-DCH, any reduction in the high SNR requirement could lead to higher system
capacity. One possible technique to reduce the required SNR is to allow for better channel estimation techniques at the
receiver. L1 techniques to facilitate better channel estimation at the receiver should be considered. These include:
- Transmission of additional pilot energy
- Data aided channel estimation
- Modified power control procedure
To justify the use of any L1 based enhanced channel estimation techniques, the following studies must be conducted.
- Incremental benefit of any enhanced L1 scheme over existing mechanisms
o Impact on link performance
o Impact on system capacity
- Impact on PAR and associated cell coverage
- Impact on receiver complexity
- Backward compatibility
3GPP
Release 6 36 3GPP TR 25.896 V2.0.0 (2004-03)
8 Physical Layer Structure Alternatives for Enhanced

Uplink DCH
8.1 Relationship to existing transport channels

It remains to be determined whether there will be a new transport channel added to RAN specification. Uplink
enhancements may
- consist of methods limited on improving the utilization of existing transport channels or
- introduce methods that require new transport and physical channels
In order to encompass both possibilities, the transport channel is referred here as E-DCH.
8.1.1 Transport Channel Structure

To support some of the enhancements currently under consideration, a new transport channel type, the E-DCH, is
introduced. Depending on future decisions on which enhancements to support and how to support them, the E-DCH
may or may not be identical to the DCH.
In order to find a suitable structure for supporting the E-DCH, there are some issues that need to be addressed:
- The number of E-DCHs supporting simultaneous transmission
- Static or semi-static TTI.
- One or multiple CCTrCHs. Either one or multiple uplink CCTrCHs are required, depending on the physical
channel structure adopted.
In Figure 8.1.1, a generic structure is illustrated, not making any particular assumption on the number of CCTrCHs, E-
DCHs or the TTIs supported. For E-DCHs using (hybrid) ARQ, a new MAC-e entity is introduced to handle the
retransmission protocol in a similar way as for HS-DSCH. In any scheme with more than one MAC-e, there will be a
dependency between the MAC-e entities as, according to section 7.2.3, a single ACK/NAK per uplink TTI is used.
Thus, if multiple E-DCHs are supported, a retransmission request is valid for all E-DCHs using hybrid ARQ in the
corresponding interval.
3GPP
Release 6 37 3GPP TR 25.896 V2.0.0 (2004-03)
Logical channels
MAC-d
MAC-d flows
MAC-e MAC-e
E-DCH E-DCH DCH
Processing
Processing
Processing
Transport
Transport
Transport
Channel
Channel
Channel
TrCH multiplexing TrCH mux
CCTrCH
Mapping to phy channel(s)
Figure 8.1.1: Simplified illustration of possible transport channel structures.
8.1.1.1 Number of E-DCHs

Supporting only one E-DCH may simplify transport channel multiplexing and reduce the amount of additional outband
signaling. MAC layer multiplexing may be used to support (simultaneous) transmission of multiple MAC-d flows
(possibly with different priorities) into a single transport channel. Inband signaling may be used for separating the
received data into different MAC-d flows instead of relying on the TFCI.
Supporting multiple E-DCHs may allow for greater flexibility but may require more outband signaling compared to a
single E-DCH. One E-DCH can be set up for each MAC-d flow. Outband TFCI signaling is used to demultiplex the
received data into multiple transport channels/MAC-d flows.
The interaction with TFC selection needs to be considered. According to Rel5, logical channels in the uplink have
absolute priority, i.e., the UE shall maximize transmission of high priority data in each TTI. Whether this rule is to be
maintained for the E-DCH or not is FFS, although the TFC selection needs to take both DCHs and E-DCHs into
account. If the Rel5 principle is retained, TFC selection and MAC-e (if applicable) multiplexing must be jointly
designed in order not to “starve” low-priority MAC-d flows.
8.1.1.2 TTI
A static TTI, i.e., the specifications mandates a single TTI value to be supported by the E-DCH, may simplify the
processing. Obviously a static TTI will prohibit the use of (hybrid) ARQ in conjunction with TTIs other than the one
specified for E-DCH.
A semi-static TTI, i.e., the network configures the TTI to use when configuring the E-DCH, is in line with other Rel5
transport channels and may be useful in some situations.
3GPP
Release 6 38 3GPP TR 25.896 V2.0.0 (2004-03)
8.2 TTI length vs. HARQ physical channel structure

Two different TTIs have been mentioned in conjunction with uplink enhancements: either reusing the existing R99
10 ms TTI or introducing a shorter (e.g., 2 ms) TTI:
- Using a 10 ms TTI allows for reusing the R99 DPDCH structure, including baseband processing and TFCI
signaling. The drawback is the, compared to a shorter TTI, larger delays. Using QPSK in the uplink can lead to
an increase in PAR, although the value of the PAR increase remains to be investigated.
- Using a 2 ms TTI allows for reduced delays. The drawback is the need for a new physical layer frame structure
and TFCI-like signaling. The most straightforward way of supporting a short (2 ms) TTI seems to be the
introduction of a new code multiplexed physical channel in the uplink. Using additional codes in the uplink can
lead to an increase in PAR, although the value of the PAR increase remains to be investigated.
These TTI lengths of 10 ms and 2 ms are considered here as examples.
If E-DCH utilizes physical layer HARQ, there is a need to transmit ACK/NACK signaling in a downlink physical
channel. N defines the minimum number of HARQ processes required to provide continuous transmission. However,
increasing the number of HARQ channels also adds to round trip time and thus N cannot be arbitrarily large. A
compromise between round trip time and processing time is of main importance when considering the selection of N.
If the available time for downlink signaling and UE/Node B processing is made long enough through suitable selection
of N, ACK/NACK could be embedded in existing Rel’99 downlink channel structure, i.e. within a 10 ms TTI. Another
option is to reserve a specific field shorter than 10 ms time period, in a downlink physical channel for ACK/NACK as is
done in HS-DPCCH for uplink in Rel’5 HSDPA. The downlink ACK/NACK field length is naturally independent of
TTI length in uplink.
Figure 8.2.1 depicts the general concept of timing for E-DCH HARQ process. After having received transport block(s)
on E-DCH the Node B has TNBP for processing and sending acknowledgement to the UE. In here no assumption is made
on which downlink physical channel the ACK/NACK in DL would be sent. Based on the acknowledgement and
possible other information provided by the UTRAN, the UE decides whether it resends the transport block(s) or
transmits new transport block(s). The processing time available for the UE between receiving the acknowledgement and
transmitting the next TTI in the same HARQ process is TUEP.
The length of the acknowledgement field in DL directly affects the available processing time in Node B and UE. The
length of the acknowledgement field might also affect the required power offset for transmitting it, relative to DL
DPCCH, depending on the scheme. With 10 ms TTI and high enough N, acknowledgement could e,g, be embedded in
existing multiplexing structure within a 10 ms TTI. This might allow more space for coding and smaller power offset
for transmitting ACK/NACK than in the case where ACK/NACK is inserted into downlink physical channel within a
shorter time period than 10ms.
T0
TTI
Physical channel UE channel 1 UE channel 2 UE channel 3 UE channel 1 UE channel 2

carrying [E]-DCH at
UE
Physical channel UE channel 1 UE channel 1 UE channel 2

carrying [E]-DCH at
Node B
DL physical channel Tprop

carrying ACK/NACK ACK/NACK
at Node B
TNBP
DL physical channel ACK/NACK
carrying ACK/NACK
at UE TUEP
Tprop
TACK
Figure 8.2.1. HARQ timing schematic for N=3, TTI=10 ms, as an example.
3GPP
Release 6 39 3GPP TR 25.896 V2.0.0 (2004-03)
Table 8.2.1 presents some estimations for available processing time TTI lengths 10 ms and 2 ms, with N=2,3,4,5. The
timing calculations assume a roundtrip delay of 0.1 ms. The acknowledgement signal from the Node B may be spread
over one of more slots. However, the longer TACK becomes, the less processing time there is available for UE and RNS.
For TTI=10 ms case, a TACK = 10 ms is possible if N=3 or larger. With TTI=2 ms, TACK necessarily has to be shorter.
Table 8.2.1. Examples of UE and Node B processing times with E-DCH
TTI length (ms) N Tack (ms) TNBP+TUEP (ms)
10 2 2 7.9 (0.8xTTI)
10 3 2 17.9 (1.8xTTI)
10 3 10 9.9 (1.0xTTI)
10 4 2 27.9 (2.8xTTI)
10 4 10 19.9 (2.0xTTI)
2 4 2 (3 slots) 3.9 (1.95 x TTI)
2 5 2/3 (1 slot) 7.23 (3.6xTTI)
2 5 4/3 (2 slots) 6.56 (3.3xTTI)
2 6 4/3 (2 slots) 8.56 (4.3xTTI)
2 6 2 (3 slots) 7.90 (4.0xTTI)
2 7 2 (3 slots) 9.90 (5.0xTTI)
The table shows examples of the total time available for UE and Node B processing in the case of implicit scheduling.
Thus, the figures in Table 8.2.1 represent minimum round trip time. Other methods with e.g. additional control channels
would increase the round trip time or reduce available processing time. These methods are investigated separately. Note
that the length of the E-DCH TTI also has an impact on the processing time needed. Since a shorter TTI contains fewer
bits than a longer one, the processing load for baseband processing such as interleaving and turbo decoding is smaller
and less time is consumed. On the other hand, interleaving gain is impacted when short TTI length is employed.
The choice of TTI and N should be done in conjunction with selecting the structure of the downlink ACK/NAK
transmission. Furthermore, the maximum data rate supported will affect the required processing times. Herein, the
assumption that maximum data rate would be around 1-2Mbit/s was used.
More detailed analysis of the required processing times are needed in the future, but this gives some rough estimate how
the TTI length affects the HARQ physical layer structure. In addition to processing times, important issues to consider
are the physical layer structure for sending the L1 signaling in uplink and downlink, and the performance and
complexity related to that.
8.3 Multiplexing alternatives in general

This chapter is describing the different alternatives of how E-DCH can be multiplexed with the existing Rel'99 channel
structures. (E-DCH is used as a general term referring to both a possible new type of transport channel and to possible
enhancements to an existing transport channel)
There are basically two different alternatives to introduce the E-DCH: it can either be time multiplexed with other
DCHs in the same way as different DCHs are multiplexed in Rel'99 or it can be code multiplexed, i.e., sent using a
dedicated code channel. These alternatives are described and discussed in the following subsections.
Issues that need to be studied when considering each multiplexing alternative are:
- Possible introduction of TTI lengths shorter than 10ms
- Possible Slot or frame synchronism for E-DCH users
- Flexibility of H-ARQ operation for both soft-handoff and non soft-handoff case.
3GPP
Release 6 40 3GPP TR 25.896 V2.0.0 (2004-03)
- Variable gain factors and modulation for E-DCH
- Peak to Average Power Ratio (PAR)
- Interoperability with Rel’99/Rel’4/Rel’5 base stations and support of existing R99/4/5 channels
- Impact of possible introduction of shorter TTI lengths to TFC selection algorithm
- Impact of possible introduction of multiple uplink CCTrCHs to higher layers
8.3.1 Reuse of current physical layer structure

In this alternative the E-DCH is time multiplexed into the same coded composite transport channel (CCTrCH) as the
other DCHs if present. The TFCI indirectly informs where and how many bits of each DCH within the CCTrCH are,
regardless of the DCH being a Rel99 DCH or an E-DCH.
Time multiplexing is easiest to implement if the TTI length is 10/20/40/80 ms, since then the Rel'99 transport channel
multiplexing chain can be used. There may naturally be some enhancements, e.g., to rate matching, to support the
potential new enhanced uplink features, e.g., hybrid ARQ.
The advantage of time multiplexing of the E-DCH with Rel99 DCHs is that no new code channels are unnecessarily
introduced. The multicode transmission would only be used for high data rates in a similar way as specified in Rel99.
This approach minimises the required peak to average power ratio (PAR) in the UE transmitter provided only one
DPDCH is used. The code channel structure of this alternative is the same than is already used in Rel'99.
It may be difficult to use higher order modulation and variable gain factors with this approach. Further, the number of
available channel bits on a DPDCH for E-DCH depends on the presence of higher priority DCH’s (e.g voice) and may
impact the flexibility of HARQ operation.
With the similar coding chain for E-DCH with Rel’99 DCH and time multiplexing scheme to a single CCTrCH, the
possibilities of decoding E-DCH in Rel’99/Rel’4/Rel’5 Node Bs could be considered even though no soft combining is
performed in those Node Bs. This kind of backward compatibility can increases the macro diversity gain in SHO,
especially when previous release Node Bs are included in the active set.
8.3.2 Allocating a separate code channel for Enhanced uplink DCH

In this alternative the E-DCH is code multiplexed with other DCHs, i.e., sent using a dedicated code channel, thus
introducing a new CCTrCH in the uplink. (Note, that Rel'99 only allows one CCTrCH in the uplink per UE.)
The advantages of code-multiplexing include, among others, simpler introduction of new/shorter TTI lengths, increased
flexibility of HARQ operation , and support of adaptive modulation.
Introducing a new code channel may increase PAR in some cases which should be studied. Further, the available
resources, such as power, for the code channel carrying E-DCH depends on the presence of higher priority DCHs being
carried on the other code channels.
8.4 Multiplexing alternatives in detail

Currently there are physical channel structures under study both with 10 ms TTI and with 2 ms TTI. Here all the
possible structures are explained shortly, and also the main difference compared to other structures.
The main assumptions are:
- The maximum possible data rate allocated to DCH simultaneously with E-DCH can be anything, up to
2Mbit/s, as long as UE capability supports the combination of DCH and E-DCH with the simultaneously
allocated bit rates. Thus no restrictions for the simultaneous data rates of E-DCH and DCH have yet been
agreed.
These assumptions should be taken into account in the channel structure descriptions in the below subsections.
Issues to be considered when any channel structures are studied and benefits and drawbacks of them are compared
further are listed below:
3GPP
Release 6 41 3GPP TR 25.896 V2.0.0 (2004-03)
- What is the maximum data rate that UE is able to utilise for E-DCH simultaneously with DCH. And what is
the maximum data rate that UE is able to utilise for DCH simultaneously with E-DCH. This type of analysis
should be made for different UE capability categories.
- What is the PAR for a certain UE capability with different structures. When PAR is analysed and compared for
different structures, it should be compared so that the total data rate for E-DCH and DCH that UE supports is
the same with both structures.
- Is it possible to utilise 8PSK in these structures, i.e. what does time multiplexing and code multiplexing of
EDCH and DCH mean in relation to 8PSK.
What is the desired structure when thinking about how the network side can allocate TFCS in an accurate way to the UE
so that UE is able to utilise maximum allocation most of the time during the allocation period.
8.4.1 Physical layer structures in time domain (TS25.212 )
8.4.1.1 General structures describing only how to multiplex DCH and E-DCH
8.4.1.1.1 Physical Layer Structure Supporting minimum TTI of 10ms
8.4.1.1.1.1 Code multiplexing between DCH and E-DCH
This could be considered, if there is a desire to have totally separate processing , i.e. rate matching etc., for E-DCH and
DCH. There are two possibilities for defining code multiplexing between E-DCH and DCH, explained below.
a) Code multiplexing between DCH and E-DCH, with separate UE capabilities for DCH and E-DCH data rate,
with the assumption that UE is able to support the combination of these data rates simultaneously. Here it is
assumed that UE capability is defined so that DCH with certain data rate is assumed to be possible to send
code multiplexed simultaneously with E-DCH, when E-DCH is transmitted at maximum data rate that UE
supports for E-DCH. Figure 8.4.1 depicts this case with an example.
This scheme assumes that there are two CCTrCHs, one carrying DCHs , the other carrying EDCHs.
Carries only DCHs with 10 ms or n* 10ms TTI It is possible that there is

sometimes no data
transmitted either on
DPDCHs carrying DCH or
Carries only EDCHs with 10 ms TTI
DPDCHs carrying EDCH.
DPDCH 1
DPDCH 2
…
….
DPDCH i
DPDCH i+1
Figure 8.4.1. An example showing code multiplexing with separate UE capabilities for DCH and E-DCH , with
minimum TTI=10 ms for E-DCH. Here the transmission of DCH does not decrease the data rate of E-DCH.
b) Code multiplexing between DCH and E-DCH assuming there are following UE capability parameters defined:
- UE capability for the total data rate of DCH and E-DCH
- UE capability for the total number of codes that UE supports being common for DCH and E-DCH.
This scheme assumes that there are two CCTrCHs, one carrying DCHs, the other carrying EDCHs.
3GPP
Release 6 42 3GPP TR 25.896 V2.0.0 (2004-03)
This means that there are certain limitations how DCH and E-DCH can occur simultaneously. If e.g. DCH would have
higher priority than E-DCH, it would mean that DCH can occur any time, but data rate for E-DCH needs to be clearly
reduced in the frames when DCH is transmitted.
Figure 8.4.2 depicts this case with an example, where it is assumed that DCH is assumed to fit to one DPDCH code
channel, while in a generic case the maximum data rate of DCH could be anything depending on UE capability and
TFCS. Another assumption as an example in this figure is that DCH would have higher priority than EDCH. In this
example the transmission of DCH means that data rate is decreased for E-DCH in the same TTI.
Only DCHs with 10 ms or n* 10ms TTI
Only EDCHs with 10 ms TTI
On DPDCH1 it is possible
to transmit only DCHs or
EDCHs but not both at
the same time.
DPDCH 1
DPDCH 2
…
…
DPDCH i
DPDCH i+1
Figure 8.4.2. An example showing code multiplexing with UE capabilities defined in a combined fashion for E-
DCH and DCH, with minimum TTI=10 ms for E-DCH.
8.4.1.1.1.2 Time multiplexing between DCH and E-DCH
This could be considered if it is seen acceptable to have processing of E-DCH and DCH done together, in rate matching
etc. This means that there is no need to change the Rel5 physical layer structure and no need to change the Rel5 TFC
selection algorithm. Thus one CCTrCH carries both DCH and E-DCH. Figure 8.4.3 depicts this with an example.
It is to be noted that in this structure, similar to rel99/rel4/rel5, if data for both DCH and E-DCH exist in the frame it
depends on the number of bits and which TrCH number is selected for DCH on which and how many DPDCHs there
are DCH bits and on which and how many DPDCHs there are E-DCH bits. This is if the current uplink TrCH
multiplexing structure is assumed.
As an example, if DCH is carried on the first TrCH, TrCH1, and if the maximum number of channel bits for DCH in the
TFCS is such that it always fits to one DPDCH with SF=4, then in the figure 8.4.3, only DPDCH1 carries both E-DCH
and DCH bits, and DPDCH2 – DPDCHi carry only E-DCH bits.
As another example, if DCH is carried still on the first TrCH, TrCH1, and if the maximum number of channel bits for
DCH in the TFCS is such that it always fits to two DPDCHs, then in the figure 8.4.3, it will vary from TTI to TTI,
depending on what is the transport format of DCH used in that TTI, which DPDCHs will carry DCH bits and which
DPDCHs will carry EDCH bits. In this example, in the TTIs in which DCH has the transport format referring to
maximum data rate of DCH, both DPDCH1 and DPDCH2 will carry DCH bits. If the transport format of DCH does not
totally fill DPDCH2, then DPDCH2 also carries some of E-DCH bits, and the rest of the E-DCH bits are carried on
DPDCH3-DPDCHx. In TTIs where DCH has zero data rate, all DPDCHs may carry E-DCH bits.
3GPP
Release 6 43 3GPP TR 25.896 V2.0.0 (2004-03)
Can carry both DCHs with 10 ms or n* 10ms TTI

and EDCHs with 10ms TTI.
DPDCH 1
DPDCH 2
DPDCH 3
DPDCH 4
…
…
DPDCH i
Figure 8.4.3. Time multiplexing with minimum TTI=10 ms for E-DCH.
8.4.1.1.2 Physical Layer Structure Supporting minimum TTI of 2ms
8.4.1.1.2.1 Code multiplexing between DCH and E-DCH
This could be considered, if there is a desire to have totally separate processing , i.e. rate matching etc. , for E-DCH and
DCH and allow 2 ms TTI for E-DCH. There are two possibilities for defining code multiplexing between E-DCH and
DCH, explained below.
a) Code multiplexing between DCH and E-DCH, with separate UE capabilities for DCH and E-DCH data rate,
with the assumption that UE is able to support the combination of these data rates simultaneously. Here it is
assumed that UE capability is defined so that DCH with certain data rate is assumed to be possible to send
code multiplexed simultaneously with E-DCH, when E-DCH is transmitted at maximum data rate that UE
supports for E-DCH. Figure 8.4.4 depicts this case with an example.
DCHs with 10 ms or n* 10ms TTI It is possible that there is

sometimes no data
transmitted either on
DPDCHs carrying DCH or
EDCHs with 2 ms TTI
DPDCHs carrying EDCH.
DPDCH 1
DPDCH 2
…
….
DPDCH i
DPDCH i+1
Figure 8.4.4. Code multiplexing with separate UE capabilities for DCH and E-DCH , with minimum TTI=2 ms
for E-DCH. Here the transmission of DCH does not decrease the data rate of E-DCH.
b) Code multiplexing between DCH and E-DCH assuming there are following UE capability parameters defined:
- UE capability for the total data rate of DCH and E-DCH
- UE capability for the total number of codes that UE supports being common for DCH and E-DCH.
3GPP
Release 6 44 3GPP TR 25.896 V2.0.0 (2004-03)
This means that there are certain limitations how DCH and E-DCH can occur simultaneously. Assuming as an example
that DCH would have higher priority than E-DCH, it would mean that DCH could occur any time, but data rate for E-
DCH needs to be clearly reduced in the frames when DCH is transmitted.
Figure 8.4.5 depicts this case with an example, where it is assumed that DCH is assumed to fit to one DPDCH code
channel, while in a generic case the maximum data rate of DCH could be anything depending on UE capability and
TFCS. Another assumption as an example in this figure is that DCH would have higher priority than EDCH. In this
example the transmission of DCH means that data rate is decreased for E-DCH in the same TTI.
DCHs with 10 ms or n* 10ms TTI On DPDCH1 it is possible

to transmit only DCHs or
EDCHs but not both at
EDCHs with 2 ms TTI the same time.
DPDCH 1
DPDCH 2
….
….
DPDCH i
DPDCH i+1
Figure 8.4.5. An example showing code multiplexing with UE capability defined in a combined fashion for E-
DCH and DCH, with minimum TTI=2ms for E-DCH.
8.4.1.1.2.2 Time multiplexing between DCH and E-DCH
Figure 8.4.3 is valid also here, in the context when it is analysed what code channels can be used in different frames for
carrying DCH and E-DCH. So it is copy pasted here and renamed as figure 8.4.6. Also the same assumptions as were
explained for figure 8.4.3 are valid here.Figure 8.4.6 depicts this with an example.
Can carry both DCHs with 10 ms or n* 10ms TTI

and EDCHs with 2ms TTI.
DPDCH 1
DPDCH 2
DPDCH 3
DPDCH 4
…
…
DPDCH i
Figure 8.4.6. Time multiplexing between 2 ms TTI E-DCH with 10ms TTI E-DCH.
The difference here compared to time multiplexing with minimum TTI of 10ms is that here there can be different
possibilities in terms whether there is only one CCTrCH carrying both DCH and E-DCH, or whether there is a separate
CCTrCH carrying DCH and a separate CCTrCH carrying E-DCH. Also there are different possibilities how to do the
time multiplexing. The proposals currently available for describing the actual multiplexing of DCH and E-DCH and
issues related to number of CCTrCHs are explained below:
3GPP
Release 6 45 3GPP TR 25.896 V2.0.0 (2004-03)
a) Utilising place holder bits in the transport channel multiplexing. This is described with the figure 8.4.7 below.
The idea in this is that if the EDCH(s) are the first transport channel(s) in the TFCS, the bits in the frame after
2nd interleaving will be in known positions. Thus it is proposed here that so called E-DCH ‘place holder bits ‘
will be run through TrCH multiplexing, to reserve place in these known positions. After the 2nd interleaving the
bits from EDCH(s) replace the ‘place holder bits’. This method assumes a fixed TFC during 10 ms radio
frame. It is for ffs, whether fixed TFC during 10ms radio frame will be feasible.
This scheme assumes that one CCTrCH carries both DCH and E-DCH.
E-DCH (2 ms TTI) E-DCH 'place DCH1 DCH2

holder bits'
CRC attachment CRC attachment CRC attachment
TrBk concatenation TrBk concatenation TrBk concatenation

Code block segment. Code block segment. Code block segment.
Channel coding Channel coding Channel coding
Radio frame Radio frame

equalisation equalisation
1st interleaving 1st interleaving
Radio frame Radio frame

segmentation segmentation
Rate matching/HARQ Rate matching Rate matching
TrCH multiplexing TrCH multiplexing
Physical channel Physical channel

segmentation segmentation
2nd interleaving
2nd interleaving (2 ms) (10 ms)
Physical channel
mapping
D
D
P
P
D
D
C
C
H
H
1
2
Figure 8.4.7. Time multiplexing of E-DCH (2ms TTI) and DCH (10ms TTI) with place holder bits.
b) Utilising SF reduction. This is described in the figure 8.4.8 below. The idea here is to utilise SF reduction to
create gaps in the 2ms TTI(s) in which EDCH is desired to be transmitted . This could be defined either with
two separate CCTrCHs or with one CCTrCH carrying both DCH and EDCH.
This method could be defined either with fixed TFC during radio frame, or fixed TFC during 2 ms. It is ffs
whether TFC should be fixed during radio frame or during 2 ms .
3GPP
Release 6 46 3GPP TR 25.896 V2.0.0 (2004-03)
”Gap” used for DCHs transmitted

E-DCHs trans. using reduced SF
Non-compressed
transmisssion of
DCHs Power increased
to compensate
for SF reduction
slot
2 ms sub-frame
10 ms frame 2 ms sub-frame
Mapped to single
set of DPDCH(s)
EDCHs DCHs Only DCHs Both E-DCHs and

transmitted DCHs transmitted
Figure 8.4.8. Time multiplexing of E-DCH (2ms TTI) and DCH (10ms TTI) with SF reduction. Whether TFC is
fixed per 10 ms or per 2 ms is ffs.
8.4.1.2 More detailed structures defining how to multiplex L1 signaling (HSDPCCH,

DPCCH, EDPCCH) with DCH and E-DCH
There are following possibilities:
- Time multiplexing at least some of the L1 signaling code channels with DCH and/or E-DCH
- Code multiplexing between L1 signaling channels and E-DCH/DCH
More detailed structures under study will be added here later on. These should be defined here so that the both
possibilities, code multiplexing or time multiplexing between E-DCH and DCH are considered.
8.4.2 Physical layer structures in code domain

In this section the cases under study for enhanced uplink DCH are described in line with TS 25.213 titled “Spreading
and modulation”. Further complexity issues, as well as backwards compatibility, need to be studied.
Cases utilizing only BPSK (Note: QPSK = 2 BPSK code channels)
Cases Description of the case Needed physical code channels
Case 1 All channels, E-DCH, DCH, HSDPCCH, DPCCH and EDPCCH DPCCH, DPDCH, E-DPDCH, HS-
are code multiplexed DPCCH, E-DPCCH
Case 2 E-DCH, DCH, EDPCCH on the same code channel (DPDCH). DPCCH, DPDCH, HS-DPCCH
Only DPCCH and HS-DPCCH on a separate code channel. Thus
EDPDCH does not exist.
Case 3 E-DCH, DCH, EDPCCH, and HS-DPCCH on the same code DPCCH, DPDCH
channel (DPDCH). Only DPCCH on a separate code channel.
Thus EDPDCH does not exist.
Case 4 E-DCH, EDPCCH, HS-DPCCH on the same code channel (E- DPCCH, DPDCH, E-DPDCH
DPDCH). DPCCH and DCH on separate code channels
Case 8 All channels, E-DCH, DCH, HS-DPCCH, DPCCH, E-DPCCH1, E- DPCCH, DPDCH, E-DPDCH, HS-
DPCCH2 and E-DPCCH3 are code multiplexed DPCCH, E-DPCCH1, E-DPCCH2, E-
DPCCH3
3GPP
Release 6 47 3GPP TR 25.896 V2.0.0 (2004-03)
Cases utilizing also 8PSK (Note: the performance of 8PSK has to be first evaluated before it can be adopted).
Cases Description of the case Needed physical code channels
Case 5 Case 2, except that it utilizes 8PSK for transmitting DPDCH if DPCCH, DPDCH, HS-DPCCH
the total number of physical channel bits from both E-DCH and
DCH would need to be accomodated on either three, six or nine
code channels of SF=4 (or SF=2).
Case 6 Case 3, except that it utilizes 8PSK for transmitting DPDCH if DPCCH, DPDCH
the total number of physical channel bits from both E-DCH and
DCH would need to be accomodated on either three, six or nine
code channels of SF=4 (or SF=2).
Case 7 Case 4, except that it utilizes 8PSK for transmitting E-DPDCH if DPCCH, DPDCH, E-DPDCH
the total number of physical channel bits from E-DCH would
need to be accomodated either three, six or nine code channels
of SF=4 (or SF=2).
The additional assumptions are:
- If time multiplexing is used between DCH and E-DCH, then multicode transmission for carrying both of them
is used only in conjunction with the lowest possible spreading factor (SF=4 or SF=2).
- If code multiplexing is used between DCH and E-DCH, the SF’s used for DPDCH and for EDPDCH are
independent of each other. Multicodes for E-DPDCH, carrying E-DCH, are utilized only with the lowest
possible spreading factor (SF=4 or with SF=2. Correspondingly for DPDCH, carrying DCH, the multicodes are
utilized only with the lowest possible spreading factor SF=4. Mapping the E-DCH on one SF=2 and one SF=4
DPCH is possible.
- Any SF can be used for code channels carrying EDCH and/or DCH, if the transport format combination is such
that it does not require multicodes.
- The figures below are generalized in the sense that the term "DPDCH" is used for denoting the physical
channels carrying both DCH and E-DCH. Furthermore, the mapping of channels not present in Rel5 to I or Q
in the figures is solely for illustrational purposes.
8.4.2.1 Case 1: Structure when using code multiplexing for all channels
The enhanced uplink consists of a new channel called Enhanced DCH (E-DCH). . The L1 signaling are sent on the E-
DPCCH. The overall structure of the enhanced uplink when all channels are code multiplexed, is shown in Figure
8.4.9. The figure is drawn so that the physical code channels are all called DPDCHs for the purpose of generalizing the
figure. Each DPDCH can carry either DCH(s) or E-DCH(s) but not both at the same time.
3GPP
Release 6 48 3GPP TR 25.896 V2.0.0 (2004-03)
cd βd
DPDCH1
(DCH)
cT βT
Σ
E-DPCCH I
ceu/d βeu/d
DPDCH3
Sdpch,n
(EDCH or DCH)
ceu/d βeu/d
I+jQ
DPDCH5
(EDCH or DCH) S
ceu βeu
DPDCH2
(E-DCH or DCH)
ceu/d βeu/d
DPDCH4
(EDCH or DCH)
ceu/d βeu/d
DPDCH6
(EDCH or DCH)
Σ Q
cc βc
j
DPCCH
chs βhs
HS-DPCCH
Figure 8.4.9. Case 1: Structure for Enhanced Uplink
8.4.2.2 Case 2: Structure when E-DCH, DCH and EDPCCH are time Multiplexed
In this structure the E-DCH, DCH, EDPCCH are time-multiplexed on the same code channel (DPDCH). Here again all
the code channels can be called DPDCHs, since E-DPDCH does not exist. Only DPCCH and HS-DPCCH are on a
separate code channel. This uplink structure is shown in Figure 8.4.10.
3GPP
Release 6 49 3GPP TR 25.896 V2.0.0 (2004-03)
cd βd
DPDCH1
(EDCH+DCH+EDPCCH)
cd βd I
DPDCH3
Σ Sdpch,n
(EDCH+DCH)
cd βd
I+jQ
DPDCH5
(EDCH+DCH) S
cd βd
DPDCH2
(EDCH+DCH)
cd βd
DPDCH4
(EDCH+DCH)
cd βd
DPDCH6
(EDCH+DCH)
Σ Q
cc βc
j
DPCCH
chs βhs
HS-DPCCH
8.4.2.3 Case 3: Structure when E-DCH , DCH and EDPCCH and HS-DPCCH are
time multiplexed
In this structure the E-DCH, DCH, EDPCCH and HS-DPCCH are time-multiplexed on the same code channel
(DPDCH). Here again all the code channels can be called DPDCHs, since E-DPDCH does not exist. Only DPCCH is on
a separate code channel. This uplink structure is shown in Figure 8.4.11.
Note, that any PAR results for this case can also be utilized for analyzing a PAR for a UE that does not support
HSDSCH, but does support EDCH, since then HSDPCCH does not exist.
3GPP
Release 6 50 3GPP TR 25.896 V2.0.0 (2004-03)
cd βd
DPDCH1
(EDCH+DCH+EDPCCH
cd βd I
Σ
+HSDPCCH)
DPDCH3
Sdpch,n
(EDCH+DCH)
cd βd
I+jQ
DPDCH5
(EDCH+DCH) S
cd βd
DPDCH2
(EDCH+DCH)
cd βd
DPDCH4
(EDCH+DCH)
cd βd
DPDCH6
(EDCH+DCH)
Σ Q
cc βc
j
DPCCH
Figure8.4.11. Case 3: Structure for Enhanced Uplink
8.4.2.4 Case 4: Structure when E-DCH, EDPCCH and HSDPCCH are time
multiplexed
In this structure the E-DCH, EDPCCH and HS-DPCCH are time-multiplexed on the same code channel (DPDCH).
Only DPCCH and DCH are on a separate code channel. This uplink structure is shown in Figure 8.4.12.
3GPP
Release 6 51 3GPP TR 25.896 V2.0.0 (2004-03)
cd βd
DPDCH1
(DCH)
ceu/d βeu/d I
DPDCH3 Σ Sdpch,n
(EDCH or DCH)
ceu/d βeu/d
I+jQ
DPDCH5
(EDCH or DCH) S
ceu βeu
DPDCH2
(EDCH +EDPCCH
+HSDPCCH) ceu/d βeu/d
DPDCH4
(EDCH or DCH)
ceu/d βeu/d
DPDCH6
(EDCH or DCH)
Σ Q
cc βc
j
DPCCH
8.4.2.5 Case 5: Structure similar to case 2, but with 8PSK included

It is similar to Case-2 except that it utilizes 8PSK for transmitting DPDCH if the total number of physical channel bits
from both E-DCH and DCH would need to be accomodated on either three, six or nine code channels of SF=4 (or
SF=2).

It is similar to Case-3 except that it utilizes 8PSK for transmitting DPDCH if the total number of physical channel bits
from both E-DCH and DCH would need to be accomodated on either three, six or nine code channels of SF=4 (or
SF=2).

It is similar to Case-4 except that it utilizes 8PSK for transmitting E-DPDCH if the total number of physical channel
bits from E-DCH would need to be accomodated on either three, six or nine code channels of SF=4 (or SF=2).
3GPP
Release 6 52 3GPP TR 25.896 V2.0.0 (2004-03)
8.4.2.8 Case 8: Structure when using code multiplexing for all channels
The enhanced uplink consists of a new channel called Enhanced DCH (E-DCH) which is mapped on a new physical
channel called E-DPDCH. The associated L1 transmission format and request signalling are mapped respectively on a
new E-DPCCH1 and E-DPCCH2 channels. Finally this structure supports a secondary pilot channel E-DPCCH3 which
enables the Node B to improve the receive performance of the uplink channels. The overall structure of the enhanced
uplink when all channels are code multiplexed, is shown in Figure 8.4.13 The figure is drawn so that the physical code
channels are all called DPDCHs for the purpose of generalizing the figure. Each DPDCH can carry either DCH(s) or E-
DCH(s) but not both at the same time.
3GPP
Release 6 53 3GPP TR 25.896 V2.0.0 (2004-03)
cd βd
DPDCH1
(DCH)
CR βR
Σ
E-DPCCH2 I
ceu/d βeu/d
DPDCH3
Sdpch,n
(EDCH or DCH)
ceu/d βeu/d
I+jQ
DPDCH5
(EDCH or DCH) S
ceu βeu
DPDCH2
(E-DCH or DCH)
ceu/d βeu/d
DPDCH4
(EDCH or DCH)
ceu/d βeu/d
DPDCH6
(EDCH or DCH)
cc βc
DPCCH
Σ
Q
chs βhs
HS-DPCCH j
CT βT
E-DPCCH1
CP βP
E-DPCCH3
Figure 8.4.13 Case 8: Structure for Enhanced Uplink
8.5 E-DCH timing

E-DCH timing should be investigated taking into account the following aspects:
- Impact on system level performance, e.g., due to the noise rise peaks caused by the partial overlap between E-
DCH transmissions from different UEs
- Relationship and impact to the Node B controlled scheduling and the hybrid ARQ
3GPP
Release 6 54 3GPP TR 25.896 V2.0.0 (2004-03)
- UE and Node B complexity for handling E-DCH transmission/reception in relation with the existing uplink
channels such as DPCCH, DPDCH, and HS-DPCCH
- Impact on UE transmit power management
It is FFS how to arrange E-DCH transmission timing. A simple approach to define E-DCH timing could be to have a
fixed timing offset with respect to the downlink DPCH timing in a similar way to Rel-99/4/5. Another alternative could
be to define E-DCH timing for all UEs with respect to a common downlink code channel, e.g., P-CCPCH so that E-
DCH TTI timing at Node B can be aligned to a certain extent.
9 Evaluation of Techniques for Enhanced Uplink
9.1 Scheduling <NodeB controlled scheduling, AMC>

9.1.1 Performance Evaluation
9.1.1.1 Comparison of Centralized and Decentralized Scheduler

In centralized scheduling, the scheduler is located in RNC, and is responsible for simultaneous scheduling of UEs
across multiple cells. Thus, it is possible to take into account the impact of each scheduled UE in all cells of its active
set. However, the drawback of such scheme is the significant scheduling delay. To reduce the scheduling delays and
take advantage of the possible fast scheduling gains, Node-B scheduling is needed. There, the scheduling is
decentralized, since the knowledge of the received signal level is available only at the scheduling Node-B, and each
Node-B schedules the UEs without considering their contribution to the other cells. Hence, there is an advantage of the
decentralized scheduling over the centralized scheduling due to the shorter delays incurred in the scheduling process
and the possibility of exploiting the fast scheduling gain, but the lack of knowledge of the impact a UE may have on the
other cells’ rise-over-thermal noise (RoT) is a disadvantage.
The following results reflect the performance comparison of the Rel-99 uplink structure and procedures with
decentralized and centralized scheduler. The results are therefore derived with 10 ms TTI, long scheduling period of
200 ms with the uplink request delay and the downlink grant delay uniformly distributed between 60 ms and 100 ms;
HARQ is not used for either of the scheduling approaches. The objective is to determine the loss due to the partial
information availability in the decentralized scheduler, without exploiting any possible fast scheduling gains, and form a
benchmark for the gains needed to be provided by faster scheduling.
The system performance is obtained for the channel mix of PA3 30%, PB3 30%, VA30 20% and VA120 20%.
Considered scheduler algorithm is Proportional Fair (PF). Scheduler related assumptions are given in Tdoc R1-031004
for centralized scheduling and in Tdoc R1-031246 for decentralized scheduler.
9.1.1.1.1 Results with Full Buffer

10 UEs with always full buffers are dropped in each cell, in a 19 Node-B, 3-cell wrap-around system layout.
3GPP
Release 6 55 3GPP TR 25.896 V2.0.0 (2004-03)
Full Buffer; Mixed Channel; 10 UEs per Cell
900
800
700
600
Cell Throughput (kbps)
500
400
300
200
100
0
0 2 4 6 8 10 12
RoT (dB)
PF Centralized PF Decentralized
Figure 9.1.1.1: Average cell throughput as a function of average RoT – Full Buffer
120.00%
100.00%
80.00%
CDF
60.00%
40.00%
20.00%
.00%
0 0.5 1 1.5 2 2.5 3 3.5
User Throughput/Average User Throughput
Figure 9.1.1.2: Fairness curve - CDF of the normalized throughput per user – Full Buffer
3GPP
Release 6 56 3GPP TR 25.896 V2.0.0 (2004-03)
12
10
8
RoT > 7dB (%)
0
3 3.5 4 4.5 5 5.5 6
Average RoT (dB)
Figure 9.1.1.3: Percentage of time the RoT is greater than 7 dB – Full Buffer
9.1.1.1.2 Results with Mixed Traffic Model

The traffic model is a mix of FTP, Near Real Time Video and Gaming users, with 12 users per cell (4 FTP, 4 Video, 4
Gaming users).
Mixed Traffic Model; Mixed Channel Model; 12 Users per Cell;
700
600
500
Throughput [kbps]
400
300
200
100
0
4.0 4.2 4.4 4.6 4.8 5.0 5.2 5.4 5.6 5.8 6.0
RoT [dB]
Centralized Decentralized
Figure 9.1.1.4: Average cell throughput as a function of average RoT – Mixed Traffic Model
3GPP
Release 6 57 3GPP TR 25.896 V2.0.0 (2004-03)
0.9
0.8
0.7
0.6
CDF
0.5
0.4
0.3
0.2
0.1
0
0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2
Throughput / Average Throughput

PF Decentralized PF Centralized
Figure 9.1.1.5: Fairness curve - CDF of the normalized throughput per user – Mixed Traffic Model
12
10
8
RoT > 7dB [%]
0
4.0 4.2 4.4 4.6 4.8 5.0 5.2 5.4 5.6 5.8 6.0
Average RoT [dB]

Centralized Decentralized
Figure 9.1.1.6: Percentage of time the RoT is greater than 7 dB – Mixed Traffic Model
9.1.1.1.3 Discussion
Based on the results presented in sections 9.1.1.1.1 and 9.1.1.1.2 it can be seen that for the same average RoT, the
centralized scheduler yields a throughput gain over the decentralized scheduler. Also, while the fairness remains the
same, the RoT overshoot (Probability {RoT > 7dB}) is higher in the case of decentralized scheduling. This happens due
to the lack of information about the interference a UE causes to the neighbouring cells. This degradation represents the
minimum benchmark for the gains to be provided by faster scheduling and other techniques that rely on faster
scheduling.
3GPP
Release 6 58 3GPP TR 25.896 V2.0.0 (2004-03)
9.1.2 Complexity Evaluation <UE and RNS impacts>
9.1.3 Downlink Signalling
9.1.4 Uplink Signalling
9.1.5 8PSK link performance

Note: Simulation assumptions behind the results in the tables below differ. Please refer to R1-040074 and R1-040049
for complete set of simulation assumptions.
Table 9.1.5.1: 8PSK to 3xBPSK link level performance comparison – Single Transmission
Channel 8PSK performance loss
TTI SF Data rate Coding rate
model BLER = 10% BLER = 20% BLER = 50%
AWGN 2 ms 4 2304 kbps 0.80 2.4 dB 2.4 dB 2.4 dB
PedA 3km/h 10 ms 4 960 kbps 0.33 1.2 dB 1.4 dB 1.5 dB
VehA 30km/h 10 ms 4 960 kbps 0.33 1.1 dB 1.3 dB 1.4 dB
Source: R1-040074, R1-040049
Table 9.1.5.2: 8PSK to QPSK link level performance comparison – Single Transmission BLER = 1%
Channel QPSK 8PSK E-DPDCH/ 8PSK perf.
TTI SF Data rate
model Coding rate Coding rate DPCCH ratio Loss
AWGN 2 ms 4 1440 kbps 0.75 0.5 6 dB 0.7 dB
AWGN 2 ms 4 1440 kbps 0.75 0.5 8 dB 0.6 dB
AWGN 2 ms 4 1440 kbps 0.75 0.5 10 dB 0.6 dB
AWGN 2 ms 4 1440 kbps 0.75 0.5 12 dB 0.6 dB
AWGN 2 ms 4 1440 kbps 0.75 0.5 14 dB 0.5 dB
Source: R1-040074
Table 9.1.5.3: 8PSK to 2xBPSK link level performance comparison – Single Transmission
Channel Coding rate 8PSK performance loss (gain)
TTI SF Data rate
model 2xBPSK 8PSK BLER = 10% BLER = 20% BLER = 50%
PedA 3km/h 10 ms 4 960 kbps 0.50 0.33 0.7 dB 0.7 dB 0.7 dB
PedA 3km/h 10 ms 4 1536 kbps 0.80 0.53 (0.2) dB (0.1) dB (0.1) dB
Source: R1-040049
Table 9.1.5.4: 8PSK to 2x/3xBPSK link level performance comparison – Residual BLER = 1% after 2 Tx
Channel Data rate Initial Coding rate 8PSK performance loss (gain)
TTI SF
model after 1 Tx 2xBPSK 3xBPSK 8PSK 2xBPSK 3xBPSK
PedA 3km/h 10 ms 4 960 kbps 0.50 0.33 0.33 0.9 dB 1.5 dB
Source: R1-040049
3GPP
Release 6 59 3GPP TR 25.896 V2.0.0 (2004-03)
9.2 Hybrid ARQ

9.2.1.1 Hybrid ARQ performance with and without soft combining

In this section, link level performance results of the hybrid ARQ with and without chase combining are presented for
144 kbps and 480 kbps with the Rel-99 turbo code of 1/3 coding rate and the Rel-99 rate matching. The results are
provided on ITU Pedestrian A channel at 3kmph and 30kmph.
Simulation assumptions are listed in the Table 9.2.1 below.
Table 9.2.1. Simulation assumptions

Chip Rate 3.840 Mcps
Carrier Frequency 2 GHz
Propagation Channel Pedestrian A 3km/h, 30km/h
Channel Estimation (CE) real CE (DPCCH 6 pilot bits)
Inner-loop transmit power control (TPC) On
Outer-loop power control Off
TPC step size 1dB
TPC delay and error rate 1 slot, 4%
Receiver Rake
Antenna configuration 2 antenna space diversity
Channel oversampling 1 sample/chip
Turbo code information R=1/3, K=4, 8 iteration,
Decoder : Max Log MAP
Information bit rate 144kbps / 480kbps
SF 8 (144kbps) / 4 (480kbps)
Modulation Dual BPSK
E-DCH TTI 10ms
Hybrid ARQ Chase Combining(CC) / No Combining(NC)
Maximum number of transmission 3
ACK/NACK signaling error No error
Rate matching Rel’99 Rate matching
Gain factor β c =5, β E − DPDCH =15
Cell configuration Single omni-cell and single user
The throughput is calculated as
Rinf
Throughput =
N av
where Rinf is the information bit rate and N av is average number of transmissions.
3GPP
Release 6 60 3GPP TR 25.896 V2.0.0 (2004-03)
Ped A 3km/h, 144kbps/480kbps, real CE, 4% T PC error
500
CC(480kbps)
NC(480kbps)
400 CC(144kbps)
NC(144kbps)
Throughput [kbps]
300
200
100
0
-22 -20 -18 -16 -14 -12 -10 -8 -6 -4
received Ec/No [dB]
Figure 9.2.1. Throughput in Pedestrian A 3 km/h with power control
500
CC(480kbps)
NC(480kbps)
400
CC(144kbps)
NC(144kbps)
Throughput [kbps]
300
200
100
0
-22 -20 -18 -16 -14 -12 -10 -8 -6 -4
received Ec/No [dB]
Figure 9.2.2. Throughput in Pedestrian A 30 km/h with power control

Figure 9.2.1 and Figure 9.2.2 show the throughput performance in Pedestrian A with 3 km/h and 30km/h, respectively.
It can be seen that the chase combining provides throughput gain when the UE available power is limited so that the
hybrid ARQ without chase combining suffers from throughput loss. It is noted that the gain from the soft combining in
a realistic scenario should be studied further, since more than two data rates could be typically available to choose
depending on, e.g., the UE available power and the scheduling command received from the scheduling Node B(s).
Figure 9.2.3 and Figure 9.2.4 show the average number of transmissions in Pedestrian A 3 km/h and 30km/h,
respectively. It can be seen that the chase combining can reduce the number of transmissions significantly.
3GPP
Release 6 61 3GPP TR 25.896 V2.0.0 (2004-03)
CC(144kbps)
NC(144kbps)
CC(480kbps)
Avg.number of transmission
NC(480kbps)
1
-18 -16 -14 -12 -10 -8 -6 -4
received Ec/No [dB]
Figure 9.2.3. Average number of transmissions in Pedestrian A 3km/h with power control
CC(144kbps)
NC(144kbps)
CC(480kbps)
Avg.number of transmission
NC(480kbps)
1
-18 -16 -14 -12 -10 -8 -6 -4
received Ec/No [dB]
Figure 9.2.4. Average number of transmissions in Pedestrian A 30km/h with power control
Figure 9.2.5 shows the BLER curve of 480 kbps in Pedestrian A 3km/h for each transmission with the chase combining.
Figure 9.2.6 and Figure 9.2.7 show the delay distributions with the first transmission BLER = 17% and 49%,
respectively. It can be seen that the chase combining can cut down the number of transmissions to two transmissions
even with the first transmission BLER = 49%. The gain of the chase combining in delay distribution is more
emphasized with the higher first transmission BLER. This could be beneficial especially for delay sensitive
applications.
3GPP
Release 6 62 3GPP TR 25.896 V2.0.0 (2004-03)
Ped A 3km/h, 480kbps, real CE, 4% T PC error
1.E+00
1.E-01
BLER
1.E-02
CC1
CC2
CC3
1.E-03
-16 -15 -14 -13 -12 -11 -10 -9 -8
received Ec/No [dB]
Figure 9.2.5. BLER for 480 kbps in Pedestrian A 3km/h
0.9
0.8
CC(480kbps)
0.7 NC(480kbps)
0.6
0.5
PMF
0.4
0.3
0.2
0.1
0
1 2 3 싩4
Number of transmission
Figure 9.2.6. Delay distribution with the first transmission BLER = 17% for 480 kbps in Pedestrian A 3km/h
3GPP
Release 6 63 3GPP TR 25.896 V2.0.0 (2004-03)
0.9
0.8 CC(480kbps)
NC(480kbps)
0.7
0.6
0.5
PMF
0.4
0.3
0.2
0.1
0
1 2 3 싩4
Number of transmission
Figure 9.2.7. Delay distribution with the first transmission BLER = 49% for 480 kbps in Pedestrian A 3km/h
9.2.1.2 Hybrid ARQ performance in soft handover

In this section, the link level performance of the hybrid ARQ in soft handover with and without the macro diversity is
evaluated. In the simulation, uplink transmit power is controlled by applying the “or of down” rule to the power control
commands sent from the active set Node Bs. The UE and Node B operation when the macro diversity is enabled or not
is as follows:
- Macro diversity “ON”: All active set Node Bs decode the E-DCH packet and generate ACK/NACK. The UE
performs the retransmission only if there is no ACK.
- Macro diversity “OFF”: Only a single active set Node B decodes the E-DCH packet and generates
ACK/NACK. The UE performs the retransmission in case of NACK.
The simulation results of the hybrid ARQ with the chase combining are presented for 144 kbps with the Rel-99 turbo
code of 1/3 coding rate and the Rel-99 rate matching. The results are provided on ITU Pedestrian A channel at 3kmph.
In the simulation, two active set Node Bs are assumed and different link imbalance conditions in uplink are taken into
account. Other detailed simulation assumptions are set as described in Table 9.2.1. It is noted that in this section, the
total received Ec/No in the active set corresponds to the sum of the Ec/No experienced by both Node Bs within the
active set.
Figure 9.2.8 and Figure 9.2.9 show the throughput and the average number of transmissions, respectively, versus the
total received Ec/No in the active set with 0dB link imbalance. It can be seen that the macro diversity provides
noticeable performance gain. It is noted that the macro diversity gain increases as the received energy is increased.
Figure 9.2.10 and Figure 9.2.11 show the simulation results with 3dB link imbalance. The macro diversity gain is more
emphasized compared to the case that only the weaker cell decodes the E-DCH packet. The macro diversity gain can
still be seen with respect to E-DCH decoding at the stronger cell, although the gain is reduced.
It is noted that the results in this section show the ideal performance of the macro diversity operation, assuming no
hybrid ARQ control signalling errors.
3GPP
Release 6 64 3GPP TR 25.896 V2.0.0 (2004-03)
&&6+2OLQNV3$NPSKNESVG%LPE

@V
S
EN
>
WX
SK
JX
RU
K7
ZGLY
ZRGLY

7RWDOUHFHLYHG(F1RLQWKHDFWLYHVHW>G%@
Figure 9.2.8. Throughput in soft handover with 0dB link imbalance in PA 3kmph
ZGLY
ZRGLY
QR
LV
VL
P
VQ
WUD
RI
UH
E
P
XQ
J
Y$

Figure 9.2.9. Average number of transmissions in soft handover with 0dB link imbalance in PA 3kmph

@V
S
EN
>
WX
SK
JX
RU
K7
ZGLY
ZRGLYVWURQJHUFHOO
ZRGLYZHDNHUFHOO

3GPP
Release 6 65 3GPP TR 25.896 V2.0.0 (2004-03)
Figure 9.2.10. Throughput in soft handover with 3dB link imbalance in PA 3kmph

ZGLY
ZRGLYVWURQJHUFHOO
ZRGLYZHDNHUFHOO
QR
LV
VL
VP
QD
UW
IR
U
EH
P
XQ
J
Y$

Figure 9.2.11. Average number of transmissions in soft handover with 3dB link imbalance in PA 3kmph
9.2.1.3 HARQ Efficiency

In this section, the benefits of link level retransmissions, and issues of HARQ efficiency and the maximum number of
retransmissions needed to support on E-DPDCH are addressed. Here, E-DPDCH denotes the physical set of
channelization codes used to carry E-DCH content.
A reference MCS for a sample 2ms TTI is shown in Table 9.2.2.
Transport Code Rate (kbps)

Index Mod
Block Size Rate
1 Tx 2 Tx 4 Tx
4 1280 QPSK 0.333 640 320 160
7 2048 QPSK 0.533 1024 512 256
9 2560 QPSK 0.333 1280 640 320
15 4096 QPSK 0.533 2048 1024 512
19 5120 QPSK 0.444 2560 1280 640
31 8192 QPSK 0.711 4096 2048 1024
Table 9.2.2 Reference MCS – 2ms TTI

From Table 9.2.2, the same target rate can be achieved using different transport formats and number of transmissions.
The performance of E-DPDCH is now evaluated with 1 or 2 or 4 target transmissions for the same target data rate, as
shown in Table 9.2.3
MCS
Target Data Rate (kbps)
1 Tx 2 Tx 4 Tx
640 4 9 19
3GPP
Release 6 66 3GPP TR 25.896 V2.0.0 (2004-03)
1024 7 15 31
Table 9.2.3 Simulation Set – 2ms TTI

The simulation assumptions and results are shown in Annex A.2.1.1.
For a 2ms sample TTI and associated link level performance shown in Figures A.2.1.1.1 to A.2.1.1.4 and Tables
A.2.1.1.1 and A.2.1.1.2, it is seen that:
1. For the same target data rate, as the target number of transmissions increases, the link efficiency improves.
a. The efficiency improvement reduces as the base number of transmissions increases.
b. The link efficiency gain from 1 to 2 transmissions is more than the gain from 2 to 4 transmissions.
2. The optimal DPCCH SNR typically decreases and E-DPDCH/DPCCH power ratio increases as the number of
transmissions increases.
3. For the same target data rate, as the maximum number of transmissions increases, the E-DPDCH can be
terminated relatively earlier ! effective data rate is higher.
a. For a target maximum of 2 transmissions, the average number of required transmissions is 1.7 !
early termination factor is 1.7/2 = 0.85
b. For a target maximum of 4 transmissions, the average number of required transmissions is 3.0 ! early
termination factor is 3.0/4 = 0.75
4. For the same effective data rate, as the maximum number of transmissions increases, the link efficiency
increases.
5. The first transmission BLER can be very high for the most efficient link operation
a. This does not necessarily maximize throughput.
6. For the same number of target transmissions, throughput can be maximized or delay can be reduced, at the cost
of link efficiency.
7. For the same effective data rate and same base TTI, as the maximum number of transmissions increases, the
average delay increases.
9.2.2.1 Buffering complexity
9.2.2.1.1 Soft buffer at Node B

The principle of hybrid ARQ is to buffer E-DCH TTIs that were not received correctly and consequently combine the
buffered data with retransmissions. The actual method of doing soft combining depends on the HARQ combining
scheme selected. In Chase combining scheme the receiver always combines the full retransmission of the failed TTI, i.e.
the amount of data in the receiver buffer remains the same. In the incremental redundancy schemes the receiver buffers
coded symbols, which introduce new information to the E-DCH TTI transmitted first, i.e. the amount of data to be
buffered increases with consecutive retransmissions. However, in practice the buffer in the receiver needs to be
dimensioned considering the maximum number of coded bits of the E-DCH TTI after all the incremental redundancy
has been introduced. Regardless of the HARQ combining scheme soft combining is done on L1 of Node B before the
decoding stage of FEC. Prior to decoding these symbols are soft-valued, i.e. each symbol is represented by two or more
bits. Here we call them soft symbols.
3GPP
Release 6 67 3GPP TR 25.896 V2.0.0 (2004-03)
For N-process SAW HARQ, the number of soft symbols to be buffered in L1 receiver can be estimated generally as
follows, since no new PDUs are transmitted on a subchannel before the previous packet is acknowledged. The receiver
has to buffer one E-DCH TTI for each HARQ process and for each UE. The next transmission is either a new packet or
a retransmission of an erroneous packet. In either case, the maximum buffering need is N E-DCH TTIs. The actual size
of the buffer needed for each E-DCH TTI depends on the HARQ combining scheme as described above. Thus, for N-
process stop-and-wait ARQ the L1 buffering at Node B for one UE can be expressed as:
buffer = ( softsymbolsTTI × N )
Table 9.2.4 shows some examples for the soft buffer size required at Node B per UE. It should be noted that soft buffer
is needed for all UEs waiting for retransmission at a given time. Thus these values have to be multiplied by the number
of active UEs using E-DCH. Depending on particular implementations, the buffer may be shared between UEs and thus
the total size of soft buffer can be reduced given that not all active UEs transmit simulteanously using the most
demanding format. Also, it may be possible to re-use some existing buffers.
Table 9.2.4 Node B soft buffer size (kilo soft symbols) per UE, for some example values of N (number of HARQ
processes) and TTI lengths
N=4, TTI=10 ms N=3, TTI=10 ms N=8, TTI=2 ms N=6, TTI=2 ms
BPSK, SF=4 38.4 28.8 15.36 11.52
QPSK or 2*BPSK, SF=4 76.8 57.6 30.72 23.04
8PSK or 3*BPSK, SF=4 115.2 86.4 46.08 34.56
2*QPSK or 4*BPSK, SF=4; 153.6 115.2 61.44 46.08
or QPSK, SF=2
It should be noted that soft buffer in the Node B is not needed if soft combining is not used, e.g., with physical/MAC
layer ARQ without soft combining.
9.2.2.1.2 Reordering buffer in radio network

Due to physical/MAC layer (H)ARQ, the MAC-e PDUs may be received in wrong order. Therefore, reordering of the
MAC-e PDUs is required either in the Node B or in the RNC. Here the required reordering buffer size per UE is
estimated. In the estimation it is assumed that only one high bit rate reordering queue is active for a UE at a time.
Furthermore, maximum of 3 retransmissions per MAC-e PDU is assumed and the buffer size is calculated for the worst
case where one ARQ process requires retransmissions while the others get blocks through and forward them to
reordering queue. The worst case buffer size is then calculated as
reorderingbuffer = [3( N − 1) + 1]× (bits / TTI )

These values have to be multiplied by the number of E-DCH UEs served by the Node B or by the RNC, depending on
the location of the reordering buffer. Depedending on implementation and location of the re-ordering buffer, it may be
possible to re-use some existing buffers.
Table 9.2.5 Reordering buffer size (kB) per UE, for some example values of N (number of HARQ processes) and
TTI lengths
User data rate N=4, TTI=10 ms N=3, TTI=10 ms N=8, TTI=2 ms N=6, TTI=2 ms
384 kbit/s 4.8 3.36 2.1 1.5
768 kbit/s 9.6 6.72 4.2 3.1
1 Mbit/s 12.5 8.8 5.5 4.0
1.5 Mbit/s 18.8 13.1 8.3 6.0
9.2.2.1.3 Retransmission buffer in UE

In addition to buffers in the receiver side, also some buffer at UE side is needed. The retransmission buffer can be either
at MAC layer as info bits or at physical layer as coded bits. The total number of coded bits is typically 3 times the
number of info bits. Table 9.2.4 shows also the required retransmission buffer size in kbits (assuming that coded bits are
buffered). Depending on implementation it may be possible to re-use existing buffers.
3GPP
Release 6 68 3GPP TR 25.896 V2.0.0 (2004-03)
9.2.2.2 Encoding/decoding and rate matching complexity

Rate 1/3 turbo code specified in Rel99 as well as the two stage rate matching specified for HSDPA are supposed to be
possible to reuse for E-DCH with some modifications. These are not considered to bring much more complexity for
uplink processing than already is in Rel99/4/5.
9.2.2.3 UE and RNS processing time considerations

One of the major complexity issues for fast HARQ is the tight processing time requirement that it sets to the Node B
and the UE. Section 8.2 already discusses the processing times as well as other delay components related to fast HARQ.
9.2.2.4 HARQ BLER operation point and complexity

Section 9.2.1.3 states that HARQ efficiency is increased when the maximum number of transmissions is increased. That
also implies that the first transmission BLER is increased. From complexity point of view, the increase of BLER
operation point (to 50% or even higher) also means complexity increase. If the first transmission BLER is high and the
single user throughput is kept the same, then the peak data rate has to be increased, which means that more hardware
and/or software resources have to be allocated for each user both at UE and radio network side. On the other hand, if
single user throughput is allowed to decrease and the system throughput is increased by allowing more users in the cell,
this also requires more hardware and/or software resources in the network side. The higher peak data rate per user or
more users both imply that the amount of processing, as well as the amount of the buffering is increased at Node B.
Also the amount of Iub traffic and buffering and processing at RNC is increased if the reordering is performed at RNC.
Roughly speaking BLER=50-60% operation point requires that the baseband buffers and amount of processing
resources are doubled compared to BLER=10% operation point.
9.2.4.1 E-TFC signalling

This section provides some simulation results for a number of combinations derived from the options described in
section 7.5.2.1. The options under consideration are listed in table 9.2.1
Table 9.2.4.1: E-TFC coding, multiplexing and mapping options
Parameter Case 1 Case 2 Case 3

# of E-TFC bits 10 5 10
TTI 10 ms 10 ms 2 ms
CRC No No No
Block [30,10] +
Coding Block [30,10] Block [30,10]
Repetition [5 times]
E-DPCCH DPCCH E-DPCCH
Mapping
SF=256 SF=256
0 dB
Offset relative to
Variable (can not be Variable
DPCCH
changed by design)
Modulation BPSK BPSK BPSK
Results in section 9.2.4.1.1.1 9.2.4.1.1.2 9.2.4.1.1.3
3GPP
Release 6 69 3GPP TR 25.896 V2.0.0 (2004-03)
9.2.4.1.1 Summary of results

Table 9.2.2 provides a summary of the simulation results assuming a target E-TFC error rate of 1%. It is FFS whether
this target is appropriate.
Table 9.2.4.2: E-TFC coding, multiplexing and mapping options
Parameter Required offset to DPCCH [dB] to

achieve 1% error rate on E-TFC Comments
DPCCH SNR -21 dB -24 dB

Case 1 -9 dB -4 dB No issue
This approach requires a power
@ 0 dB @ 0 dB offset on the TFCI bits (new option) in
Case 2
BLER < 1e-3 BLER < 1e-1 order to achieve the target error rate
in difficult conditions.
Required power offset is similar to
Case 3 1 dB - one required for HS-DPCCH
transmission.
9.2.4.1.1.1 Case 1 results
Figure 9.2.4.1 E-DPCCH/DPCCH = -9 dB
3GPP
Release 6 70 3GPP TR 25.896 V2.0.0 (2004-03)
Figure 9.2.4.2: E-DPCCH/DPCCH = -4 dB
Figure 9.2.4.3: TFCI/DPCCH = 0 dB
3GPP
Release 6 71 3GPP TR 25.896 V2.0.0 (2004-03)
Figure 9.2.4.4: E-DPCCH/DPCCH = -2 dB
Figure 9.2.4.5: E-DPCCH/DPCCH = 1 dB
3GPP
Release 6 72 3GPP TR 25.896 V2.0.0 (2004-03)
9.2.4.1.2 Simulation assumptions

Table 9.2.4.3 summarizes the simulation parameters.
Table 9.2.4.3: Simulation parameters
Parameter Value
Channel Estimation On
DPCCH slot format 0
Inner Loop Power Control On
ILPC Step Size +/- 1 dB
Outer Loop Power Control Off,
DPCCH SNR target varied
PC feedback delay 1-slot
PC command BER 4%
Channels PA3, PB3, VA30, VA120
Number of Rx antennas 2
9.3 Fast DCH Setup Mechanisms

9.4 Shorter Frame Size for Improved QoS

Two possible candidates for the frame size are 2ms and 10ms. In this section, we present the E-DCH system
performance with 2ms TTI vs. 10ms with HARQ and a Node-B scheduler. The comparison is performed assuming
the same maximum physical layer delay equal to 40 ms. Comparison performed using a different criterion (e.g.
different max delay value, average delay, …) may yield different relative results.
9.4.1.1 Data only, Full buffer

The system configuration has been set as shown in Table 9.4.1.1.1. A subset of the MCS used for 2 ms and 10 ms are
shown in Annex 2.2.1 and 2.2.2.
3GPP
Release 6 73 3GPP TR 25.896 V2.0.0 (2004-03)
Table 9.4.1.1.1: Simulation parameters

Parameter Configuration
Layout 19 Node-B, 3-cell wrap-around layout
Channel model Mixed (PA3 30%, VA30 50% and VA120 20%) and individual
Traffic model Full buffer
#UE per cell 10
Duration 200 s + 10 s warm-up
2ms TTI 10ms TTI
Max # of transmissions = 4 Max # of transmissions = 2
HARQ # of HARQ processes = 5 # of HARQ processes = 3
Re-transmission delay = 10 ms Re-transmission delay = 30 ms
Ack/Nack errors = 0% Ack/Nack errors = 0%
Scheduling algorithm Proportional fair
As described in R1-031246. Decentralized Node-B scheduler with
Scheduling process 1 serving cell per UE = best DL (same as HSDPA serving cell). All cells in
UE’s active set send ACK/NAK.
2ms E-DCH 10ms E-DCH

Period 2 ms 10 ms
Scheduling delays Uplink SI delay 10 slots 35 slots
DL Grant delay 1 slot 1 slot
Outer loop driven by 1% BLER on DPDCH

Power control
Inner loop error rate = 4%
TFCS = 8 kbps (100% duty cycle)
DCH
Minimum set: 8 kbps
TFCS = TFS = MCS as shown in Table 2
Minimum set is empty
E-DCH E-TFC elimination:

Similar to R99 TFC elimination. UE MAC decides upon the E-DCH TFC in
SUPPORTED_STATE and EXCESS_POWER_STATE every radio frame.
The parameters {x, y, z} are set to {15, 30, 30} as in Rel-99.
2ms TTI 10ms TTI
E-DPCCH β / βc = 17/15 β / βc = 7/15
E-DPCCH errors: 0%
2ms TTI 10ms TTI
SHO When in SHO E-TFS is restricted up When in SHO E-TFS is restricted up
to instantaneous 512kbps to instantaneous 256kbps
Decoding Short term link level curves: [A2.2.1] with implementation-I and [A2.2.2]
Figure 9.4.1.1.1 and Figure 9.4.1.1.2 compare the E-DCH cell throughput with 2ms and 10ms TTI. It is seen that
compared to 10ms TTI, the system performance with 2ms TTI improves by 16% at 4.5 dB RoT. Figure 9.4.1.1.3 shows
that 2 ms yield a better fairness. The RoT overshoot curve given in Figure 9.4.1.1.4 indicates that 10ms TTI has a
higher RoT overshoot.
3GPP
Release 6 74 3GPP TR 25.896 V2.0.0 (2004-03)
2ms vs. 10ms, mixed channel, PF
1800
Throughput (kbps)
1600
1400
1200
1000
800
3 3.5 4 4.5 5 5.5 6 6.5
Avg. RoT (dB)
2ms 10ms
Figure 9.4.1.1.1: Average cell throughput as a function of average RoT – mixed channel
2ms vs. 10ms, mixed channel, PF
40
Throughput Gain (%)
30
20
10
0
3 3.5 4 4.5 5 5.5 6 6.5
Avg. RoT (dB)
Figure 9.4.1.1.2: Throughput gain between EUL 2ms and EUL 10ms – mixed channel
3GPP
Release 6 75 3GPP TR 25.896 V2.0.0 (2004-03)
Fairness - E-DCH 2ms vs. 10ms
100.00%
80.00%
60.00%
CDF
40.00%
20.00%
.00%
0 0.5 1 1.5 2 2.5 3
Normalized User Throughput
E-DCH - 2ms E-DCH - 10ms
Figure 9.4.1.1.3: Fairness curves - mixed channel
RoT overshoot
8
Pr [RoT > 7dB] (%)
0
3 3.5 4 4.5 5 5.5 6 6.5
Avg. RoT (dB)
E-DCH - 2ms E-DCH - 10ms
Figure 9.4.1.1.4: Percentage of time the RoT is greater than 7 dB – mixed channel
9.4.1.2 Data only, Traffic models

The system configuration has been set as shown in tables 9.4.1.1.1, except for the number of UE and traffic model part
which is as shown in table 9.4.1.2.1. A subset of the MCS used for 2 ms and 10 ms are shown in Annex 2.2.1 and 2.2.2.
Table 9.4.1.2.1: Simulation parameters for mixed traffic model

#UE per cell 12
Traffic model Mixed (4 FTP, 4 Video, 4 Gaming)
Table 9.4.1.2.2 shows the values of tau parameters used for FTP users.
3GPP
Release 6 76 3GPP TR 25.896 V2.0.0 (2004-03)
Table 9.4.1.2.2: Tau parameters used for FTP

Delay component Symbol Value
The uplink transmission time of a TCP data τ1 Determined by uplink throughput
segment from the client to the Node-B
The sum of the time taken by a TCP data τ2 Exponential distribution
segment to travel from Node-B to the server and Mean = 50 ms.
the time taken by an ACK packet to travel from
the server to Node-B
Time taken by the ACK to travel from Node-B to τ3 Lognormal distribution
client Mean = 50 ms
Standard deviation = 50 ms
Increased delay to account for RLC τ4 Constant
retransmissions from residual uplink physical = 0 ms, if packet is not in error after all
layer BLER physical layer retransmissions
= 200 ms, else
The following figures present the system performance of E-DCH with different TTI lengths. The comparison of the
performances, in terms of cell throughput, fairness, RoT overshoot, and delays are shown.
Figure 9.4.1.2.1 shows the system throughput as a function of the average RoT. The gain of around 10% of the system
with 2ms TTI over the 10ms TTI can be observed.
The RoT overshoot is given in Figure 9.4.1.2.2. It can be seen that the RoT overshoot for the region of interest is similar
for both, 2 ms TTI and 10 ms TTI.
The cumulative density function (CDF) of user throughputs normalized by the average throughput per user is used to
represent the fairness. The fairness curve, given in Figure 9.4.1.2.3, shows that the fairness of the system with 2 ms TTI
is slightly degraded compared to 10 ms TTI, primarily due to the higher instantaneous data rates.
Figures 9.4.1.2.4 to 9.4.1.2.7 present the average packet call delays and the average packet delays. Packet call delay is
the time between two consecutive reading periods. For Gaming users, packet call delay represents the time of a gaming
session that includes the time during which the packets are generated (active period), and the time needed for
transmission of the data packets accumulated during the active period. For FTP users, packet call delay is the time
needed for an FTP file upload. Packet delay is the time needed for a packet to be received at a Node-B. It can be seen
that the delays are decreased for the system with 2 ms TTI when compared to the 10 ms TTI.
Figures 9.4.1.2.8 to 9.4.1.2.11 show the CDF of the packet call delays and packet delays, for both systems, with 2 ms
TTI and 10 ms TTI. It can be seen that the delay characteristics of the 2 ms TTI are superior over the 10 ms TTI, for all
traffic models.
3GPP
Release 6 77 3GPP TR 25.896 V2.0.0 (2004-03)
1600
1400
Cell Throughput [kbps]
1200
1000
800
600
400
3.5 4 4.5 5 5.5 6 6.5
Average RoT [dB]
TTI=2ms TTI=10ms
Figure 9.4.1.2.1: Average cell throughput as a function of the average RoT
RoT Overshoot
16
14
12
Pr{RoT > 7dB} [%]
10
0
3.5 4 4.5 5 5.5 6 6.5
Average RoT [dB]
TTI=2ms TTI=10ms
Figure 9.4.1.2.2: Percentage of time the RoT is greater than 7 dB
3GPP
Release 6 78 3GPP TR 25.896 V2.0.0 (2004-03)
Fairness Curve
0.9
0.8
0.7
0.6
CDF
0.5
0.4
0.3
0.2
0.1
0
0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2
User Throughput / Average User Throughput
TTI=2ms TTI=10ms
Figure 9.4.1.2.3: Fairness curves
Packet Call Delay for FTP Users
140
120
100
Packet Call Delay [s]
80
60
40
20
0
3.5 4 4.5 5 5.5 6 6.5
Average RoT [dB]
TTI=2ms TTI=10ms
Figure 9.4.1.2.4: Average packet call delay for FTP users
3GPP
Release 6 79 3GPP TR 25.896 V2.0.0 (2004-03)
Packet Call Delay for Gaming Users
25
20
15
10
0
3.5 4 4.5 5 5.5 6 6.5
Average RoT [dB]
TTI=2ms TTI=10ms
Figure 9.4.1.2.5: Average packet call delay for Gaming users
Packet Delay for FTP Users
35
30
25
Packet Delay [s]
20
15
10
0
3.5 4 4.5 5 5.5 6 6.5
Average RoT [dB]
TTI=2ms TTI=10ms
Figure 9.4.1.2.6: Average packet delay for FTP users
3GPP
Release 6 80 3GPP TR 25.896 V2.0.0 (2004-03)
Packet Delay for Video Users
1.8
1.6
1.4
1.2
Packet Delay [s]
0.8
0.6
0.4
0.2
0
3.5 4 4.5 5 5.5 6 6.5
Average RoT [dB]
TTI=2ms TTI=10ms
Figure 9.4.1.2.7: Average packet delay for Video users
Packet Call Delay - FTP Traffic
0.9
0.8
0.7
0.6
CDF
0.5
0.4
0.3
0.2
0.1
0
0 20 40 60 80 100 120 140 160 180 200
TTI=10ms TTI=2ms
Figure 9.4.1.2.8: CDF of the packet call delays for FTP users
3GPP
Release 6 81 3GPP TR 25.896 V2.0.0 (2004-03)
Packet Call Delay - Gaming Traffic
0.9
0.8
0.7
0.6
CDF
0.5
0.4
0.3
0.2
0.1
0
0 5 10 15 20 25 30
TTI=10ms TTI=2ms
Figure 9.4.1.2.9: CDF of the packet call delays for Gaming users
Packet Delay - FTP Traffic
0.9
0.8
0.7
0.6
CDF
0.5
0.4
0.3
0.2
0.1
0
0 10 20 30 40 50
Packet Delay [s]
TTI=10ms TTI=2ms
Figure 9.4.1.2.10: CDF of the packet delays for FTP users
3GPP
Release 6 82 3GPP TR 25.896 V2.0.0 (2004-03)
Packet Delay - Video Traffic
0.9
0.8
0.7
0.6
CDF
0.5
0.4
0.3
0.2
0.1
0
0 0.5 1 1.5 2 2.5 3 3.5
Packet Delay [s]
TTI=10ms TTI=2ms
Figure 9.4.1.2.11: CDF of the packet delays for Video users
9.4.1.3 Voice & Data, Full buffer

This section considers the impact on (legacy) voice users. The system configuration has been set as shown in tables
9.4.1.1.1 and 9.4.1.1.2. A subset of the MCS used for 2 ms and 10 ms are shown in Annex 2.2.1 and 2.2.2.
Table 9.4.1.3.1: Simulation parameters for voice users

Voice UE: TFCS = {Null, SID and 12.2kbps} = Minimum set;
DCH
TTI: 20ms, 40% voice activity
Duration 500 s + 10 s warm up
The following figures compare the system performance of E-DCH with 2ms and 10ms TTI in terms of average cell
throughput, fairness and RoT overshoot with 20UEs present in the system.
Figure 9.4.1.3.1 and Figure 9.4.1.3.2 compare the E-DCH cell throughput with 2ms and 10ms TTI. It is seen that
compared to 10ms TTI, the system performance with 2ms TTI yields higher throughput, similarly as what can be
observed in section 9.4.1.1. The throughput is less than in sections 9.4.1.1 as part of the resources are taken by voice
UEs and more data UEs are transmitting on DPDCH with 8kbps. Figure 9.4.1.3.3 shows that the voice outage with 2ms
is slightly lower than with 10ms, but they are all very small in both cases. 2ms sees a better fairness than 10ms TTI, as
demonstrated in Figure 9.4.1.3.4. The RoT overshoot curves given in Figure 9.4.1.3.5 indicate that 10ms TTI has a
higher RoT overshoot, but again the overshoot is very small with both 2ms and 10ms TTI.
3GPP
Release 6 83 3GPP TR 25.896 V2.0.0 (2004-03)
2ms vs. 10ms - 10 Data + 20 Voice UEs
1200
Throughput (kbps)
1000
800
600
400
200
3 3.5 4 4.5 5 5.5 6 6.5 7
Avg. RoT (dB)
2ms - Data+Voice 10ms - Data+Voice

Throughput gain (%)
25
20
15
10
5
0
3 3.5 4 4.5 5 5.5 6 6.5 7
Avg. RoT (dB)
Throughput gain (%)
Figure 9.4.1.3.2: Throughput gain between 2ms and 10ms
3GPP
Release 6 84 3GPP TR 25.896 V2.0.0 (2004-03)
0.7
Voice Outage (%)

0.6
0.5
0.4
0.3
0.2
0.1
0
3 3.5 4 4.5 5 5.5 6 6.5 7
Avg. RoT (dB)
2ms 10ms
Figure 9.4.1.3.3: Voice Outage with 2ms and 10ms TTI
1
0.8
0.6
CDF
0.4
0.2
0
0 0.5 1 1.5 2 2.5 3 3.5
2ms 10ms
3GPP
Release 6 85 3GPP TR 25.896 V2.0.0 (2004-03)
RoT overshoot
30
Pr [RoT>7dB] (%)
25
20
15
10
5
0
3 3.5 4 4.5 5 5.5 6 6.5 7
Avg. RoT (dB)
2ms 10ms

Introduction of a shorter TTI (than 10 ms) affects the following aspects of the UE and Node B:
a) Timing
• The timing aspect of both 2 and 10 ms TTI is covered in section 8.5.
• Use of a shorter TTI may result in tighter delay requirements between DL and UL reception and transmission
if used in conjunction with a fast ARQ mechanism.
b) Physical channel structure
• Physical channel structures compatible with a shorter TTI are described in sections 8.4.2. The associated
impact on PAR (relevant for the UE only) is presented in section 9.5.1
c) HARQ (if introduced for E-DCH)
• Buffering requirements associated with the introduction of HARQ for both 2 and 10 ms TTI are shown in
section 9.2.2.
• In general a lower TTI results in lower buffer requirements compared to 10 ms TTI
In addition, the introduction of a shorter TTI also affects the TFC selection procedure in the UE
• Complexity of TFC selection relates to the number of CCTrCh, their respective timing and TTI. The number of
CCTrCh and timing is not specific to the TTI discussion although introduction of a shorter TTI would likely
prevent the use of a single time aligned CCTrCH. Consequently the introduction of a shorter TTI will impact the
TFC selection procedure.
Depending on whether the Iub/Iur interfaces frame protocol are adapted to 2 ms the impact on the RNS may or may not
be significant. The complexity impact of adapting the Iub/Iur frame protocol is FFS.

No specific downlink signalling is associated with a shorter E-DCH TTI value compared to 10 ms TTI. However the
channel structure supporting the signalling may be different than the one used for 10 ms TTI. In case the downlink
control signalling is also using a shorter TTI, the power requirement to transmit the signalling would be higher than for
a 10 ms TTI.
3GPP
Release 6 86 3GPP TR 25.896 V2.0.0 (2004-03)
In case the system supports semi-static configuration supporting both 10 ms TTI and a shorter TTI, RRC signalling
would be necessary to switch between one TTI and the other.

No specific uplink signalling is associated with a shorter E-DCH TTI value compared to a 10 ms TTI. However the
channel structure supporting the control signalling may be different that the one used for 10 ms TTI. In case a shorter
TTI value is used for the control structure the power requirement to transmit the signalling would be higher as shown in
section 9.2.4.
9.5 Physical layer structures

9.5.1 Complexity evaluation
9.5.1.1 PAR analysis

The parameters and results for the analysed cases are shown below. The idea how the parameters are shown in the
tables is that if the E-DCH and DCH are inserted to the same code channel/s, then the parameters are shown in the
column of DPDCH (DPDCH meaning a generalized name for code channels carrying both E-DCH and DCH). If E-
DCH are DCH are carried on separate code channels, then the parameters are given so that for code channels carrying
E-DCH they are in the column of E-DPDCH. And the parameters for code channels carrying DCH are in the column of
DPDCH.
The main parameters to be listed for each code channel are :
- Branch (Br) defines whether the code channel is on I or Q branch.
o DPCCH, HS-DPCCH and E-DPCCH are only assumed to be carried on one physical code channel, so
for these the Br defines the branch that they are carried on, either I -branch or Q- branch.
o For DPDCH and/or E-DPDCH this defines the branch for the first code channel for the physical
channel type in question. Thus if Br is defined to be Br = I in the tables below, it means that DPDCH1
is on I branch , DPDCH2 is on Q branch, DPDCH3 is again on I branch etc. Thus the assumption is
that every other additional code channel is on I branch , every other is on Q branch.
o 8PSK is indicated with p8
- Power level of code channel/s relative to other code channels (β factor). In the tables, it is defined in the form
of x / 15 as in current specifications, out of which only the value x is included in the tables. The same
terminology is assumed to be used as in Rel5, i.e.
o For DPCCH and DPDCH(s), the β -factor is defined relative to each other. And since the code
channel having higher amplitude is defined to have amplitude 1, the β -factor of either DPCCH or
DPDCH is equal β =x/15 =15/15 =1.
o For HS-DPCCH the β -factor is as defined in TS25.214.Some of the PAR results presented here use β
-factors that are not constrained to the set of β –factors defined in Release-5.
o For E-DPCCH the β -factor is as defined for the HS-DPCCH with no constraint on the set of delta
values.
o For E-DPDCH the β -factor is defined relative to amplitude 1, since either DPCCH or DPDCH has the
amplitude of 1. This ensures that there is enough dynamic range for defining β factors for DPDCH
and DPCCH.
o In the case of E-DCH transmitted using QPSK, it is assumed that the QPSK signal is constructed from
two code channels, and that beta applies to each code channel for data.
o For E-DCH transmitted using 8PSK, it is assumed that the modulation constellation points have the
same energy as for the QPSK case (amplitude of the constellation point equals to √2 beta) , and
therefore beta applies to each of the I and Q components for data.
3GPP
Release 6 87 3GPP TR 25.896 V2.0.0 (2004-03)
- Spreading factor of each code channel (SF). If this is greater than 4 in the tables, it means that no multicodes
are used. If this is equal to 2 or 4, the number of multicodes could be derived from the data rate.
- Channelisation code (C). This defines explicitly what channelisation code was used, with the terminology of
current specification.
The analysis is divided to different sections based on how many channel bits there are in total for both E-DCH and
DCH. This is defined with the help of the number of channel bits fitting to certain number of BPSK code channels with
SF=4. This allows to look at different data rate regions separately.
PAR results are given for a number of parameter sets. The rationale for these sets are described in table 9.5.1, including
the assumption of the BLER level in the initial transmission for the data, at least if that is assumed to be differing
between DPDCH and EDPDCH. The rationale is provided for the sole purpose of PAR evaluation under various
scenarios and does not reflect any decision by RAN WG1 relative to the final channel configuration in support of
enhanced uplink.
Table 9.5.1 – Parameter Set Rationale

Parameter Set Rationale
1 The betas are derived considering the Eb/Nt requirements of each physical channel as described in
R1-031349 and R1-031367. This assumes target BLER for E-DCH of 20% and target BLER for
DPDCH of 1%, and assumes DPCCH is boosted for improved channel estimation performance for
high data rates on E-DCH.
2 The Beta values have been derived assuming non ideal receiver and DPCCH Ec/Nt = -21 dB.
These Beta values are selected for the purpose of optimum performance in this scenario. Whether
the performance is optimum can still be verified later.In addition, for case 2, the beta values have
been selected assuming 10 ms TTI, and 1% BLER in the first transmission. (note that the beta
values are different than those used in TS 25.104). In addition for case 8, the beta values have been
selected assuming 2 ms TTI, and BLER of x% in the initial transmission. Furthermore a 12.2 kbps
DCH is assumed to be mapped on the DPCH. Note that the channelisation codes assigned to the
Rel-5 physical channels differ from Rel-5 hence configurations equivalent to Rel-5 ones are listed
under case 8. The beta values for E-DPCCH1 and E-DPCCH2 channels are based on results
provided in chapter 9. E-DPCCH3 (pilot) is only assumed to be transmitted for the highest E-DCH
rates as it does not seem provide any benefit for lower E-DCH rates.
3 The beta values are defined with the help of the WG4 specification TS 25.141, containing uplink
measurement channels, i.e. also beta factors for different data rates for NodeB performance tests.
In this parameter set the beta factors for case 3 are exactly the same as in TS25.141, since they are
assumed to give the best performance for DPCH for the given data rates according to WG4. For
other cases than case 3, the beta factors are defined so that the percentage of pilot power from the
total transmitted signal is as close as possible to one in case 3, taken the limitation into account that
the βc cannot be higher than 1. BLER in the initial transmission is here assumed to be a value
within range 1-20 %. For the sake of making PAR comparison of different cases easier, it is
assumed here, that the BLER in the initial transmission is the same for DCH and EDCH, which
means that the channel bit energy for DCH and EDCH is equal. Thus the beta factor for code
channel carrying EDCH is defined to be βe= βd * sqrt(SFDCH/SFEDCH). Beta factors for L1
signaling channels (E-DPCCH or HS-DPCCH) are assumed to require 6 dB higher power than
DPCCH in the low to medium data rates (up to 1 BPSK code channel with SF=4) since that might
be in soft handover, and equal power with DPCCH with higher data rates than that.
3GPP
Release 6 88 3GPP TR 25.896 V2.0.0 (2004-03)
9.5.1.1.1 Total number of channel bits from both E-DCH and DCH that can be
accommodated one BPSK code channel with SF=4
Parameters and results:
Table 9.5.1.1.1: Cases 1-7

Param Case DPCCH DPDCH E-DPDCH HS-DPCCH E-DPCCH 99.9%
set PAR
Br βc SF C Br βd SF C Br β eu SF C Br β hs SF C Br βT SF C [dB]
1 1 Q 11 256 0 Q 15 64 16 I 24 32 8 Q 15 256 32 I 15 128 1 4.75
1 1 Q 15 256 0 Q 10 64 16 I 42 4 1 Q 7 256 32 I 7 128 1 3.64
1 2 Q 11 256 0 I 33 16 4 Q 15 256 64 3.06
2 2 Q 15 256 0 I 15 64 16 3.10
2 2 Q 15 256 0 I 15 64 16 Q 15 256 64 3.65
2 2 Q 15 256 0 I 15 64 16 Q 30 256 64 3.65
3 1 Q 15 256 0 I 15 64 16 Q 42 8 2 I 30 256 1 Q 30 256 32 4.92
3 1 Q 15 256 0 I 15 64 16 Q 30 16 4 I 30 256 1 Q 30 256 32 4.95
3 1 Q 15 256 0 I 15 64 16 Q 21 32 8 I 30 256 1 Q 30 256 32 4.85
3 2 Q 5 256 0 I 15 8 2 - - Q 10 256 64 - - 3.11
3 2 Q 8 256 0 I 15 16 4 - - Q 16 256 64 - - 3.30
3 2 Q 10 256 0 I 15 32 8 - - Q 20 256 64 - - 3.43
3 1 Q 15 256 0 I 15 64 16 Q 60 4 1 I 30 256 1 Q 30 256 32 4.69
3 2 Q 5 256 0 I 15 4 1 - - Q 9 256 64 - - 3.10
3 3 Q 5 256 0 I 15 4 1 - - - - - - 3.06
3 4 Q 15 256 0 I 15 64 16 Q 60 4 1 4.01
Table 9.5.1.1.1b: Case 8

Case 8 8 8 8
Parameter set 2 2 2 2
99.9% PAR [dB] 4.70 4.70 5.20 4.90
Br Q Q Q Q
βc 15 15 15 15
DPCCH
SF 256 256 256 256
C 0 0 0 0
Br I I I I
βd 15 15 15 15
DPDCH
SF 64 64 64 64
C 8 8 8 8
Br Q Q Q Q
β hs 15 30 15 30
HS-DPCCH
SF 256 256 256 256
C 32 32 32 32
Br I I
E-DPCCH2 βR 17 30
(request) SF 64 64
C 1 1
Table 9.5.1.1.1c: Backward compatible settings

Case 1 1 8 8 8 8
Parameter set 1 1 2 2 2 2
99.9% PAR [dB] 5.36 4.73 3.63 3.64 5.41 5.32
Br Q Q Q Q Q Q
DPCCH βc 11 15 15 15 15 15
SF 256 256 256 256 256 256
C 0 0 0 0 0 0
Br I I I I I I
DPDCH βd 15 10 15 15 15 15
SF 64 64 64 64 64 64
C 16 16 16 16 16 16
Br Q Q Q Q Q Q
HS-DPCCH β hs 15 7 15 30 15 30
SF 256 256 256 256 256 256
C 64 64 64 64 64 64
3GPP
Release 6 89 3GPP TR 25.896 V2.0.0 (2004-03)
Case 1 1 8 8 8 8
Parameter set 1 1 2 2 2 2
99.9% PAR [dB] 5.36 4.73 3.63 3.64 5.41 5.32
Br Q Q
E-DPDCH β eu 24 42
SF 32 4
C 16 2
Br I I
E-DPCCH βT 15 7
SF 128 128
C 1 1
E-DPCCH2 Br Q Q
βR 17 30
(request) SF 64 64
C 1 1
accommodated in two BPSK code channels with SF=4
Table 9.5.1.1.2: Cases 1-7

set PAR
1 1 Q 15 256 0 I 6 64 8 I+Q 40 4 1 Q 5 256 32 I 5 128 1 3.97
1 2 Q 15 256 0 I+Q 40 4 1 Q 7 256 32 3.79
2 2 Q 7 256 0 I+Q 15 4 1 4.00
2 2 Q 7 256 0 I+Q 15 4 1 I 7 256 1 4.40
2 2 Q 7 256 0 I+Q 15 4 1 I 14 256 1 4.75
3 1 Q 15 256 0 I 15 64 16 IQ 60 2*4 2 Q 15 256 32 I 15 256 1 4.44
3 1 Q 15 256 0 I 15 64 16 Q 85 2 1 I 15 256 1 Q 15 256 32 4.59
3 2 Q 5 256 0 IQ 15 2*4 1 - - I 5 256 1 - - 4.03
3 3 Q 5 256 0 IQ 15 2*4 1 - - - - - - 3.69
3 4 Q 15 256 0 I 15 64 16 IQ 60 2*4 2 - - - - 3.98
3 4 Q 15 256 0 I 15 64 16 Q 85 2 1 - - - - 3.95
3GPP
Release 6 90 3GPP TR 25.896 V2.0.0 (2004-03)

Case 8 8
Parameter set 2 2
99.9% PAR [dB] 5.70 6.05
Br Q Q
βc 15 15
DPCCH
SF 256 256
C 0 0
Br I I
βd 15 15
DPDCH
SF 64 64
C 8 8
Br Q Q
β hs 15 30
HS-DPCCH
SF 256 256
C 32 32
Br I+Q I+Q
β eu 34 34
E-DPDCH
SF 4 4
C 1 1
Br Q Q
βT 17 30
E-DPCCH
SF 64 64
C 2 2
Br I I
E-DPCCH2 βR 17 30
(request) SF 64 64
C 1 1

Case 1 8 8
Parameter set 1 2 2
99.9% PAR [dB] 4.16 5.85 6.12
Br Q Q Q
βc 15 15 15
DPCCH
SF 256 256 256
C 0 0 0
Br I I I
βd 6 15 15
DPDCH
SF 64 64 64
C 16 16 16
Br Q Q Q
β hs 5 15 30
HS-DPCCH
SF 256 256 256
C 64 64 64
Br I+Q I+Q I+Q
β eu 40 34 34
E-DPDCH
SF 4 4 4
C 2 2 2
Br I I I
βT 5 17 30
E-DPCCH
SF 128 64 64
C 1 1 1
Br Q Q
E-DPCCH2 βR 17 30
(request) SF 64 64
C 1 1
3GPP
Release 6 91 3GPP TR 25.896 V2.0.0 (2004-03)
accommodated in three BPSK code channels with SF=4
Table 9.5.1.1.3: Cases 1-7

set PAR
1 1 Q 15 256 0 I 5 64 8 p8 67 4 1 Q 4 256 32 I 4 128 1 3.44
1 5 Q 15 256 0 p8 47 4 1 I 5 256 1 3.64
1 5 Q 15 256 0 p8 78 4 1 I 4 256 1 3.30
3 1 Q 15 256 0 I 15 64 16 Q 60 3*4 1,3 I 15 256 1 Q 15 256 32 5.5
3 1 I 85 2+ 1
Q 15 256 0 I 15 64 16 Q 15 256 32 I 15 256 1 5.2
Q 60 4 1
3 2 Q 5 256 0 I 15 3*4 1,3 - - Q 5 256 32 - - 5.3
3 3 Q 5 256 0 I 15 3*4 1,3 - - - - - - 5.1
3 4 Q 15 256 0 I 15 64 16 Q 60 3*4 1,3 - - - - 5.2
3 4 I 85 2+ 1
Q 15 256 0 I 15 64 16 - - - - 5.0
Q 60 4 1
3 5 Q 4 256 0 p8 15 4* 1 - - I 4 256 1 - - 3.77
3 6 Q 4 256 0 p8 15 4* 1 - - - - - - 3.5
3 7 Q 15 256 0 I 15 64 16 p8 73 4* 2 - - - - 3.80
* Here there is one 8PSK stream .
Table 9.5.1.1.3b: Backward compatible settings

Case 1
Parameter set 1
99.9% PAR [dB] 3.61
Br Q
βc 15
DPCCH
SF 256
C 0
Br I
βd 5
DPDCH
SF 64
C 16
Br Q
β hs 4
HS-DPCCH
SF 256
C 64
Br p8
β eu 67
E-DPDCH
SF 4
C 2
Br I
βT 4
E-DPCCH
SF 128
C 1
3GPP
Release 6 92 3GPP TR 25.896 V2.0.0 (2004-03)
accommodated in four BPSK code channels with SF=4
Table 9.5.1.1.4: Cases 1-7

set PAR
2 2 Q 7 256 0 I+Q 15 4 1,3 5.40
2 2 Q 7 256 0 I+Q 15 4 1,3 I 7 256 1 5.65
2 2 Q 7 256 0 I+Q 15 4 1,3 I 14 256 1 5.85
3 1 Q 15 256 0 I 15 64 16 IQ 60 4*4 2,3 Q 15 256 32 I 15 256 1 5.6
3 1 Q 15 256 0 I 15 64 16 IQ 85 2*2 1 Q 15 256 32 I 15 256 1 4.1
3 2 Q 5 256 0 IQ 15 4*4 1,3 - - I 5 256 1 - - 5.5
3 2 Q 4 256 0 IQ 15 2*2 1 - - I 4 256 1 - - 4.1
3 3 Q 5 256 0 IQ 15 4*4 1,3 - - - - - - 5.25
3 3 Q 4 256 0 IQ 15 2*2 1 - - - - - - 3.8
3 4 Q 15 256 0 I 15 64 16 IQ 60 4*4 2,3 - - - - 5.2
3 4 Q 15 256 0 I 15 64 16 IQ 85 2*2 1 - - - - 3.75
3 5 26 - - Q
Q 5 256 0 p8+I 4* 1,3 5 256 32 - - 4.63
15
3 6 26 - -
Q 5 256 0 p8+I 4* 1,3 - - - - 4.50
15
3 7 127 4* 3,1
Q 15 256 0 I 15 64 16 p8Q - - - - 4.58
73
* Here there are one 8PSK stream + 1 BPSK stream.

Case 8 8
Parameter set 2 2
99.9% PAR [dB] 5.60 6.25
Br Q Q
βc 15 15
DPCCH
SF 256 256
C 0 0
Br I I
βd 15 15
DPDCH
SF 64 64
C 8 8
Br Q Q
β hs 15 30
HS-DPCCH
SF 256 256
C 32 32
Br I+Q I+Q
β eu 47 47
E-DPDCH
SF 2 2
C 1 1
Br Q Q
βT 17 30
E-DPCCH
SF 64 64
C 2 2
Br I I
E-DPCCH2 βR 17 30
(request) SF 64 64
C 1 1
3GPP
Release 6 93 3GPP TR 25.896 V2.0.0 (2004-03)

Case 8 8
Parameter set 2 2
99.9% PAR [dB] 5.40 5.91
Br Q Q
βc 15 15
DPCCH
SF 256 256
C 0 0
Br I I
βd 15 15
DPDCH
SF 64 64
C 16 16
Br Q Q
β hs 15 30
HS-DPCCH
SF 256 256
C 64 64
Br I+Q I+Q
β eu 47 47
E-DPDCH
SF 2 2
C 1 1
Br I I
βT 17 30
E-DPCCH
SF 64 64
C 1 1
Br Q Q
E-DPCCH2 βR 17 30
(request) SF 64 64
C 1 1
accommodated in five BPSK code channels with SF=4
Table 9.5.1.1.5: Cases 1-7

set PAR
3 1 IQIQ 2,3,
Q 15 256 0 I 15 64 16 60 5*4 I 15 256 1 Q 15 256 32 6.23
Q 1
3 1 IQ 85 2*2,
Q 15 256 0 I 15 64 16 1,1 I 15 256 1 Q 15 256 32 5.16
Q 60 4
3 2 1,3 - - Q
Q 5 256 0 I 15 5*4 5 256 32 - - 6.05
,2
3 3 1,3 - -
Q 5 256 0 I 15 5*4 - - - - 5.86
,2
3 2 IQ 21 2*2 1 - - Q
Q 5 256 0 5 256 32 - - 4.89
I 15 4 1
3 3 IQ 21 2*2 1 - -
Q 5 256 0 - - - - 4.83
I 15 4 1
3 4 IQIQ 2,3,
Q 15 256 0 I 15 64 16 60 5*4 - - - - 5.99
Q 1
3 4 IQ 85 2*2, 1,1
Q 15 256 0 I 15 64 16 - - - - 4.93
Q 60 4
3 5 p8 26 2 - - I
Q 5 256 0 4* 5 256 1 - - 4.85
IQ 15 3
3 6 p8 26 2 - -
Q 5 256 0 4* - - - - 4.70
IQ 15 3
3 7 p8 127 4* 2,3
Q 15 256 0 I 15 64 16 - - - - 4.67
IQ 73
* Here there are one 8PSK stream + 2 BPSK streams
3GPP
Release 6 94 3GPP TR 25.896 V2.0.0 (2004-03)
accommodated in six BPSK code channels with SF=4
Table 9.5.1.1.6: Cases 1-7

set PAR
2 2 Q 7 256 0 I+Q 15 4 1,3,2 6.25
2 2 Q 7 256 0 I+Q 15 4 1,3,2 I 7 256 1 6.40
2 2 Q 7 256 0 I+Q 15 4 1,3,2 I 14 256 1 6.55
3 1 1,2,
Q 15 256 0 I 15 64 15 IQ 60 6*4 I 15 256 1 Q 15 256 32 6.39
3
3 1 IQ 85 2*2 1
Q 15 256 0 I 15 64 15 I 15 256 1 Q 15 256 32 5.40
IQ 60 2*4 1
3 2 Q 5 256 0 IQ 15 6*4 1,2,3 - - I 5 256 1 - - 6.33
3 3 Q 5 256 0 IQ 15 6*4 1,2,3 - - - - - - 6.15
3 2 IQ 21 2*2 1 - - I
Q 5 256 0 5 256 1 - - 5.29
IQ 15 2*4 1
3 3 IQ 21 2*2 1 - -
Q 5 256 0 - - - - 5.15
IQ 15 2*4 1
3 4 1,2,
Q 15 256 0 I 15 64 15 IQ 60 6*4 - - - - 6.20
3
3 4 IQ 85 2*2 1
Q 15 256 0 I 15 64 15 - - - - 5.17
IQ 60 2*4 1
3 5 Q 4 256 0 p8 15 2*4 * 1,3 - - I 4 256 1 - - 5.31
3 6 Q 4 256 0 p8 15 2*4 * 1,3 - - - - - - 5.20
3 7 Q 15 256 0 I 15 64 16 p8 73 2*4 * 2,3 - - - - 5.03
* Here there are two 8PSK streams. Notice that cases 1 and 4 are not backwards compatible since DPDCH
channelisation code is not according to Rel5 spec.

Case 8 8 8 8
Parameter set 2 2 2 2
99.9% PAR [dB] 6.30 6.70 6.55 7.10
Br Q Q Q Q
βc 15 15 15 15
DPCCH
SF 256 256 256 256
C 0 0 0 0
Br I I I I
βd 15 15 15 15
DPDCH
SF 64 64 64 64
C 8 8 8 8
Br Q Q Q Q
β hs 15 30 15 30
HS-DPCCH
SF 256 256 256 256
C 32 32 32 32
Br I+Q I+Q I+Q I+Q
β eu 47 & 34 47 & 34 47 & 34 47 & 34
E-DPDCH
SF 2&4 2&4 2&4 2&4
C 1 1 1 1
Br Q Q Q Q
βT 17 30 17 30
E-DPCCH
SF 64 64 64 64
C 2 2 2 2
Br I I I I
E-DPCCH2 βR 17 30 17 30
(request) SF 64 64 64 64
C 1 1 1 1
Br Q Q
E-DPCCH3 βP 26 26
(pilot) SF 256 256
C 1 1
3GPP
Release 6 95 3GPP TR 25.896 V2.0.0 (2004-03)
accommodated in three 8PSK streams with SF=4
Table 9.5.1.1.7: Cases 1-7

set PAR
3 5 1,2 - - I
Q 4 256 0 p8 15 3*4 * 4 256 1 - - 6.07
,3
3 6 1,2 - -
Q 4 256 0 p8 15 3*4 * - - - - 5.98
,3
3 7 73 3*4 * 1,2,
Q 15 256 0 I 15 64 16 p8 - - - - 6.00
3
* Here there are three 8PSK streams.
9.5.1.2 Considerations on PAR analysis

The following parameters affect the average energy per chip requirement
• Overhead channels
• Transmission rate or block size
• Target residual physical layer error rate
• Target maximum physical layer delay
• TTI
The energy per chip requirement relates to the system efficiency and does not depend on UE implementation aspects.
The impact of these parameters on the system performance is taken into account in system level simulations to the
extent that the cell layout describe in the TR reflects a real deployment scenario.
The following parameters affect the dynamic of the signal (not the average transmit power):
• Channel configuration
• Respective code channel gains
o These fully depend on the first set of parameters
The signal dynamic affects either the power amplifier complexity or the link budget if the specification allows for a PA
back-off under certain channel configurations. The impact may direct (e.g. 99.9% PAR) or indirect (e.g. impact of
signal dynamic on ACLR). At this stage, all system level simulation results assume that the additional signal dynamic is
handled by the PA; however contrarily to typical R99 configuration being used so far (typical single code UL) the
signal dynamic and associated impact is more sensitive to the operating point.
The following examples illustrate the sensitivity of the PAR increase to the set-point.
9.5.1.2.1 Example based on case 2/5 and parameter set 1

Figure 9.5.1.2.1 illustrates the PAR variation when changing the beta values. The curves are using parameter set a cases
described in section . The reference beta values are the ones listed in section 9.5.1.1; the actual beta_dpch values equal
the reference beta_dpch values multiplied by the factor f listed on the x axis. One should note that case 2 can be seen as
being equivalent to Release-5 situation.
3GPP
Release 6 96 3GPP TR 25.896 V2.0.0 (2004-03)
99.9% PAR for parameters in R1-031367
7.00
Reference point for results

Series1
6.00 shown in R1-031367, Table 3
Series2
Series3
5.00
Series4
Series5
99.9% PAR [dB]
4.00
Series6
Series7
3.00 Series8
Series9
2.00 Series10
Series11
1.00
0.00
0 0.5 1 1.5 2 2.5
f (Beta_dpch = f * Best_dpch_ref)
Figure 9.5.1.2.1
9.5.1.2.2 Example based on case 1,2 (BPSK vs 8-PSK)

This example illustrates the relationship between PAR discussion and performance discussion. Looking at the figure
9.5.1.2.2, one could conclude that using 3 BPSK code is a bad idea and that 8-PSK should be used instead. However
when considering results presented in R1-04-0049, in turns out that in most cases using 3 BPSK codes saves around 2
dB in Ec/Nt requirement compared to 8-PSK.Taking this into account one then concludes that using 3 BPSK codes is
more efficient than using 8-PSK and does not impact the link budget for a particular rate compared to using 8-PSK.
3GPP
Release 6 97 3GPP TR 25.896 V2.0.0 (2004-03)
99.9% PAR for 8-PSK in R1-040049

(Bc=15, Bhs=15, Bd=15)
7.00
1536
kbps
6.00
5.00
99.9% PAR [dB]
4.00
960
3.00 2 x BPSK (SF4) kbps
3 x BPSK (SF4)
1 x 8PSK (SF4)
2 x BPSK (SF2)
2.00
1.00
0.00
0 0.2 0.4 0.6 0.8 1 1.2 1.4
Figure 9.5.1.2.2
9.5.1.2.3 Example for multi-code

Figure 9.5.1.2.3 shows the PAR sensitivity to the number of codes transmitted simultaneously. The reference beta_dpch
equals 100 (selected to cover a large range of possible beta_dpch values)
99.9% PAR for multi-code
8.00
7.00
6.00
5.00
99.9% PAR [dB]
4.00
3.00 1 x QPSK (SF4)

1 x QPSK (SF2)
2 x QPSK (SF2+ SF4)
2 x QPSK (SF4 + SF4)
2.00 3 x QPSK (SF4 + SF4 + SF4)
1.00
0.00
0 0.2 0.4 0.6 0.8 1 1.2
Figure 9.5.1.2.3
3GPP
Release 6 98 3GPP TR 25.896 V2.0.0 (2004-03)
9.5.1.2.4 Discussion
Based on figure 9.5.1.2.1 to 9.5.1.2.3 once can derive a few general remarks:
• PAR impact decreases as the signal is dominated by the DCH/E-DCH energy
• PAR impact increase with the number of code channels used for data transmission
• PAR impact peaks when all code channels are transmitted with about the same power
• PAR impact needs to be considered together with the link level performance
The above observations result in a number of possible options to handle PAR aspects in the context of EUL:
• Should the principle that the PA will absorb any PAR increase and related constraints (ACLR) still apply?
• If not, how should the UE derive the allowed PA back-off?
o Generic PA back-off when using enhanced uplink?
" May result in reduced efficiency with enhanced uplink
o As a function of the channel configuration and gains?
" May become complex to test
" Could be related to the number of code channels (see figure 3)
o Forbid certain configurations with certain gain factors
" For example only allow multi-code E-DPCH when gain factor above a certain beta value
" May result in a trade-off between efficiency and complexity
These options are FFS in the context of a WI phase. System level simulation used to evaluate the merit of the respective
techniques should then consider any solution which would allow the UE to back-off from the nominal maximum
transmit power.
9.6 Results including multiple techniques

9.6.1 Results with HARQ, shorter TTI, time & rate scheduling
This section includes results with HARQ, shorter TTI and time & rate Node B scheduling.
9.6.1.1 Full Buffer results

The following results reflect the relative cell throughput gain of E-DCH (EUL), with 2ms TTI, HARQ and a Node-B
scheduler, over the system with DCH (Rel-99 assumptions), with 10 ms TTI, long scheduling period and centralized
scheduler.
The system configuration is shown in Table 9.4.1.1.1. The TTI is 2ms. Other assumptions are listed in Annex A3.
The MCS for E-DCH is shown in Annex 2.2.1.
The key differences between R99 and E-DCH parameters are summarized in Table 9.6.1.1.1.
3GPP
Release 6 99 3GPP TR 25.896 V2.0.0 (2004-03)
Table 9.6.1.1.1
Parameter R99 E-DCH

TTI 10 ms 2 ms
Enhanced
Nomial TFCS: TFCS: {8, 16,
{16, 32, 64, 96,128, 256, 384,
{8, 16, 32, 64, 32, 64, 128,
TFCS 512, 640, 768, 896, 1024} kbps
128, 256, 384} 256, 384, 768,
after 4 transmissions.
kbps 1152, 1536,
1920} kbps
5 processes
HARQ -
Up to 4 transmissions
Scheduler RNC (centralized) Node-B (decentralized)
The following figures present the system performance in terms of average cell throughput, fairness and RoT overshoot,
defined as Probability {RoT > 7dB}.
Figure 9.6.1.1.1 and Figure 9.6.1.1.2 compare the cell throughput with E-DCH (2ms TTI, PF scheduler), Rel-99
(nominal TFCS, PF scheduler) and Rel-99 (nominal TFCS, DL Sinr scheduler) with the assumptions shown above. It is
seen that compared to Rel-99 with nominal TFCS with PF scheduler, the system performance with E-DCH improves by
70% at 4.5 dB RoT. Higher throughput gain can be observed with higher speed due to the increased time diversity
achieved with retransmissions. On the other hand Rel-99 with DL Sinr scheduler can yield relatively high throughput at
the cost of extremely bad fairness, shown in Figure 9.6.1.1.3.
The RoT overshoot is given in Figure 9.6.1.1.4. It can be seen that the RoT overshoot is smaller with DL Sinr scheduler
with nominal Rel-99 and with EUL with SHO restriction. With DL Sinr, only the best users (in terms of forward link
path loss) are scheduled; with EUL the SHO users can only transmit using the instantaneous rate up to 512kbps,
therefore, the interference is decreased in both cases. Figure 9.6.1.1.5 to Figure 9.6.1.1.8 present the results with each
individual channel models for completeness.
3GPP
Release 6 100 3GPP TR 25.896 V2.0.0 (2004-03)
EUL vs. Nominal Rel-99 - Mixed Channel
1800
Throughput (kbps)
1600
1400
1200
1000
800
600
3 3.5 4 4.5 5 5.5 6 6.5 7
Avg. RoT (dB)
EUL - PF Nom. Rel-99 - PF Nom. Rel-99 - DL Sinr
EUL vs. Nominal Rel-99 - Mixed Channel
100
Relative Gain (%)
80
60
40
20
0
3 3.5 4 4.5 5 5.5 6 6.5 7
Avg. RoT (dB)
EUL, PF vs. Nom. Rel-99, PF

EUL, PF vs. Nom. Rel-99, DL Sinr
Figure 9.6.1.1.2: Throughput gain between EUL and Nominal Rel-99 – mixed channel
3GPP
Release 6 101 3GPP TR 25.896 V2.0.0 (2004-03)
Fairness - mixed channel
100.00%
80.00%
60.00%
CDF
40.00%
20.00%
.00%
0 0.5 1 1.5 2 2.5 3
EUL-PF Nom. Rel-99-PF Nom. Rel-99-DL Sinr
RoT overshoot - mixed channel
20
Pr[RoT>7dB] (%)
15
10
0
3 3.5 4 4.5 5 5.5 6 6.5 7
Avg. RoT (dB)
3GPP
Release 6 102 3GPP TR 25.896 V2.0.0 (2004-03)
EUL vs. Nominal Rel-99 - PA3
1900
Throughput (kbps)
1700
1500
1300
1100
900
700
3 3.5 4 4.5 5 5.5 6 6.5 7
Avg. RoT (dB)
Figure 9.6.1.1.5 Average cell throughput as a function of average RoT – PA3
EUL vs. Nominal Rel-99 - PB3
1500
Throughput (kbps)
1300
1100
900
700
500
3.5 4 4.5 5 5.5 6 6.5 7
Avg. RoT (dB)
Figure 9.6.1.1.6: Average cell throughput as a function of average RoT - PB3
3GPP
Release 6 103 3GPP TR 25.896 V2.0.0 (2004-03)
EUL vs. Nominal Rel-99 - VA30
1700
Throughput (kbps)
1500
1300
1100
900
700
500
3 3.5 4 4.5 5 5.5 6 6.5
Avg. RoT (dB)
Figure 9.6.1.1.7: Average cell throughput as a function of average RoT -- VA30
EUL vs. Nominal Rel-99 - PF, VA120

Throughput (kbps)
1450
1250
1050
850
650
450
2.5 3 3.5 4 4.5 5 5.5 6 6.5
Abg. RoT (dB)
Figure 9.6.1.1.8: Average cell throughput as a function of average RoT - VA120
Recall that the Rel-99 throughput could be increased with higher capability UE class. To illustrate this point the system
level results are provided in Figure 9.6.1.1.9 and Figure 9.6.1.1.10 with TF {768, 1152, 1536, 1920} kbps included.
These enhanced TFs can be achieved by using up to 5 DPDCHs simultaneously. At 4.5dB average RoT, the gain
associated with introducing enhanced TFs with Rel-99 is about 6.7%; while the fairness curve gets a bit worse than that
of Rel-99 with nominal TFCS, which is given in Figure 9.6.1.1.11. The RoT overshoot is clearly much larger with
enhanced TFCS, shown in Figure 9.6.1.1.12.
3GPP
Release 6 104 3GPP TR 25.896 V2.0.0 (2004-03)
EUL-Nominal Rel-99-Enhanced Rel-99-PF
1800
Throughput (kbps)
1600
1400
1200
1000
800
600
3 3.5 4 4.5 5 5.5 6 6.5 7
Avg. RoT (dB)
EUL Nom. Rel-99 En. Rel-99
Figure 9.6.1.1.9: Average cell throughput as a function of average RoT
EUL-Nominal Rel-99-Enhanced Rel-99-PF
100
Throughput (kbps)
80
60
40
20
0
3.5 4 4.5 5 5.5 6 6.5 7
Avg. RoT (dB)
EUL vs. Nom. Rel-99 EUL vs. En. Rel-99

En. Rel-99 vs. Nom. Rel-99
Figure 9.6.1.1.10: Throughput gain between EUL and Rel-99 - PF
3GPP
Release 6 105 3GPP TR 25.896 V2.0.0 (2004-03)
Fairness - PF
100.00%
80.00%
60.00%
CDF
40.00%
20.00%
.00%
0 0.5 1 1.5 2 2.5
Figure 9.6.1.1.11: Fairness curves with EUL and Rel-99
RoT overshoot - Rel-99
25
Pr [RoT>7dB] (%)
20
15
10
5
0
3 3.5 4 4.5 5 5.5 6 6.5 7
Avg. RoT (dB)
9.6.1.2 Mixed traffic model results

The following results reflect the relative cell throughput gain of E-DCH (EUL), with 2ms TTI, HARQ and a Node-B
scheduler, over the system with DCH (Rel-99 assumptions), with 10 ms TTI, long scheduling period and centralized
scheduler.
The system configuration is shown in Table 9.6.3. Other assumptions are as listed in Annex A3.
3GPP
Release 6 106 3GPP TR 25.896 V2.0.0 (2004-03)
Table 9.6.3
Site to site distance = 2800 m
Channel model Mixed (PA3 30%, PB3 30%, VA30 20% and VA120 20%)
Traffic model Mixed (4 FTP, 4 Video, 4 Gaming)
#UE per cell 12
UE timing UEs are time aligned
Duration 200 s + 10 s warm-up
HARQ Max # of transmissions = 4
# of HARQ processes = 5
Re-transmission delay = 10 ms
Ack/Nack errors = 0%
Scheduling algorithm Proportional fair
Scheduling Type Rel-99:
RNC scheduler/controller, scheduling period 200 ms
E-DCH:
As described in R1-03-1246. Decentralized Node-B scheduler with
1 serving cell per UE = best DL (same as HSDPA serving cell). All cells in
Scheduling delays
DCH E-DCH
Period 200 ms 2 ms
Uplink SI delay Uniform 60-100 ms 10 slots
DL Grant delay Uniform 60-100 ms 1 slot
Power control Outer loop driven by 1% BLER on DPDCH

Inner loop error rate = 4%
DCH TFCS = 8 kbps (100% duty cycle)
Minimum set: 8 kbps
Reference link level data as presented in R1-03-1380

E-DCH TFCS = TFS = MCS as shown in Table 2
Minimum set is empty
E-TFC elimination:
Reference link level data as presented in Annex 2.2.1

E-DPCCH Beta = 17
(based on results in section 9.2.4)
SHO E-DCH: When in SHO E-TFS is restricted to MCS-3
(denoted as with SHO restriction)
DCH: No SHO restriction
(denoted as without SHO restriction)
The MCS for E-DCH is shown in annex A.2.2.1. Table 9.6.1.2.1 shows the values of tau parameters used for FTP users.
3GPP
Release 6 107 3GPP TR 25.896 V2.0.0 (2004-03)
Table 9.6.1.2.1: Tau parameters used for FTP

segment to travel from Node-B to the server and Mean = 50 ms.
the time taken by an ACK packet to travel from
the server to Node-B
Time taken by the ACK to travel from Node-B to τ3 Lognormal distribution
client Mean = 50 ms
retransmissions from residual uplink physical = 0 ms, if packet is not in error after all
layer BLER physical layer retransmissions
= 200 ms, else
Figure 9.6.1.2.1 shows the system throughput as a function of the average RoT. The significant gain of the E-DCH over
the Rel-99 can be observed, and it is presented in percentages in Figure 9.6.1.2.2.
The RoT overshoot is given in Figure 9.6.1.2.3. It can be seen that the RoT overshoot is smaller for E-DCH results,
primarily due to the SHO restriction, since the other cell interference is decreased as compared to the case without it
(Rel-99). For the fixed RoT overshoot, the corresponding average RoT is higher for E-DCH, which implies higher
throughput.
The cumulative density function (CDF) of user throughputs normalized by the average throughput per user is used to
represent the fairness. The fairness curve, given in Figure 9.6.1.2.4, shows that the fairness is degraded for E-DCH
compared to Rel-99, primarily due to the SHO restriction and higher data rates.
Figures 9.6.1.2.5 to 9.6.1.2.8 present the average packet call delays and the average packet delays. Packet call delay is
the time between two consecutive reading periods. For Gaming users, packet call delay represents the time of a gaming
session that includes the time during which the packets are generated (active period), and the time needed for
transmission of the data packets accumulated during the active period. For FTP users, packet call delay is the time
needed for an FTP file upload. Packet delay is the time needed for a packet to be received at a Node-B. It can be seen
that the delays are considerably decreased for E-DCH when compared to the Rel-99.
Figures 9.6.1.2.9 to 9.6.1.2.12 show the CDF of the packet call delays and packet delays, for both E-DCH and Rel-99. It
can be seen that the delay characteristics of the E-DCH are superior over the Rel-99, for all traffic models.
3GPP
Release 6 108 3GPP TR 25.896 V2.0.0 (2004-03)
1600
1400
Cell Throughput [kbps]
1200
1000
800
600
400
3.5 4 4.5 5 5.5 6 6.5
Average RoT [dB]
Rel-99 EUL PF
Figure 9.6.1.2.1: Average cell throughput as a function of the average RoT
100
90
80
Cell Throughput Gain [%]
70
60
50
40
30
20
10
0
3.5 4 4.5 5 5.5 6 6.5
Average RoT [dB]
Figure 9.6.1.2.2: Cell throughput gain of EUL over Rel-99 as a function of the average RoT
3GPP
Release 6 109 3GPP TR 25.896 V2.0.0 (2004-03)
RoT Overshoot
30
25
Pr{RoT > 7dB} [%]
20
15
10
0
3.5 4 4.5 5 5.5 6 6.5
Average RoT [dB]
Rel-99 EUL PF
Fairness Curve
0.9
0.8
0.7
0.6
CDF
0.5
0.4
0.3
0.2
0.1
0
0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2
Rel-99 EUL PF
Figure 9.6.1.2.4: Fairness curves for EUL and Rel-99
3GPP
Release 6 110 3GPP TR 25.896 V2.0.0 (2004-03)
Packet Call Delay for FTP Users
200
180
160
140
120
100
80
60
40
20
0
3.5 4 4.5 5 5.5 6 6.5
Average RoT [dB]
Rel-99 EUL PF
Figure 9.6.1.2.5: Average packet call delay for FTP users, for EUL and Rel-99
Packet Call Delay for Gaming Users
40
35
30
25
20
15
10
0
3.5 4 4.5 5 5.5 6 6.5
Average RoT [dB]
Rel-99 EUL PF
Figure 9.6.1.2.6: Average packet call delay for Gaming users, for EUL and Rel-99
3GPP
Release 6 111 3GPP TR 25.896 V2.0.0 (2004-03)
Packet Delay for FTP Users
50
45
40
35
Packet Delay [s]
30
25
20
15
10
0
3.5 4 4.5 5 5.5 6 6.5
Average RoT [dB]
Rel-99 EUL PF
Figure 9.6.1.2.7: Average packet delay for FTP users, for EUL and Rel-99
Packet Delay for Video Users
3.5
3
Packet Delay [s]
2.5
1.5
0.5
0
3.5 4 4.5 5 5.5 6 6.5
Average RoT [dB]
Rel-99 EUL PF
Figure 9.6.1.2.8: Average packet delay for Video users, for EUL and Rel-99
3GPP
Release 6 112 3GPP TR 25.896 V2.0.0 (2004-03)
Packet Call Delay - FTP Traffic
0.9
0.8
0.7
0.6
CDF
0.5
0.4
0.3
0.2
0.1
0
0 20 40 60 80 100 120 140 160 180 200
EUL Rel99
Figure 9.6.1.2.9: CDF of the packet call delays for EUL and Rel-99 for FTP users
Packet Call Delay - Gaming Traffic
0.9
0.8
0.7
0.6
CDF
0.5
0.4
0.3
0.2
0.1
0
0 5 10 15 20 25 30
EUL Rel99
Figure 9.6.1.2.10: CDF of the packet call delays for EUL and Rel-99 for Gaming users
3GPP
Release 6 113 3GPP TR 25.896 V2.0.0 (2004-03)
Packet Delay - FTP Traffic
0.9
0.8
0.7
0.6
CDF
0.5
0.4
0.3
0.2
0.1
0
0 10 20 30 40 50
Packet Delay [s]
EUL Rel99
Figure 9.6.1.2.11: CDF of the packet delays for EUL and Rel-99 for FTP users
Packet Delay - Video Traffic
0.9
0.8
0.7
0.6
CDF
0.5
0.4
0.3
0.2
0.1
0
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5
Packet Delay [s]
EUL Rel99
Figure 9.6.1.2.12: CDF of the packet delays for EUL and Rel-99 for Video users
9.6.2 Results with HARQ, 10ms TTI, rate scheduling with persistence
9.6.2.1 Full Buffer results

The following results reflect the relative cell throughput gain of E-DCH, with 10ms TTI, HARQ and with Node-B rate
control with persistence, over the system with DCH (Release 99), with 10 ms TTI, 200ms scheduling period and a
centralized (RNC based) Round Robin scheduler.
The system configuration is shown in Table 9.6.2.1 Other assumptions are as listed in Annex A3.
3GPP
Release 6 114 3GPP TR 25.896 V2.0.0 (2004-03)
From Figure 9.6.2.1 it can be seen that use of the E-DCH with Node-B Rate control with persistence compared to
Release 99 uplink with 200ms Time sliced Round Robin yields approximately a 60% improvement in user and cell
throughput and 30% reduction in outage (%UEs with user throughput < 16Kbps) for similar RoT statistics as shown in
Table 9.6.2.3. For longer RLC round trip time delay and lower R99 dropped frame targets (x% users with >1% dropped
frames) the throughput improvement is over 80%.
Figure 9.6.2.2 presents the fairness curve, defined in terms of CDF of the normalized user throughputs. It shows that the
fairness remains approximately the same for DCH and E-DCH.
9.6.2.2 Mixed traffic model results

The following results reflect the relative cell throughput gain of E-DCH, with 10ms TTI, HARQ and with Node-B rate
control with persistence, over the system with DCH (Release 99), with 10 ms TTI, 200ms scheduling period and a
centralized (RNC based) Round Robin scheduler.
The system configuration is shown in Table 9.6.2.1 Other assumptions are as listed in Annex A3.
From Figure 9.6.2.3 it can be seen that use of the E-DCH with Node-B Rate control with persistence compared to
Release 99 uplink with 200ms Time sliced Round Robin yields for Gaming traffic approximately a 30% and 45%
improvement in cell and user throughput respectively and 10% reduction in outage (%UEs with user throughput <
16Kbps) for similar RoT statistics as shown in Table 9.6.2.5. For NRTV (64Kbps streaming) traffic the outage (%
users with more than 2% late (dropped) packets) is reduced by almost 45% while for the Mixture case (1/3 FTP, 1/3
NRTV, 1/3 Gaming) the cell and user throughput is increased by 15% and 50% respectively.
Figure 9.6.2.4 presents the delay curve for Gaming traffic, defined in terms of reduction in average packet call delay. It
shows that about a 40% improvement for E-DCH over DCH until the edge of the cell is approached which occurs for a
transmission gain of around 125dB.
Figure 9.6.2.5 presents the fairness curve for Gaming traffic, defined in terms of CDF of the normalized user
throughputs. It shows that the fairness remains approximately the same for DCH and E-DCH.
3GPP
Release 6 115 3GPP TR 25.896 V2.0.0 (2004-03)
Table 9.6.2.1
Site to site distance = 2800 m
Channel model PB3 (Pedestrian B, 3km/h)
Traffic model Full buffer or Gaming, FTP, NRTV
Node-B Receiver Rake (2 antennas per cell)
8 fingers per UE (finger assignment as in Table A-6)
#UE per cell 5 or 10 (as indicated)
UE timing Time aligned (no offset between users)
Duration 300 s + 10 s warm-up per Monte Carlo drop (up to 20 drops)
HARQ Max # of transmissions = 4 (Chase/IR combining)
N = # of HARQ processes = 3, Re-transmission delay = 30 ms
Ack/Nack errors = 0%
Scheduling Type R99: (RNC)
Round Robin scheduler with 200ms scheduling period. Maximum CDM
and rate controlled per cell based on Rise over Thermal measurements.
E-DCH: (Node-B) Time + Rate

Node-B Proportional Fair scheduler with
1 serving cell per UE = best DL (same as HSDPA serving cell). All cells in
E-DCH: (Node-B) Rate + Persistence

CDM users transmit autonomously while the maximum data rate and
hence the rise over thermal level is controlled by Node-B using a
persistence parameter which is signaled by the Node-B.
Scheduling delays
DCH E-DCH
Time+rate
Period 200 ms 10 ms
Uplink SI delay Uniform 60-100 ms 10 slots
DL Grant delay Uniform 60-100 ms 1 slot
RLC delay 100ms or 200ms 100ms or 200ms
Power control Outer loop driven by ZTB 1.6Kbps 10ms TTI and DPDCH services
Inner loop error rate = 4%, delay = 1slot, step size=1dB
PA size: 21dBm,
TFC power measurement error: 2dB std dev.
TFC power measurement delay: 3 slots
DCH TFCS = 8,16,32,64,128,256,384 Kbps (see Table 9.6.2.2)
Minimum set: DCCH (βc,βd)=(15,4), ZTB (βc,βd)=(15,9), SID (βc,βd)=(15,7)

Reference link level data as presented in R1-040016, R1-040227.
E-DCH TFCS = TFS = MCS as shown in Table 9.6.2.2
Minimum set: DCCH, ZTB, SID (if speech+data)
E-TFC elimination:
Reference link level data as presented in R1-040016, R1-040227

E-DPCCH TFCI on DPCCH is used to indicate TFC for 10ms TTI
TFC indicated with 20Kbps TFRI channel for 2ms TTI
SHO When in SHO E-TFS is restricted via R99 TFC selection
Channel Estimation BW=625Hz, non-ideal & modeled in system simulation
(see R1-031276,R1-030313])
Vehicular 6 dB (see link budget Annex B R1-040016)
Penetration/Body Loss
3GPP
Release 6 116 3GPP TR 25.896 V2.0.0 (2004-03)
The TFC for DPDCH and E-DCH are shown in Table 9.6.2.2
Table 9.6.2.2 DCH and E-DCH Per TFC relative power levels
TFC --> 12.2 8 16 32 64 128 256 384 Kbps
beta_d 13 12 15 15 15 15 15 15
beta_c 15 15 15 11 8 6 4 3
Ec/Nt total -17.1 -17.4 -16.5 -14.9 -12.9 -10.9 -7.7 -5.3 dB
DPCCH Ec/Nt -19.5 -19.5 -19.5 -19.5 -19.5 -19.5 -19.5 -19.5 dB
DPDCH Ec/Nt -20.7 -21.4 -19.5 -16.8 -14.0 -11.5 -8.0 -5.5 dB
DPDCH Pwr Offset -1.2 -1.9 0.0 2.7 5.5 8.0 11.5 14.0 dB
TFC --> 640 768 960 1152 1280 1440 Kbps

beta_d 23 26 30 26 29 22
beta_c 4 4 4 3 3 2
Ec/Nt total -4.2 -3.1 -1.9 -0.6 0.2 1.3 dB
DPCCH Ec/Nt -19.5 -19.5 -19.5 -19.5 -19.5 -19.5 dB
DPDCH Ec/Nt -4.3 -3.2 -2.0 -0.7 0.2 1.3 dB
DPDCH Pwr Offset 15.2 16.3 17.5 18.8 19.7 20.8 dB
Rates 640Kbps thru 1440Kbps use QPSK modulation
RLCdelay=100ms, R99:3% users w. >1% dropped frames targeted

RLCdelay=200ms, R99:2% users w. >1% dropped frames targeted
100.0
90.0
Channel: PB3
80.0 Load: 10UEs/Cell
70.0
Improvement (%)
60.0
50.0
40.0
30.0
20.0
10.0
0.0
Cell T-put User T-put Outage Reduction
Figure 9.6.2.1: T-put gain of E-DCH over DCH for similar RoT – Full Buffer
3GPP
Release 6 117 3GPP TR 25.896 V2.0.0 (2004-03)
Table 9.6.2.3 System/User Performance for Full Buffer traffic, PB3

Avg %Users>1% Outage
Uplink Rise Statistics
Scheduling Cell TTI Cell User dropped (User T-put
Cases Load T-put T-put Frames <16Kb/s) 50%-ile 90%-ile 98%-ile Avg Std
(UEs) (Kb/s) (Kb/s) (%) (%) (dB) (dB) (dB) (dB) (dB)
RLC Delay=100ms
1) EU: Rate+Persist., N=2 5 10ms 1201 248 0.0 15.2 7.0 8.9 10.7 7.3 1.7
RLC Delay=200ms
RLC Delay=100ms
5) R99: Rrobin 5 10ms 870 177 2.5 15.0 6.1 8.2 9.9 6.1 2.4
6) R99: Rrobin 10 10ms 866 88 3.8 24.2 6.7 8.7 10.4 6.8 3.1
RLC Delay=200ms
7) R99: Rrobin 5 10ms 830 169 1.9 15.7 5.6 7.9 10.4 6.0 3.0
8) R99: Rrobin 10 10ms 747 76 2.7 24.4 6.1 8.7 11.2 6.5 3.5
0.9
0.8
0.7
0.6
CDF
0.5
0.4
Round Robin - R99
0.3
Time+Rate Scheduling - EU
0.2 Rate+Persistence Scheduling - EU
0.1
0
0.00 0.50 1.00 1.50 2.00 2.50 3.00 3.50 4.00
Figure 9.6.2.2: Full Buffer Fairness curve for PB3 (RLC delay=200ms)
3GPP
Release 6 118 3GPP TR 25.896 V2.0.0 (2004-03)
60.0
Channel: PB3
Load: 10UEs/Cell
EU %improvement over R99 50.0
40.0
Gaming
30.0 NRTV
MIX
20.0
10.0
0.0
Cell T-put User T-put Outage Reduction
Figure 9.6.2.3: E-DCH improvement over DCH for similar RoT
Table 9.6.2.5 System/User Performance for different traffic

R99 & EU Avg %Users>1% Outage*
Uplink Rise Statistics
Cases Cell TTI Cell User dropped
for PB3 Load T-put T-put Frames 50%-ile 90%-ile 98%-ile Avg Std
(Kb/s) (Kb/s) (%) (%) (dB) (dB) (dB) (dB) (dB)
Gaming: Rate+Persist. 10 10ms 888 156 0.0 17.9 6.7 9.1 11.8 7.1 3.4
Gaming: R99 10 10ms 690 108 2.1 19.9 5.7 8.3 10.9 6.1 3.6
NRTV: Rate+Persist. 10 10ms 519 52 na 21.8 5.8 8.1 10.2 6.2 2.6
NRTV: R99 10 10ms 480 48 na 37.9 5.2 8.0 10.7 5.6 3.9
MIX: Rate+Persist. 10 10ms 688 141 0.0 20.8 6.6 8.8 11.3 6.8 3.5
MIX: R99 10 10ms 585 93 1.5 23.6 5.7 8.4 10.7 6.0 3.5
* Gaming, FTP outage: User t-put < 16Kbps, NRTV outage: >2% packets late (dropped)
3GPP
Release 6 119 3GPP TR 25.896 V2.0.0 (2004-03)
60
Average Packet Call Delay Reduction (%)

50
40
30
20
10
0
90 95 100 105 110 115 120 125 130 135 140
Transmission Gain (-pathloss+shadowing+antenna gains) in dB
Figure 9.6.2.4 Gaming Traffic: E-DCH Delay Reduction over DCH for PB3
EU: Rate + Persistence R99: Round Robin

1
0.9
0.8
0.7
0.6
CDF
0.5
0.4
0.3
0.2
0.1
0
0 0.5 1 1.5 2 2.5 3
Figure 9.6.2.5 Gaming Traffic Fairness curves for PB3
Table 9.4.1.2.2 shows the values of tau parameters used for FTP users.
3GPP
Release 6 120 3GPP TR 25.896 V2.0.0 (2004-03)
Table 9.6.2.6: Tau parameters used for FTP

The uplink transmission time of a TCP data segment τ1 Determined by uplink throughput
from the client to the Node-B
The sum of the time taken by a TCP data segment to τ2 Exponential distribution
travel from Node-B to the server and the time taken by Mean = 50 ms.
an ACK packet to travel from the server to Node-B
Time taken by the ACK to travel from Node-B to client τ3 Lognormal distribution
Mean = 50 ms
Increased delay to account for RLC retransmissions τ4 Constant
from residual uplink physical layer BLER = 0 ms, if packet is not in error after all
physical layer retransmissions else
= 100ms or 200 ms
9.7 Compatibility of the enhancements with existing releases

9.7.1 Compatibility at the edge of coverage
It is possible that EUL related functionality will not be deployed across the a whole network from the beginning. This
section addresses the compatibility at the edge of enhanced uplink coverage, that is compatibility of the new
functionality with Node Bs based on earlier releases.
It should be noted that compatibility issue relates to the uplink transmission; for the downlink transmission using the
new functionality, the receiving UE is by definition supporting the new functionality and aware (through signaling
mechanisms) of the edge of coverage situation (i.e. radio link sets being received from Node Bs which support and
don’t support the new functionality)
In general terms there are two possible situations:
1. The new functionality is not transparent and affects legacy Node B’s covering the area in the first ring around
the area covered by Node Bs supporting the new functionality.
2. The new functionality is transparent or hidden to legacy Node B and does not affect their behavior.
9.7.1.1 Non transparent functionality

There are two possible options to address the first situation:
1. Perform a minimum upgrade of the legacy Node Bs such that they can cope with the modified UE behavior
without specifically supporting the new functionality.
2. Sacrifice the Node Bs with the new functionality covering the outer ring and use this area as a buffer zone to
signal a UE reconfiguration back to the legacy functionality, thus allowing the Node Bs covering the area
outside the enhanced cluster to seamlessly handle the particular UE.
These options are always available and do not require particular attention during the design phase of the enhanced
functionality as they relate to deployment aspects; however they essentially require upgrades to the Node Bs covering
area surrounding the area in which the enhanced functionality should be supported.
9.7.1.2 Transparent functionality

By definition this approach relies on the design of a new functionality or on the use of existing functionality to ensure
that legacy Node Bs can handle the new functionality without any modification. The following addresses the Node B
based control, HARQ and shorter TTI functionality in that respect.
Node B based control is essentially transparent to a legacy Node B. Whether the UE TFC selection obeys RNC based
commands or neighboring Node B based commands does not affect the processing of the actual data by a legacy Node
B. As such Node B based control does not create any compatibility issue. However, Node B based control may rely on
3GPP
Release 6 121 3GPP TR 25.896 V2.0.0 (2004-03)
uplink feedback for UE specific TFC control or TFC assignment. Introduction of this additional uplink signaling
channel could be transparent to legacy Node B by using DPCCH puncturing if the number of bits is small or a separate
code channel.
Support of HARQ in the uplink involves at least the signaling of some control information in order to allow the Node B
to properly combine the various transmissions of different data blocks. Again, this control information can be punctured
in what could be seen as a legacy DCH by a legacy Node B (assuming no change to the channel structure) or could be
mapped on a separate code channel. With the puncturing option, the legacy Node B may not be able to successfully
decode the data (again assuming no change to the channel structure); however, as long as the Node B is configured such
that these deterministic errors would not negatively affect the power control behavior, such errors are not an issue. In
the same way, if the HARQ scheme relies on incremental redundancy or if a new modulation is introduced this would
only result in the legacy Node B not being able to decode the data but would not affect the compatibility for legacy
DCH. Alternatively, the E-DCH could be mapped to a separate set of code channels which would not be visible to the
legacy Node B.
Introduction of a shorter TTI affects the channel multiplexing structure and procedure. The straightforward option that
is transparent to legacy Node Bs is the use of separate code channels for the E-DCH transmission.
In summary one can note that the functionality considered in support of enhanced uplink operation could be introduced
in a way that is transparent to legacy node Bs.
9.7.2 Legacy UE
This section addresses the impact of introducing new functionality on legacy UE and associated system performance.
Support of higher data rates and possibly shorter TTI in the uplink could potentially result in higher variance in the intra
and inter cell interference; this could in turn result in reduced performance of legacy DCH. However, the important
metric should be the overall capacity, including voice and data, not just the voice or legacy data capacity. As is
suggested by results presented in section [tbd] it seems that the net result is an increase in data throughput when
supporting the same number of voice users.
An important special case is the border area between legacy Node B and Node B supporting the new functionality. In
this area, the capacity in the area covered by the legacy Node Bs may be affected by the additional interference resulting
from UEs operating in the area covered by Node Bs which support the new functionality. However, the new
functionality itself enables the system to control the potential interference and interference variance and could be
configured in the border area such that the capacity impact in the legacy area is minimum if not null.
9.7.3 Link budget

This section addresses the impact on the uplink link budget. The link budget is potentially affected by increased peak to
average and increased peak transmit power requirement to achieve a certain rate.
Introduction of new control fields in the uplink slightly (in relative terms) increases the amount of data (and power)
needed to close the link.
Introduction of HARQ seems to result in higher power requirement since it calls for higher peak rate transmission to
achieve the same rate as seen by higher layers. However, HARQ actually improves the efficiency of the transmission
such that for a certain link budget a UE can transmit with a higher throughput. All the system level results presented in
chapter 9 take into account the UE maximum transmit power limit and cell radius; as such the link budget is therefore
the same for both legacy uplink and uplink with the new functionality.
Introduction of new code channels affects the peak to average of the resulting signal and results in requirement for
additional power amplifier back-off or for more complex power amplifier (larger, better or smarter). Specifically,
introduction of new code channels in itself does not affect the link budget but the power amplifier complexity. The link
budget would only be affected if one would want to re-use a power amplifier designed for legacy uplink channel
structure.
9.7.4 DL capacity
The downlink capacity is affected by the DL control channels to support the new uplink functionality; this includes
control data for TFC control or assignment procedure and control data for the HARQ functionality. The impact on
average DL capacity is expected to be relatively small. However the variance of the impact expected to be larger (e.g.
when handling UE at the edge of the cell) and this may affect the capacity of the cell if the cell resource is only used for
3GPP
Release 6 122 3GPP TR 25.896 V2.0.0 (2004-03)
streaming services. In contrast there would be minimum impact if part of the cell resource is used for best effort
services since the resource could temporarily be preempted to transmit the UL related control information.
9.7.5 Design re-use

Although the goal of the study item was not to decide on the details of each functionality it is apparent that the existing
structure, procedures and blocks can be and will be re-used as much as possible. This is strongly driven by the
backward and forward compatibility requirement and desire to minimize the increase in complexity.
9.7.6 Conclusion
Based on above considerations one can conclude that it is feasible to introduce new uplink functionality in a way that is
fully compatible with systems deployed based on existing releases.
10 Impacts to the Radio Interface Protocol Architecture
10.1 Protocol Model

The proposed new MAC entity (Chapter 8.1.1) is introduced to the Rel99/4/5 MAC sub-layer on UE and network side
and covers the E-DCH specific functionality.
Figure 10.1 is an example protocol model for E-DCH. In case that inter-Node B soft handover is supported for E-DCH,
the macro diversity selection combining (MDC)3 and reordering operation may take place in the MAC-es of the serving
RNC (MAC-es represents MAC-e functionality of the serving RNC.) Otherwise, the MAC-es functionality is null given
that the reordering function would reside in the MAC-e of the Node B.
DTCH DCCH DCCH DTCH
MAC-d
MAC-d
MAC-es (MDC)
MAC-e EDCH
MAC-e FP EDCH FP
PHY PHY TNL TNL
Iub/Iur
UE Uu NodeB C-RNC/S-RNC
Figure 10.1: Example of protocol model for E-DCH transport channel
10.1 Introduction of new MAC functionality

The new functionalities of Node B controlled Hybrid ARQ and Node B controlled scheduling, considered as
enhancements for the uplink dedicated transport channel, require the introduction of new MAC functionalities. These
new functionalities could be partly added to the existing MAC-d, e.g. reordering or TFC selection, or included in a new
MAC entity, as proposed in chapter 8.1.1. This new MAC entity, which is referred to as MAC-e, is added to the
Rel99/4/5 MAC sublayer on UE and on network side and covers HARQ related functionality, e.g. generation of
ACK/NACK and retransmissions, as well as the scheduling related functionality. For the definition of the MAC
architecture and functionality of the new MAC entity, issues like TFC selection, number of E-DCH transport channels
and location of the reordering entity need to be considered, since they have a big impact on the overall architecture. The
introduction of a new MAC entity will have an impact on TS25.321.
3 In R’99 the MDC function is considered to be a physical layer functionality of the SRNC.
3GPP
Release 6 123 3GPP TR 25.896 V2.0.0 (2004-03)
10.1.1 Introduction of an enhanced uplink dedicated transport channel (E-

DCH)
The support of the uplink enhancements, considered in RAN WG1, requires the introduction of an enhanced uplink
dedicated transport channel, called E-DCH. It still remains to be decided whether there will be a new transport channel
added to RAN specification.
If only one E-DCH transport channel is supported, similar to HSDPA, MAC-e multiplexing may be required to
multiplex several MAC-d flows into one E-DCH. In case several E-DCH transport channels are supported, each MAC-d
flow is mapped to one transport channel. It needs to be decided whether there are only one or several E-DCH transport
channels simultaneously allowed in the same TTI. The simultaneous support of transport channels with different
transmission modes, e.g. different TTI lengths or different scheduling approaches, may for example require several E-
DCH transport channels per TTI.
10.1.2 HARQ functionality

Node B controlled Hybrid ARQ allows for rapid retransmissions of erroneously received data packets between UE and
Node B. A similar retransmission scheme as employed for the HS-DSCH in HSDPA can be used for the E-DCH. It has
to be defined whether to adopt a retransmission protocol with asynchronous or synchronous uplink data transmission
and with asynchronous or synchronous downlink feedback signalling.
Support of E-DCH HARQ functionality during soft handover is under consideration and link imbalances in soft
handover may lead to unsynchronised soft buffers among different Node Bs. Enhancements in HARQ protocol
operation, e.g. soft buffer synchronisation, should be discussed in order to provide a reliable HARQ protocol operation
during soft handover.
10.1.3 Reordering entity

Since RLC requires in-sequence delivery the location of the reordering entity should be defined. Possible locations for
the reordering entity are Node B and RNC. Such decision also depends on whether soft handover is supported or not.
10.1.4 TFC selection

In Rel5 TFC selection in the UE shall be done in accordance with the priorities (logical channel priority) indicated by
RRC. In case the same functionality with different logical channel priorities should be maintained in enhanced uplink
DCH, the TFC selection in the UE has to take both E-DCH and DCH into account in case of a simultaneous
transmission on E-DCH and DCH. TFC Selection for E-DCH can be either done jointly with TFC selection for Rel99/5
DCH channels in MAC-d or in the new MAC-e entity. Some interaction between MAC-e and MAC-d is in both cases
required. Furthermore the logical channel priorities for E-DCH need to be discussed.
The impact of multiple CCTrChs and a possible adoption of a shorter TTI on the TFC selection algorithm should be
clarified. Furthermore the minimum set of TFCs in the presence of E-DCH should be also discussed.
10.2 RLC
Since the E-DCH is intended to transport dedicated logical channels, layers above the MAC layer should be kept as in
Rel99/4/5.
10.3 RRC
To support the uplink enhancements, required new signaling should be added to the RRC specification TS25.331.
3GPP
Release 6 124 3GPP TR 25.896 V2.0.0 (2004-03)
11 Impacts to Iub/Iur Protocols
11.1 Impacts on Iub/Iur Application Protocols

Enhancements considered for the uplink dedicated transport channels like Node B scheduling and Node B controlled
HARQ will have an impact on the Iub/Iur application protocols, RNSAP and NBAP, TS25.423 and TS25.433
respectively.
To support E-DCH, application protocol procedures for setup, addition, reconfiguration and deletion of related radio
links will have to be supported. This will very likely have an impact on Common NBAP procedures (e.g. Radio Link
Setup), Dedicated NBAP procedures (e.g. Radio Link Reconfiguration) and corresponding RNSAP DCH procedures.
And as in the HSDPA case, CRNC might need to allocate resources to Node B. In addition, the scheduling performed
by serving Node B only is decentralized, and only limited information is available. To improve the accuracy of the
scheduling, some communication between the RNC and Node Bs and possibly between different RNCs might be
necessary. For example, the contribution of UEs scheduled by other serving Node Bs from the Active Set to the uplink
interference level (relative to target RoT – rise over thermal) in the serving Node B might be necessary for an efficient
scheduling in Node B. For the efficient scheduling, certain changes in NBAP Common Measurement and related
RNSAP Global procedures might be required.
Impacts of Fast DCH setup on the application protocols are FFS.
11.2 Impacts on Frame Protocol over Iub/Iur

The introduction of a new Frame Protocol for the E-DCH across Iub/Iur interface needs to be considered. Furthermore
since HARQ operation during soft handover is considered to be supported, Iub/Iur signalling might be required in order
to provide a reliable protocol operation during soft handover. Alternatively the current DCH FP could be enhanced, e.g.
new IEs or Control Frames could be defined. Moreover since shorter TTI for the air interface is under study, possible
impact to the frame protocol needs to be considered
12 Conclusions and Recommendations
12.1 Conclusions
In the study of “Uplink Enhancements for Dedicated Transport Channels”, the following techniques have been
considered:
- Node B controlled scheduling
- Hybrid ARQ
- Shorter TTI
- Higher order modulation
- Fast DCH setup
Simulation results presented to RAN1 has shown a significant improvement compared to Rel5, in the order of 50%-
70% increase in system capacity, 20%-55% reduction in end-user packet call delay and around 50% increase in user
packet call throughput, when simultaneously applying Node B scheduling, hybrid ARQ with soft combining, and a
shortened TTI. Hence, significant technical benefits have been found for a system using these techniques in
conjunction.
Higher order modulation, of which only 8PSK has been studied, has been found to cause a loss in link performance
compared to multi-code transmission with BPSK, but may enable peak data rates exceeding 5.76 Mbit/s or may provide
implementation benefits in terms of a reduced PAR. The other enhancements studied are not dependent on whether
higher order modulation is introduced or not. Thus, from a principal point of view, higher order modulation is
independent of the other enhancements studied.
3GPP
Release 6 125 3GPP TR 25.896 V2.0.0 (2004-03)
Complexity has been studied in terms of buffering and timing requirements due to hybrid ARQ, PAR impact due to
additional physical channels, and power requirements for the associated control signaling. Comments from RAN2 and
RAN3 on their respective areas have also been taken into account in the TR. The enhancements can be introduced into
the FDD specifications without impacting the backwards compatibility with Rel5 and earlier releases.
All these enhancements, Node B controlled scheduling, hybrid ARQ, shorter TTI, and higher order modulation, have
been found to be technically feasible. At least one company has expressed concerns on the benefits of a shorter TTI in
comparison with the potential implementation impacts. Some companies have questioned whether the benefit with
8PSK from a PAR perspective outweighs the loss in link performance.
Fast DCH setup has been partially investigated. Methods for reducing the synchronization time when going from
CELL_FACH to CELL_DCH have been described but not evaluated in detail in this report. Other aspects of fast DCH
setup, e.g., architectural changes and signaling protocols, have not been covered.
12.2 Recommendations
Base on the findings documented in this report, RAN1 recommends to create a work item on uplink enhancements
where:
- Node B controlled scheduling, hybrid ARQ, and shorter TTI are parts of the work item;
- Higher order modulation (8PSK and higher) is not part of the work item;
- Fast DCH setup is not part of the work item.
3GPP
Release 6 126 3GPP TR 25.896 V2.0.0 (2004-03)
Annex A:
Simulation Assumptions and Results
A.1 Link Simulation Assumptions
A.1.1 Interface between link level and system level

The performance characteristics of individual links used in system simulation are generated a priori from link level
simulations. Due to weak uplink pilots, and the resulting poor channel estimates, the link performance predicted by
methods that do not account for imperfect channel estimates can yield incorrect results. So, it is very important to
account for the effect of channel estimation errors on link performance. Suggested techniques for predicting link error
performance in the presence of channel estimation errors are discussed further in the Annex E.
In general, there are two cases of interest:
1. Comparison of techniques/proposals without H-ARQ: If the effect of channel estimation errors on link
performance is modeled in generating simulations results for a comparison of techniques without H-ARQ, the
link error prediction method used should be stated in the simulation assumptions. Otherwise, justification
should be provided as to why the comparison is valid. (See Annex E.)
2. All other cases, i.e., comparison of techniques, one or all of which include H-ARQ combining: In all these
cases, the effect of channel estimation errors on link performance must be accounted for in generating
simulation results for the comparison. (See Annex E)
The following table should be included along with the simulation assumptions accompanying all results:
Are any of the techniques being Is the effect of channel Comments

simulated involve H-ARQ estimation errors on link
combining? performance accounted for?
Yes/No Yes/No If the effect of channel estimation errors on link performance is

modeled, then state the method. Otherwise, justify why the comparison
is valid.
3GPP
Release 6 127 3GPP TR 25.896 V2.0.0 (2004-03)
A.1.2 Link level parameters

Table A - 1 below shows the general link level parameters, to be used both in the reference case, and in the new
schemes proposed for Enhanced Uplink DCH. Table A - 2 shows the link level parameters to be used in the reference
case.
Table A - 1 - General link level parameters

Parameter Explanation/Assumption Comments
Channel coder Turbo 1/3
Number of iterations for turbo 8
decoder
Turbo decoder Max Log MAP
Channel models/ Pedestrian B / 3 km/h, One channel model per simulation
UE speed for channel model Vehicular A / 30 km/h
Pedestrian A / 3 km/h
Optional Vehicular A / 120kph
Table A - 2 - Link level parameters for the Rel99/Rel4/Rel5 reference case

CL power control ON
CL power control error rate 4%
TTI 10 ms
User data rates in TFCS 8, 16, 32, 64, 128, 256, 384 kbit/s These data rates are included in the
TFC selection modelling in the
system level.
A.1.3 Channel models

ITU channel models [2] are used in the link level and system level simulations. Multipath intensity profiles are given
below.
The multipath intensity profile of the Pedestrian-A channel is defined as follows:
Relative Delay 110 190 410

0
(ns)
Relative Power -19.2 -22.8
0.0 -9.7
(dB)
Table A - 3 - ITU Pedestrian-A channel model.

The multipath intensity profile of the Pedestrian-B channel is defined as follows:
Relative Delay 200 800 1200 2300 3700

0
(ns)
Relative Power -0.9 -4.9 -8.0 -7.8 -23.9
0.0
(dB)
Table A - 4 – ITU Pedestrian-B channel model

The multipath intensity profile of the Vehicular-A channel is defined as follows:
3GPP
Release 6 128 3GPP TR 25.896 V2.0.0 (2004-03)
Relative Delay 310 710 1090 1730 2510

0
(ns)
Relative Power 0.0 -1.0 -9.0 -10.0 -15.0 -20.0
(dB)
Table A - 5 – ITU Vehicular-A channel model

The delay intensity profiles are computed from the ITU channel multipath intensity profiles given in the Tables above
for a set of transmit and receive filters. The delay intensity profile for 5MHz WCDMA transmit and receive filters
(raised cosine with beta=0.22) for a chip rate of 3.84Mcps are given in Table A - 6 The Fractional Recovered Power
(FRP) is given in Table A - 6 for each recovered ray. Fraction of un-Recovered Power (FURP) shall contribute to the
interference of the finger demodulator outputs as an independent fader.
Table A - 6 - FRP and Delay profile for each ITU channel model for 5MHz bandwidth and 3.84Mcps.
Multi-path FRP for each ray (dB) Delay for each ray (Tc)
Model 1 2 3 4 5 1 2 3 4 5
Pedestrian A -0.22 0.125
Pedestrian B -3.39 -8.45 -8.63 -11.61 -11.74 0.375 1.375 3.250 4.750 9.000
Vehicular A -3.17 -4.07 -11.19 -13.01 0.125 1.375 2.875 4.250
Vehicular B -4.83 -2.39 0.125 1.250
A.1.4 Description of Short Term FER and ECM Metod

A.1.4.1 Short-term FER method:
The short-term Eb/Nt vs. BLER results are generated in the following way:
1. The link simulation is run for a long duration (e.g. 500,000 TTI) with outer-loop set to 1% FER.
2. At the end of each TTI, the following statistics are logged:
a. TTI averaged Rx traffic Eb/Nt, combined across both antennas
i. Denoted as short-term Eb/Nt
b. Binary metric denoting whether the frame is in error or not, after decoding
3. At the end of simulation run:
a. The short-term Eb/Nt is placed in bins with a uniform grid, along with the associated binary decoding
metric
b. For each bin, the FER is computed based upon the binary metrics from all values in the bin
c. This constitutes a short-term Eb/Nt vs. FER curve
These curves form a set of look-up tables for the system level simulation. In the system level simulation, the receiver
computes the TTI averaged traffic Eb/Nt and looks up the corresponding short-term FER curve. A uniform random
variable is then selected based on the FER in the system simulator to determine if the represented frame for that TTI is
erased or not.
3GPP
Release 6 129 3GPP TR 25.896 V2.0.0 (2004-03)
A.1.4.2 ECM method:

The steps in the ECM method are summarized as follows:
1. Compute the equivalent (Es/Nt)m per m-th slot.
2. Compute σ 2 = 8 ⋅ Q ⋅ 10 ( E s N t ) / 10
for BPSK, σ 2 = 4 ⋅ Q ⋅ 10 ( E s N t ) / 10
for QPSK and
( Es N t ) / 10
σ = 2.6666 ⋅ Q ⋅ 10
2
for 8-PSK modulation. Q is a scale factor obtained from running link level
simulation.
3. Compute function J(σ) using the following approximation.
 a1σ 3 + b1σ 2 + c1σ , if σ ≤ 1.6363

J (σ ) ≈ 
1 - exp(a 2σ + b2σ + c 2σ + d 2 ) if 1.6363 ≤ σ ≤ ∞
3 2
where a1 = −0.0421061, b1 = 0.209252 and c1 = −0.00640081 for the first approximation, and where
a 2 = 0.00181491, b2 = −0.142675, c 2 = −0.0822054 and d 2 = 0.0549608 for the second approximation.
4. The average Cm is then calculated by averaging over the TTI as per the following
k M
C= ⋅ ∑ J (σ )m where k = 1,2 and 3 for BPSK, QPSK and 8-PSK modulation respectively
M m =1
5. The equivalent Eb/Nt is then given by
2
E b  −1  C  k
=  J   ⋅
N t   k  8Q
where
 a C 2 + b3C + c3 C , if 0 ≤ C ≤ 0.3646
J −1 (C ) ≈  3
a 4 ln(b4 (C - 1)) + c 4 C if 0.3646 ≤ C ≤ 1
where a 3 = 1.09542, b3 = 0.214217 and c1 = 2.33727 for the first approximation, and where
a 4 = −0.706692, b4 = −0.386013 and c 4 = 1.75017 for the second approximation.
The FER is then obtained by applying the Eb/Nt to an AWGN reference curve.
3GPP
Release 6 130 3GPP TR 25.896 V2.0.0 (2004-03)
A.1.4.3 Comparison between short term and ECM method

The short term and ECM FER curves was generated as per the parameters shown in TableA1.4.1
Table A.1.4.1. Simulation Parameters
Simulation Parameter Value
No. of slots/frame 15
No. of chips/second 3.84 Mcps
TTI 2 and 10 ms
Modulation BPSK
Channels Ped-A, Ped-B and Veh-A
No. of antennas 2
No. of fingers 1-Ped-A and 5-Ped-B, 4-Veh-A
Lock filter Yes
Receiver Rake
Sampling Rate 1X
Inner-Loop PC ON
Outer-Loop PC OFF
Power Control Metric Ideal
PC delay and error 1 slot, 4%
PC step size 1 dB
Pilot/TFCI/FBI/TPC 6/2/0/2
Base Turbo Code R=1/3, K=4, 8 iterations
Figure A.1.4.1 to figure A.1.4.4 shows the performance comparison of short-term approach to
that of the ECM approach for flat, Ped-B and Veh-A channel model at 3, 30 and 120 kmph for
2msec and 10 msec TTI respectively.
0
10
-1
10
AWGN
PA3 - ST
-2
10 PA3 - ECM
PB3 - ST
PB3 - ECM
VA30 - ST
VA30 - ECM
VA120 - ST
VA120 - ECM
-3
10
-1 0 1 2 3 4 5
Figure A.1.4.1. Comparison of actual short-term and ECM generated curves – 192 kbps, R=0.4, BPSK,
TTI=2ms, SF=8, ideal channel estimation, Q=1.0 for PA3, PB3, Q=2.0 for VA30, VA120.
3GPP
Release 6 131 3GPP TR 25.896 V2.0.0 (2004-03)
0
10
-1
10
AWGN
PA3 - ST
-2
10 PA3 - ECM
PB3 - ST
PB3 - ECM
VA30 - ST
VA30 - ECM
VA120 - ST
VA120 - ECM
-3
10
-1 0 1 2 3 4 5
0
10
-1
10
AWGN
PA3 - ST
-2
10 PA3 - ECM
PB3 - ST
PB3 - ECM
VA30 - ST
VA30 - ECM
VA120 - ST
VA120 - ECM
-3
10
-1 -0.5 0 0.5 1 1.5 2 2.5 3
3GPP
Release 6 132 3GPP TR 25.896 V2.0.0 (2004-03)
0
10
-1
10
AWGN
PA3 - ST
-2
10 PA3 - ECM
PB3 - ST
PB3 - ECM
VA30 - ST
VA30 - ECM
VA120 - ST
VA120 - ECM
-3
10
-1 -0.5 0 0.5 1 1.5 2 2.5 3 3.5 4
A.2 Link Simulation Results
A.2.1 HARQ Performance Evaluation

A.2.1.1 HARQ Efficiency and Number of Retransmissions
In this section, the following notation is used:
Ec ,avg Ec ,1 1
= ⋅ N avg ⋅ = Average Ec/Nt
Nt Nt Ttrans
Eb,comb Ec ,avg W
= ⋅ = Average Eb/Nt
Nt Nt Rt arg et
Ec ,1 Ec ,dpcch Ec ,e −dpdch
= ⋅ (1 + ) = Single transmission Ec/Nt including DPCCH overhead
Nt Nt Ec ,dpcch
N avg = Average number of transmissions needed for successful transmission ≤ Ttrans
Ttrans = Target (maximum) number of transmissions = 1 or 2 or 4
Rt arg et = Target data rate
W = Chip rate = 3.84 Mcps
The simulation assumptions are shown in Table A.2.1.1.1.
3GPP
Release 6 133 3GPP TR 25.896 V2.0.0 (2004-03)
Parameter Value
DPCCH Slot format 0

Channel estmation Realistic
Inner Loop PC Enabled
Outer Loop PC Based on Residual BLER
PC BER 4%
Channel AWGN
Number of Rx antennas 2
HARQ Xrv {0}, {0,3}, {0,3,5,7} for 1/2/4 transmissions
Table A.2.1.1.1 Simulation Assumptions
Figures A.2.1.1.1 to A.2.1.1.4 show the simulation results.
Figure A.2.1.1.1 Eb/Nt vs. E-DPDCH/DPCCH – Target Data Rate = 640 kbps
3GPP
Release 6 134 3GPP TR 25.896 V2.0.0 (2004-03)
Figure A.2.1.1.2 Eb/Nt vs. E-DPDCH/DPCCH – Target Data Rate = 1024 kbps
Figure A.2.1.1.3 Throughput vs. E-DPDCH/DPCCH – Target Data Rate = 640 kbps
3GPP
Release 6 135 3GPP TR 25.896 V2.0.0 (2004-03)
Figure A.2.1.1.4 Throughput vs. E-DPDCH/DPCCH – Target Data Rate = 1024 kbps
The optimal operating points for all cases are shown in Table A.2.1.1.2.
Target Optimal BLER

Optimal Average
Data EDPDCH/ Optimal
MCS DPCCH number of
Rate DPCCH Eb/Nt (dB)
SNR (dB) 1 Tx 2 Tx 3 Tx 4 Tx transmissions
(kbps) (dB)
640 4 10 -14.2 4.0 0.01 - - - 1.00

640 9 15 -19.1 2.8 0.60 0.01 - - 1.60
640 19 15 -19.5 2.1 0.99 0.76 0.18 0.01 2.93
1024 7 10 -12.4 3.8 0.01 - - - 1.00
1024 15 13 -15.6 3.0 0.84 0.01 - - 1.84
1024 31 15 -17.6 2.1 0.99 0.84 0.22 0.01 3.07
Table A.2.1.1.2 Optimal Operating Point – 1, 2, 4 transmissions
A.2.2 Link Performance of E-DCH for System Simulations

A.2.2.1 Short-term Link Performance with 2 ms TTI
In this section, the short-term link performance is evaluated for a reference MCS based on 2ms TTI. Without any loss of
generality, only 1 TrCH is assumed for E-DCH. Therefore, each TFC translates to a TF. The MCS is shown in Table
A.2.2.1.1.
3GPP
Release 6 136 3GPP TR 25.896 V2.0.0 (2004-03)
Table A.2.2.1.1 MCS
Number of
Transport
Block Size
Code Modulation OVSF Code
Code
Rate
βc β eu Rate after
4 Tx (kbps)
Blocks
(1
128 1 QPSK C(4,1) 0.33 15 12 16
(1
256 1 QPSK C(4,1) 0.33 15 17 32
(1
512 1 QPSK C(4,1) 0.33 15 21 64
(1
768 1 QPSK C(4,1) 0.33 15 27 96
1024 1 QPSK C(4,1) 0.33 15 38 128
2048 1 QPSK C(4,1) 0.53 15 47 256
3072 1 QPSK C(2,1) 0.40 15 53 384
4096 1 QPSK C(2,1) 0.53 15 67 512
5120 2 QPSK C(2,1) , C(4,1) 0.44 15 61 , 43 640
6144 2 QPSK C(2,1) , C(4,1) 0.53 15 69 , 49 768
7168 2 QPSK C(2,1) , C(4,1) 0.62 15 77 , 54 896
8192 2 QPSK C(2,1) , C(4,1) 0.71 15 86 , 61 1024
1)
Repetition has been used to achieve the given data rates
Similar to HS-DPCCH, the E-DPDCH/DPCCH power ratio for each TF are indirectly signalled using beta factors.
These power offsets were chosen for optimal link performance with a 1% residual BLER target after 4 transmissions
across channel models PA3, PB3, VA30 and VA120.
The rest of the simulation assumptions are shown in Table A.2.2.1.2. For the HARQ operation it is assumed that the 1st
and 3rd transmissions are self-decodable, while the 2nd and 4th transmissions are not self-decodable.
Table A.2.2.1.2
Parameter Value
TTI 2 ms
RV sequence {0,1,2,5}
Number of HARQ processes 5
IR Inter-TTI 5
DPCCH Slot Format 0
Power Control On
Inner Loop PC Step Size +/- 1 dB
Outer Loop PC Step Size + 0.5 dB
PC BER 4%
Rx antennas 2
Number of fingers 1-PA, 5-PB, 4-VA
Channel estimation Implementation I
Implementation II
Residual BLER 1%
1. The link simulation is run for a long duration (500,000 TTI)
a. TTI averaged Rx Eb/Nt
b. Transmission number (1st vs. 2nd vs. 3rd vs. 4th)
i. The inter-TTI duration is maintained at 10ms.
c. Accumulated short-term Rx Eb/Nt
3GPP
Release 6 137 3GPP TR 25.896 V2.0.0 (2004-03)
i. Summation of TTI averaged Rx Eb/Nt from previous transmissions and current transmission,
if the transmission number is greater than 1
ii. This indicates the Eb/Nt associated with soft combining
d. Binary metric denoting whether the block is in error or not, after soft-combining and decoding
a. Four different sets of logs are created, each corresponding to either 1, 2, 3 or 4 transmissions
i. The logged statistics are separated based upon the transmission number
b. For each log, the accumulated short-term Eb/Nt is placed in bins with a uniform grid, along with the
associated binary decoding metric
i. For each bin, the BLER is computed based upon the binary metrics from all values in the bin
4. The four short-term BLER results denote:
a. BLER after 1st transmission
b. BLER after 2nd transmission, conditioned on 1st transmission in error
c. BLER after 3rd transmission, conditioned on 1st and 2nd transmissions in error
d. BLER after 4th transmission, conditioned on 1st, 2nd and 3rd transmissions in error
In this sense, each BLER curve is conditioned on erroneous previous transmission/s. Note that the TTI averaged Rx
Eb/Nt (mentioned in step 2a) is defined as:
Eb E c, pilot E c ,e− dch # chips per TTI

Rx = Rx + +
Nt Nt E c , pilot # information bits per payload (including overhead)
Since there are 8 MCS, 4 channel models and 4 possible transmissions resulting in numerous combinations, only a
subset of the link simulation results are shown. Figures A.2.2.1.1 to A.2.2.1.12 show a subset of short-term results after
{1, 2, 3, 4} transmissions.
3GPP
Release 6 138 3GPP TR 25.896 V2.0.0 (2004-03)
Figure A.2.2.1.1: 16 kbps – VA30
3GPP
Release 6 139 3GPP TR 25.896 V2.0.0 (2004-03)
3GPP
Release 6 140 3GPP TR 25.896 V2.0.0 (2004-03)
Figure A.2.2.1.5: 128 kbps – VA30
Figure A.2.2.1.6: 256 kbps – VA30
3GPP
Release 6 141 3GPP TR 25.896 V2.0.0 (2004-03)
Figure A.2.2.1.7: 384 kbps – VA30
Figure A.2.2.1.8: 512 kbps – VA30
3GPP
Release 6 142 3GPP TR 25.896 V2.0.0 (2004-03)
Figure A.2.2.1.9: 640 kbps – VA30
Figure A.2.2.1.10: 768 kbps – VA30
3GPP
Release 6 143 3GPP TR 25.896 V2.0.0 (2004-03)
Figure A.2.2.1.11: 896 kbps – VA30
Figure A.2.2.1.12: 1024 kbps – VA30
3GPP
Release 6 144 3GPP TR 25.896 V2.0.0 (2004-03)
A.2.2.2 Short-term Link Performance with 10 ms TTI

In this section, the short-term link performance is evaluated for a reference MCS based on 10ms TTI. Without any loss
of generality, only 1 TrCH is assumed for E-DCH. Therefore, each TFC translates to a TF. The MCS is shown in Table
A.2.2.2.1.
Table A.2.2.2.1
Transport
Block Size
Number of
Code Blocks
Modulation
OVSF
Code
Code
Rate
βc β eu Rate after 2
Tx (kbps)
(1
320 1 QPSK C(4,1) 0.33 15 11 16
(1
640 1 QPSK C(4,1) 0.33 15 15 32
(1
1280 1 QPSK C(4,1) 0.33 15 21 64
(1
1920 1 QPSK C(4,1) 0.33 15 27 96
(1
2560 1 QPSK C(4,1) 0.33 15 30 128
5120 2 QPSK C(4,1) 0.33 15 42 256
7680 2 QPSK C(4,1) 0.40 15 53 384
10240 3 QPSK C(4,1) 0.53 15 60 512
12800 3 QPSK C(2,1) 0.33 15 67 640
15360 4 QPSK C(2,1) 0.40 15 75 768
17920 4 QPSK C(2,1) 0.47 15 84 896
20480 5 QPSK C(2,1) 0.53 15 95 1024
1)
Repetition has been used to achieve the given data rates
Similar to HS-DPCCH, the E-DPDCH/DPCCH power ratio for each TF are indirectly signalled using beta factors.
These power offsets were chosen for optimal link performance with a 1% residual BLER target after 2 transmissions
across channel models PA3, PB3, VA30 and VA120.
The rest of the simulation assumptions are shown in Table A.2.2.2.2. For the HARQ operation it is assumed that the 1st
transmission is self-decodable, while the 2nd transmission is not self-decodable.
Table A.2.2.2.2
Parameter Value
TTI 10 ms
RV sequence {0,1}
Number of HARQ processes 3
IR Inter-TTI 3
DPCCH Slot Format 0
Power Control On
Inner Loop PC Step Size +/- 1 dB
Outer Loop PC Step Size + 0.5 dB
PC BER 4%
Rx antennas 2
Number of fingers 1-PA, 5-PB, 4-VA
Channel estimation Implementation I
Residual BLER 1%
5. The link simulation is run for a long duration (500,000 TTI)
3GPP
Release 6 145 3GPP TR 25.896 V2.0.0 (2004-03)
a. TTI averaged Rx Eb/Nt
b. Transmission number (1st vs. 2nd)
i. The inter-TTI duration is maintained at 20ms.
c. Accumulated short-term Rx Eb/Nt
i. Summation of TTI averaged Rx Eb/Nt from previous transmissions and current transmission,
if the transmission number is greater than 1
ii. This indicates the Eb/Nt associated with soft combining
d. Binary metric denoting whether the block is in error or not, after soft-combining and decoding
a. Four different sets of logs are created, each corresponding to either 1 or 2 transmissions
i. The logged statistics are separated based upon the transmission number
b. For each log, the accumulated short-term Eb/Nt is placed in bins with a uniform grid, along with the
associated binary decoding metric
i. For each bin, the BLER is computed based upon the binary metrics from all values in the bin
8. The four short-term BLER results denote:
a. BLER after 1st transmission
b. BLER after 2nd transmission, conditioned on 1st transmission in error
In this sense, each BLER curve is conditioned on erroneous previous transmission/s. Note that the TTI averaged Rx
Eb/Nt (mentioned in step 2a) is defined as:
Eb E c, pilot E c ,e− dch # chips per TTI

Rx = Rx + +
Nt Nt E c , pilot # information bits per payload (including overhead)
Since there are 8 MCS, 4 channel models and 2 possible transmissions resulting in numerous combinations, only a
subset of the link simulation results are shown. Figures A.2.2.2.1 to A.2.2.2.7 show a subset of short-term results after
{1, 2} transmissions.
3GPP
Release 6 146 3GPP TR 25.896 V2.0.0 (2004-03)
3GPP
Release 6 147 3GPP TR 25.896 V2.0.0 (2004-03)
Figure A.2.2.2.4: 128 kbps – VA30
3GPP
Release 6 148 3GPP TR 25.896 V2.0.0 (2004-03)
Figure A.2.2.2.5: 256 kbps – VA30
Figure A.2.2.2.6: 512 kbps – VA30
3GPP
Release 6 149 3GPP TR 25.896 V2.0.0 (2004-03)
Figure A.2.2.2.7: 1024 kbps – VA30
A.2.3 Link Performance with Different Pilot Overhead

A.2.3.1 Assumptions
To investigate the impact on overall performance due to different pilot power, simulations have been run on different
fading channel models and with different βc/βd ratios. The simulation assumptions are found in A.2.3.1.1.
Parameter Value
Data rates 336 kbit/s (single E-DPDCH), 1.008 Mbit/s (3 E-DPDCHs).

SF 4, 2 ms TTI, and code rate 0.35 for both cases.
Slot format Slot format 0 (6 pilot, 2 TFCI, 2 TPC bits per slot)
βc/βd ratio Varied.
Eb/N0 definition Eb is the total received energy (including both DPDCH and DPCCH) per
antenna during a TTI divided by the number of information bits in the
TTI.
Channel Models PedA at 3 km/h; VehA at 3, 30, 120 km/h. 2 GHz carrier frequency.
Channel Estimation Ideal or non-ideal. Non-ideal channel estimate based on average over
multiple slots (2-8 slots for the Doppler range studied herein)
Power control Non-ideal SIR estimation. Error-free TPC feedback in DL. 1 slot power
control delay.
Number of RAKE fingers Equal to the number of channel taps.
Antenna diversity 2 antenna Rx diversity
Table A2.3.1.1: Simulations assumptions.
3GPP
Release 6 150 3GPP TR 25.896 V2.0.0 (2004-03)
A.2.3.2 Results
The performance for different βc/βd settings with Pedestrian A at 3 km/h with ideal and non-ideal channel estimation is
found in Figure A.2.3.2.1. As seen in the plot, the performance for the lowest DPCCH powers, βc/βd=1/15 and to some
extent βc/βd =2/15, are significantly degraded compared to the higher βc/βd settings. For βc/βd =3/15 and higher ratios,
there is no large spread in performance. The reason for the performance degradation when the βc/βd is reduced is mainly
due to dissatisfactory SIR estimation for the power control mechanism and to a lesser extent due to degradation in
channel estimation.
Similar conclusions, i.e., SIR estimation error is the largest cause of loss at low DPCCH power settings, can be drawn
for the Vehicular A channel model at 3 km/h, although the benefit for the channel estimator with a higher DPCCH
power setting is somewhat larger than for PedA due to the larger number of paths in the VehA channel model.
Results for Vehicular A at 30 km/h are found in Figure A2.3.2.3. On average, a higher Eb/N0 is required compared to the
3 km/h case due to a reduced possibility for the power control mechanism to track fast fading. Furthermore, the amount
of averaging in the channel estimator is reduced. Hence, the benefits from a higher DPCCH power for the channel
estimation is slightly larger than for the 3 km/h case.
In Figure A.2.3.2.4, results for Vehicular A at 120 km/h are plotted. From the plot, it is seen that the power control
cannot track the fast fading, making the influence of SIR estimation errors insignificant. Furthermore, as only two slots
of averaging is used in the channel estimator, the spread in performance for different βc/βd ratios is increased compared
to lower Doppler frequencies, thus increasing the benefits with a stronger DPCCH from a channel estimation point of
view.
In Table A.2.3.2.1 and Table A.2.3.2.2, the results are summarized for data rates of 336 kbit/s and 1.008 Mbit/s,
assuming non-ideal channel and SIR estimation. It is seen that a higher pilot energy is beneficial for the overall
performance at both low and high Doppler frequencies. At low Doppler frequencies, the main reason is improved SIR
estimation, while at the highest Doppler frequency, the improved quality of the channel estimate dominates.
Table A.2.3.2.1: Difference in performance for some different βc/β d settings compared to βc/β d = 5/15, which was
found to be (close to) the best ratio for 336 kbit/s data rate assuming continuous transmission. Non-ideal channel
and SIR estimation.
βc/βd = 2/15 βc/βd = 3/15 βc/βd = 4/15
10% BLER 1 % BLER 10% BLER 1% BLER 10% BLER 1% BLER
Pedestrian A, 1 dB 1.4 dB 0.4 dB 1.1 dB 0.1 dB 0.3 dB
3 km/h
Vehicular A, 1.3 dB 1.8 dB 0.5 dB 0.8 dB 0.1 dB 0.3 dB
3 km/h
30 km/h
120 km/h
Table A.2.3.2.2: Difference in performance for some different βc/β d settings compared to βc/β d = 6/15, which was
found to be (close to) the best ratio for 1.008 Mbit/s data rate. Non-ideal channel and SIR estimation.
βc/βd = 3/15 βc/βd = 4/15 βc/βd = 5/15
10% BLER 1 % BLER 10% BLER 1% BLER 10% BLER 1% BLER
Pedestrian A, 0.6 dB 0.9 dB 0.25 dB 0.4 Db 0.05 dB 0.2 dB
3 km/h
30 km/h
Vehicular A, 2 dB 2 dB 1.1 dB 1.4 dB 0.5 dB 0.7 dB
120 km/h
3GPP
Release 6 151 3GPP TR 25.896 V2.0.0 (2004-03)
Figure A.2.3.2.1. Results for 336 kbit/s, Pedestrian A at 3 km/h for different βc/β d ratios. Ideal (dashed lines) and
non-ideal (solid lines) channel estimation, non-ideal SIR estimation. Plotted with a dotted line is the performance
without power control for reference.
Figure A.2.3.2.2: Results for 336 kbit/s, Vehicular A at 3 km/h for different βc/β d ratios. Ideal (dashed lines) and
non-ideal (solid lines) channel estimation, non-ideal SIR estimation.
3GPP
Release 6 152 3GPP TR 25.896 V2.0.0 (2004-03)
Figure A2.3.2.3: Results for 336 kbit/s, Vehicular A at 30 km/h for different βc/β d ratios. Ideal (dashed lines) and
non-ideal (solid lines) channel estimation, non-ideal SIR estimation.
Figure A2.3.2.4: Results for 336 kbit/s, Vehicular A at 120 km/h for different βc/β d ratios. Ideal (dashed lines)
and non-ideal (solid lines) channel estimation, non-ideal SIR estimation.
3GPP
Release 6 153 3GPP TR 25.896 V2.0.0 (2004-03)
A.2.4 Link Performance of Release-99 for System Simulations

The short-term 1% FER values (DPDCH Eb/Nt, where Eb includes CRC overhead as a part of the traffic information
bits) for Release-99 uplink with ideal and non-ideal channel estimation is shown in the following Table. The simulation
results were obtained without DCCH. In case of ideal channel estimation, ideal SIR metric and ideal finger allocation
were assumed. In case of non-ideal channel estimation, non-ideal SIR metric and ideal finger allocation were assumed.
It may be noted that these ranges are representative values and may change, dependent on variety of assumptions like
type of channel estimator used (e.g. number of slots estimation is performed over, data or non-data assisted estimation),
SIR metric for power control, threshold for lock filters, beta values etc.
Table A.2.4.1: Rel-99 short term link performance

8 kbps 64 kbps 128 kbps 384 kbps
Non-ideal Ideal Non-ideal Ideal Non-ideal Ideal Non-ideal Ideal
PA3 2.8-3.3 2.8 1.8-2.0 1.4 1.7-1.9 1.3 1.4-2.0 1.3
PB3 4.0-4.2 3.0 2.7-3.1 1.7 2.6-3.1 1.6 2.4-3.2 1.7
VA30 4.0-4.6 3.0 2.9-3.2 1.7 2.7-3.1 1.6 2.6-3.7 1.7
VA120 4.8-5.2 3.0 3.5-4.1 1.6 3.4-4.1 1.5 3.6-4.0 1.6
A.3 System Simulation Assumptions

As system level simulation tools and platforms differ between companies very detailed specification of common
simulation assumptions is not feasible. Yet, basic simulation assumptions and parameters should be harmonized as
proposed in the subsequent chapters. Various kinds of system performance evaluation methods may be used.
A.3.1 System Level Simulation Modelling and Parameters

A.3.1.1 Antenna Pattern
The antenna pattern [2] used for each sector, uplink and forward Link, is plotted in Figure A - 1 and is specified by
  θ 2 
A (θ ) = − min 12   , Am  where − 180 ≤ θ ≤ 180
  θ 3dB  
, θ 3dB is the 3dB beam width, and Am = 20dB is the maximum attenuation.
3GPP
Release 6 154 3GPP TR 25.896 V2.0.0 (2004-03)
-5
-10
Gain - dB
-15
-20
-25
-180 -150 -120 -90 -60 -30 0 30 60 90 120 150 180
Horizontal Angle - Degrees
Figure A - 1 - Antenna Pattern for 3-Sector Cells
A.3.1.2 System Level Parameters

Table A - 7 below shows the general system level parameters, to be used both in the reference case, and in the new
schemes proposed for Enhanced Uplink DCH. Table A - 8 shows the system level parameters to be used in the
reference case.
3GPP
Release 6 155 3GPP TR 25.896 V2.0.0 (2004-03)
Table A - 7 – General System Level Simulation Parameters

Cellular layout Hexagonal grid, 3-sector sites
Site to Site distance 2800 m
1000 m
Antenna pattern 0 degree horizontal azimuth is East Only horizontal pattern specified
70 degree (-3dB), 20dB front-to-back ratio See Section 3.1.1.
Propagation model L = 128.1 + 37.6 Log10(R) (see [6]) R in kilometres
Downlink CPICH power -10 dB Relative to the maximum power
Other downlink common channels -10 dB Relative to the maximum power
Slow fading Similar to UMTS 30.03, B 1.4.1.4
Std. deviation of slow fading 8.0 dB Log-Normal Shadowing
Correlation between sectors 1.0
Correlation between sites 0.5 See Annex B
Correlation distance of slow fading 50 m See D,4 in UMTS 30.03.
Carrier frequency 2000 MHz
Node B antenna gain plus Cable 14 dBi

Loss
Node B RX diversity Uncorrelated 2-antenna RX diversity Maximal ratio combining
UE antenna gain 0 dBi
Maximum UE EIRP 21 dBm Also 24 dBm can be simulated

additionally, however 21 dBm should be
the main case.
BS total Tx power 43 dBm
Active set size Up to 3 Maximum size
Uplink system noise –102.9 dBm
Specify Fast Fading model Jakes spectrum where Doppler based on Generated e.g. by Jakes or by Filter
speed. approach
Soft Handover Parameters Window_add = 4 dB, Window_add: The signal from a BS has to
be at highest this amount smaller than the
Window_drop = 6 dB current active set’s best BS’s signal for a
BS to be added in the active set.
Window_drop: When the signal from a BS

has dropped below the active set’s best
BS’s signal minus this parameter, the BS
will be dropped from the active set.
3GPP
Release 6 156 3GPP TR 25.896 V2.0.0 (2004-03)
Uplink Power Control Closed-loop power control delay: one slot Power control feedback: BER = 4% for a
Node-B - UE pair.
Short term average Rise over x dB 4 The percentage of time the short term
Thermal (Uplink Received Power average rise over thermal is above the x
Normalized by Thermal Noise Level) dB target should not exceed 1%. Short
term average Rise over thermal for the
default two receiving antenna mode is the
result of filtering the instantaneous rise
½[(Io1+No)/No + (Io2 + No)/No] with the
filter described in Annex C, where the total
received signal power at antenna i is
defined as Ioi, I=1,2.
Delays between network elements. Document [7] is resource and starting

point for delay information between
different network elements for release 5.
Table A - 8 - System Level Simulation parameters used in the reference rel99/rel4/rel5 case
Method included in the reference Rel'99 / Rel'4 / Rel'5 System with TFC The parameters defined based on
case selection Rel'99 / Rel'4 / Rel'5 specifications
User data rates in TFCS allocated to TFCS1: 8, 16, 32, 64, 128, 256, 384 kbit/s One of these two TFCS is to be
the UE included in the TFC selection
TFCS2: 8, 16, 32, 64, 128, 256, 384, 768, modelling.
1000 kbit/s
TTI 10 ms Maximum TTI in the TFC
Ptx estimation error in TFC selection The error is within ±2 dB with 90% Error is Log normally distributed
certainty. around zero mean with std = 1.2159
dB.
Delay for moving TFC into blocked 60 ms As defined in current specification,
state in TFC selection assuming max TTI in the TFC being
TTTI =10 ms and no codec which
9.33 ms + Tnotify + Tmodify+ TL1_proc + needs rate adjustment.
Talign_TTI
Delay for moving TFC back into 60 ms As defined in current specification,

supported state in TFC selection assuming max TTI in the TFC being
TTTI =10 ms and no codec which
9.33 ms + Tnotify + Tmodify+ TL1_proc + needs rate adjustment.
Talign_TTI
In the proposed schemes for Enhanced Uplink DCH, following parameters are defined in more detail:
• TFC selection method should be used with the same parameters as in the reference case, if there is no clear reason
why it does not fit to the scheme.
• Used data rates and transport formats
• Parameters and other details of scheduling
4Note that the final value for the rise outage threshold and its exact use will be determined later as simulation and analytical results are generated by
proponent companies. One reason for having a rise outage threshold is to guarantee acceptable voice call quality and reliable signaling given
autonomously or explicitly scheduled data UEs on the Release 99/4/5 or enhanced uplink channel.
3GPP
Release 6 157 3GPP TR 25.896 V2.0.0 (2004-03)
A.3.1.3 Signaling Errors

Signaling errors may be modeled and specified as the examples in Table A - 9.
Table A - 9 - WCDMA Signaling Errors
Signaling Channel Errors Impact
ACK/NACK channel Misinterpretation, misdetection, or false Transmission (frame or encoder packet)

detection of the ACK/NACK message error or duplicate transmission
Scheduling related signaling Misinterpretation of feedback Potential transmission errors

information
For H-ARQ, if an ACK is misinterpreted as a NACK (duplicate transmission), the packet call throughput should be
scaled down by (1-pACK), where pACK is the ACK error probability. Otherwise the signaling errors will be explicitly
modeled to properly account for them.
A.3.1.4 Downlink Modeling in Uplink System Simulation

In addition to modelling CPICH transmission for the purpose of active set selection, only feedback errors for e.g. power
control, acknowledgements, scheduling related signaling etc. need to be modeled. Thus explicit modeling of the
downlink channels is not required.
A.3.2 Uplink measurement accuracy

Measurement errors for taking instantaneous (e.g. 0.667 ms) samples of Received total wideband power (RTWP), (also
called Io), can be modeled as a lognormal process with standard deviation and mean as given below and in keeping with
RTWP requirements given in specification 25.133 [8] (see specifically section 9.2 and Annex A.9 in 25.133).
Absolute interference rise error mean: 0
Absolute interference rise error std. dev.: 4 / 1.28
Relative interference rise error mean: 0
Relative interference rise error std dev.: 0.5 / 1.28
A.3.2.1 Uplink power control

Inner loop power control update rate is assumed to be 1500Hz in keeping with release 5. Inner loop power control is
applied to all uplink channels including the EUDCH, the proponent should indicate otherwise.
Outer loop power control is needed so that the DPCCH can meet minimum required Ec/Nt. Outer loop power control
can be active at all times by using a Rel-99 Zero-block CRC DPDCH which will also keep the DPCCH at the minimum
required received Ec/Nt for demodulation of the EUDCH and other uplink control channels
3GPP
Release 6 158 3GPP TR 25.896 V2.0.0 (2004-03)
A.3.3 System Simulation Outputs and Performance Metrics

A.3.3.1 Output metrics for data services
The following statistics related to data traffics should be generated and included in the evaluation report for each
scheme. If wrap-around is used [9], statistics are collected from all cells, otherwise at least from “center cell(s)”. If
wrap-around is not used statistic collection is taken from “center cell(s)” and at least two tiers of cells around the
“center cell” site. A frame as used below is also referred to as a transport block and consists of information bits, CRC,
and tail bits.
1. Average cell throughput [kbps/cell] is used to study the network throughput performance, and is measured as
b ,
R=
k ⋅T
where b is the total number of correctly received data bits in the uplink from all data UEs in the simulated
system over the whole simulated time, k is the number of cells in the simulation and T is the simulated time. In
the case of only evaluating the center cell site, k is the number of sectors.
2. Average packet call throughput [kbps] for user i is defined as
K
1 good bits in packet call k
R pktcall (i ) =
K
∑
k =1 (tend _ k − tarrival _ k )
where k = denotes the kth packet call from a group of K packet calls where the K packet calls can be for a given
user i , tarrival_k = first packet of packet call k arrives in queue, and tend_k = last packet of packet k is received by
the Node-B. Note for uncompleted packet calls, tend_k is set to simulation end time. The mean, standard
deviation, and distribution of this statistic is to be provided.
3. The packet service session FER is calculated for all the packet service sessions. A packet service session FER
is defined as the ratio
nerroneous _ frames
FERsession = ,
n frames
where nerroneous_frames is the total number of erroneous frames in the packet service session and nframes is the total
number of frames in the packet service session. These individual packet service session FERs from all packet
service sessions (from all UEs) form the distribution for this statistic. The mean, standard deviation, and the
distribution of this statistic is to be provided.
A Definition of a Packet Service Session: A Packet Service Session contains one or several packet calls
depending on the application. Packet service session starts when the transmission of the first packet of the first
packet call of a given service begins and ends when the last packet of the last packet call of that service has
been transmitted. (One packet call contains one or several packets.) Note, that FER statistics are only collected
from those frames during which UE is transmitting data.
4. The residual FER is calculated for each user for each packet service session. A packet service session residual
FER is defined by the ratio
ndropped _ frames
FERresidual = ,
n frames
where ndropped_frames is the total number of dropped frames in the packet service session and nframes is the total
number of frames in the packet service session. A dropped frame is one in which the maximum ARQ or
HARQ re-transmissions have been exhausted without the frame being successfully decoded. In the case of
HARQ the proponent should indicate whether he is including RLC initiated re-transmissions or not. The mean,
3GPP
Release 6 159 3GPP TR 25.896 V2.0.0 (2004-03)
standard deviation, and distribution of this statistic over all the packet service sessions in the simulation is to be
provided.
5. The averaged packet delay per sector is defined as the ratio of the accumulated delay for all packets for all
users received by the sector and the total number of packets. The delay for an individual packet is defined as
the time between when the packet enters the queue at transmitter and the time when the packet is received
successively by the base station. If a packet is not successfully delivered by the end of a run, its ending time is
the end of the run.
6. The histogram of averaged packet delay per user. The averaged packet delay is defined as the ratio of the
accumulated delay for all packets for the user and the total number of packets for the user. The delay for a
packet is defined as in 2.
7. The scattering plot of data throughput per user vs. its averaged packet delay. The data throughput and
averaged packet delay per user are defined as in 3 and 2, respectively.
8. The uplink TxP is the ideal measured UE TxP at the UE antenna connector. This is collected from all the UEs
at desired intervals. A distribution of these over the simulation time is to be provided.
9. The noise rise is defined as the ratio of the total received wideband power and the thermal noise. Noise rise
samples are taken every 0.667ms. Mean, std and the 95th percentile of this and the distribution is to be
provided.
A.3.3.2 Mixed Voice and Data Services

In order to fully evaluate the performance of a proposal with mixed data and voice services, simulations are repeated
with different loads of voice users. The following outputs may be generated and included in the evaluation report.
1. The following cases can be simulated: no voice users (i.e., data only), voice users only (i.e., number of voice
users equal to voice capacity), and 0.25Nmax or 0.5Nmax voice users with data users, where Nmax is the voice
capacity.
2. For each of the above case, all corresponding output metrics defined previously are generated, whenever it is
applicable.
In addition, the following output may also be generated and included in the evaluation report:
1. A curve of sector data throughput vs. the number of voice users is generated, where the sector data throughput
is defined as above.
A.3.3.3 Voice Services and Related Output Metrics

The following statistics related to voice traffics can be generated and included in the evaluation report.
1. Voice capacity. Voice capacity is defined as the maximum number of voice users that the system can
support within a sector with certain maximum outage probability. The details on how to determine the
voice capacity of a sector are described in Annex D.
2. Percentage of blocked voice user
A.3.3.3.1 Voice Model

An example speech (voice) model is specified in Annex D.
A.3.3.4 Packet Scheduler

The voice users’ (if simulated together with the data users) transmissions are not scheduled. The data users can be
scheduled or allowed to transmit in a random fashion. The exact procedure and its delay and reliability with which a UE
gains the right to transmit is to be specified in detail.
3GPP
Release 6 160 3GPP TR 25.896 V2.0.0 (2004-03)
A.4 System Simulation Results
A.4.1 Release-99 Performance

A.4.1.1 Release-99 Performance With Full Buffer
A.4.1.1.1 System Setup

The system performance is obtained under the following assumptions:
• Link-level curves used are generated based on the following parameters, where each pair represents
(TFC,DPDCH/DPCCH): (8 kbps, 0 dB), (16 kbps, 2 dB), (32 kbps, 4 dB), (64 kbps, 7 dB), (128 kbps, 10 dB),
(256 kbps, 13 dB), (384 kbps, 15 dB),
• Maximum data rate is 384 kbps
• 19 Node-B, 3-cell wrap-around layout
• Simulation duration: 200 s
o Additional warm-up time, during which statistic is not collected: 10 s
A.4.1.1.2 Performance Without TFC Control in AWGN

The following figures present the system performance in AWGN, without TFC control, in terms of average RoT and
throughput per user. Figure A.4.1.1.2.2 represents the average RoT as a function of the number of users per cell. It can
be seen that as the number of users increases, the RoT increases.
Figure A.4.1.1.2.3 shows the scatter plot of the user throughputs for 5, 10 and 15 users per cell as a function of the best
downlink path loss. From this figure it can be seen that as the number of users increases, the cell coverage decreases.
RoT vs. number of UEs
25
20
RoT (dB)
15
10
0
0 2 4 6 8 10 12 14 16
num ber of UEs
Figure A.4.1.1.2.2 Average RoT as a function of number of users per cell
3GPP
Release 6 161 3GPP TR 25.896 V2.0.0 (2004-03)
user throughput vs. downlink path loss
500
user throughput (kbps)

400
300
200
100
0
0 50 100 150
downlink path loss (dB)
UE - 5 UE - 10 UE - 15
Figure A.4.1.1.2.3 Average user throughput as a function of the best downlink path loss
A.4.1.1.3 Performance With TFC Control in AWGN

In these simulations, the following assumptions are made regarding the DCCH.
• DCCH is present 20% of the time for each UE
• When present, DCCH is transmitted at 3.4 kbps with 40ms TTI
• The associated TF contains 148 information bits in accordance with 3GPP TS 34.108
• Every 40ms, a decision on the presence or absence of DCCH is made for every UE
Two sets of link level curves are generated for traffic (DTCH), with appropriate rate matching simulating the presence
or absence of DCCH.
The TF for DTCH and the corresponding beta factors are listed in Table A.4.1.1.3.1. These values have been derived
assuming a received DPCCH Ec/Nt = -21 dB, non ideal channel estimation and unlimited number of fingers; note that
outer loop power control is enabled during the simulation (target = 1% BLER) and the actual received DPCCH Ec/Nt
may vary. Corresponding link level results can be found in Tdoc R1-031380.
Table A.4.1.1.3.1 TF and the corresponding beta factors
TF βc βd
8 kbps 15/15 15/15
16 kbps 12/15 15/15
32 kbps 10/15 15/15
64 kbps 7/15 15/15
128 kbps 5/15 15/15
256 kbps 3/15 15/15
384 kbps 3/15 15/15
The following figures present the system performance in AWGN, with TFC control, in terms of average RoT, average
cell throughput and throughput per user. Considered scheduler algorithms are Round Robin, Proportional Fair (PF) and
long-term downlink signal-to-interference-noise ratio (DL SINR) based. Scheduler related assumptions are given in
Tdoc R1-031004.
Figure A.4.1.1.3.1 represents the average RoT as a function of the number of users per cell (5 and 10 users per cell). It
can be seen that as the number of users increases, the RoT remains around the same.
3GPP
Release 6 162 3GPP TR 25.896 V2.0.0 (2004-03)
Figure A.4.1.1.3.2 and Figure A.4.1.1.3.3 demonstrate the average cell throughput as a function of RoT with 5 users and
10 users per cell respectively. For the same average RoT, DL SINR scheduling provides the highest throughput by
prioritizing the users close to the cell center (which typically have higher long-term average SINR and inject less
interference into the network than those at the cell boundary) while PF scheduler and Round Robin scheduler yield the
same performance. As the number of users increases, for the same average RoT, the average cell throughput decreases
as the overhead associated with the DPCCH is increased except for DL SINR. DL SINR can take advantage of
multiuser diversity when the average RoT is high enough and a higher throughput can be observed with 10 users.
Figure A.4.1.1.3.4 shows the scatter plot of the user throughputs for 5 and 10 users per cell as a function of the best
downlink path loss. From this figure it can be seen that as the number of users increases, the user throughput decreases
but the cell coverage stays around the same.
RoT vs Number of UEs per Cell
6
5
RoT (dB)
4
3
2
1
0
0 2 4 6 8 10 12
Number of UEs per Cell
DL SINR Prop. Fair Round Robin
Figure A.4.1.1.3.1 Average RoT as a function of number of users per cell
Different Scheduler - 5 UEs per Cell
2000
Throughput (kbps)
1500
1000
500
0
0 2 4 6 8
RoT (dB)
Figure A.4.1.1.3.2 Average cell throughput as a function of RoT – 5 UEs per cell
3GPP
Release 6 163 3GPP TR 25.896 V2.0.0 (2004-03)
Different Scheduler - 10 UEs per Cell
2000
Throughput (kbps)
1500
1000
500
0
0 2 4 6 8
RoT (dB)
Figure A.4.1.1.3.3 Average cell throughput as a function of RoT -- 10 UEs per cell
User Throughput vs. DL Path Loss
400
User Throughput
300
(kbps)
200
100
0
0 50 100 150
Best DL Path Loss (dB)
PF - 5 UEs PF - 10 UEs
Figure A.4.1.1.3.4 Average user throughput as a function of the best downlink path loss
A.4.1.2 Release-99 Performance With Mixed Traffic Model

The system performances are obtained under the following assumptions:
• Link-level curves used are generated based on the following parameters, where each pair represents
(TFC,DPDCH/DPCCH): (8 kbps, 0 dB), (16 kbps, 2 dB), (32 kbps, 4 dB), (64 kbps, 7 dB), (128 kbps, 10 dB),
(256 kbps, 13 dB), (384 kbps, 15 dB),
• Traffic model: FTP, Near Real Time Video, Gaming
o The TCP parameters, as defined in Table A-13, for FTP users are: Mean(τ2)=50 ms, Mean(τ3)=50
ms, StdDev(τ3)=50 ms, τ4=0 ms if packet is in error after all physical layer retransmissions and
τ4=200 ms otherwise
• Initial FTP state is the reading time, exponentially distributed with mean of 18 s
• The Gaming traffic model parameters are as defined in the Table A-10, for Value Set 2
3GPP
Release 6 164 3GPP TR 25.896 V2.0.0 (2004-03)
• Maximum data rate is 384 kbps
A.4.1.2.2 Performance Without TFC Control in AWGN

The following figures present the system performance in AWGN, without TFC control, in terms of average RoT,
throughput per user, packet call throughput per user and packet call delay.Figure A.4.1.2.2.1 represents the average RoT
as a function of the number of users per cell. As the number of users increases, the RoT increases, for all traffic models.
Figure A.4.1.2.2.2 shows the scatter plot of the throughputs of the users for 10 users per cell as a function of the best
downlink path loss.
Figure A.4.1.2.2.3 presents the packet call throughputs of the users in terms of the best downlink path loss, for 10 users
per cell. Packet call throughput is defined as the ratio of the number of correctly received bits and the packet call delay.
Packet call delay is the time between two consecutive reading periods. For Gaming users, packet call delay represents
the time of a gaming session that includes the time during which the packets are generated (active period), and the time
needed for transmission of the data packets accumulated during the active period. For FTP users, packet call delay is the
time needed for an FTP file upload. Packet call delays are presented in Figure A.4.1.2.2.4. The packet call delay is
shown for FTP and Gaming users only, since the packet call delay for Video users is not specifically defined and is
actually equivalent to the simulation duration.
18
16
14
12
RoT [dB]
10
0
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Number of Users
FTP VIDEO GAMING
Figure A.4.1.2.2.1: Average RoT as a function of number of users per cell
3GPP
Release 6 165 3GPP TR 25.896 V2.0.0 (2004-03)
10 Users per Sector
350
300
250
Throughput [kbps]
200
150
100
50
0
70 80 90 100 110 120 130 140 150
Path Loss [dB]
FTP VIDEO GAMING
Figure A.4.1.2.2.2: Average user throughput as a function of the best link path loss for the system with 10 users
per cell
10 Users per Sector
400
350
Packet Call Throughput [kbps]
300
250
200
150
100
50
0
70 80 90 100 110 120 130 140 150
Path Loss [dB]
FTP VIDEO GAMING
Figure A.4.1.2.2.3: Average packet call throughput as a function of the best link path loss for the system with 10
users per cell
3GPP
Release 6 166 3GPP TR 25.896 V2.0.0 (2004-03)
10 Users per Sector
210
200
190
180
170
160
150
140
130
120
110
100
90
80
70
60
50
40
30
20
10
0
70 80 90 100 110 120 130 140 150
Path Loss [dB]
FTP GAMING
Figure A.4.1.2.2.4: Average packet call delay as a function of the best link path loss for the system with 10 users
per cell
A.4.1.3 Release-99 Voice Capacity

The system performance is obtained under the following assumptions:
• TTI: 20ms
• Voice rate: 12.2kbps
• DPDCH/DPCCH for each TF: (12.2 kbps, 0 dB), (SID, -4 dB), (NULL, -7 dB)
• Channel model mix: PA3 30%, PB3 30%, VA30 20% and VA120 30%
• Rest of simulation assumptions as in Table A-7
3GPP
Release 6 167 3GPP TR 25.896 V2.0.0 (2004-03)
A.4.1.3.2 Voice Capacity

Table A.4.1.3.2.1 presents the average Rot and voice outage probability.
Table A.4.1.3.2.1 Average RoT and Voice Outage Probability

Number of Average Voice Outage
UEs per cell RoT (dB) Probability
2.95
45 0.00%
4.67
60 0.12%
7.54
75 0.47%
16.19
90 8.75%
A.5 Traffic Models

The following types data traffic models will be used in the evaluation study, a) Modified Gaming, b) near real time
video and c) FTP. The traffic models are described in the following paragraph.
a) Modified Gaming Model:
Instances of packet
arrival at base station
reading time A packet call
A session
First packet of the Last packet of the
session session
Figure A - 2 - A source packet data model with packets (datagrams) arriving as part of a packet call.
Figure A - 2 shows the source traffic model. Similar to other models it defines a packet call arrival process and within
each packet call a datagram arrival process. In this model the packet session arrival process is not specified and it is
assumed that packet calls are generated indefinitely (for the duration of the simulation). One may however specify a
limited number of packet calls within a packet session together with an arrival probability.
For the packet call arrival process we specify the packet call (time) duration and the reading time (the time between
packet calls). The reading time starts at the successful transmission of all datagrams generated during the previous
packet call to emulate a closed loop transmission mode; we imagine that the application running on the UE will await
acknowledgement from the network peer. Most significantly, this is a measure to ensure burstiness in the UE
transmissions since it avoids excessive UE buffer accumulation, and hence continuous-like transmission, during the
simulation. For the datagram arrival process we specify the packet size (bits) and the interarrival time between
datagrams.
The model for this is largely derived from the so-called "Gaming" measurements [1], and therefore originally using the
empirically derived distributions specified therein. However, partly as a consequence of the closed loop modeling in
Figure A - 3 and for emulating future services with higher bit rates the distributions were modified slightly. For the
3GPP
Release 6 168 3GPP TR 25.896 V2.0.0 (2004-03)
packet call distributions, both the packet call duration and reading time have exponential distributions. The datagram
size is set to a fixed value and the datagram inter-arrival distribution is a lognormal distribution. An example of the
distribution is shown in Figure A - 4.
Start of reading time
End of Packet Call

Packet Call Duration: Start of new Packet Call
packets are generated as input to
the RLC buffer
Transmission of data
packets accumulated during
the active period. No new
packets are generated.
Figure A - 3 - A simple modeling approach to include closed loop transmission mode - the 'reading time' only
starts after the UE RLC buffer has been emptied.
25
20
15
px
10
0
0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5
x - interarrival time
Figure A - 4 - Packet interarrival time distribution for 40 ms mean interarrival time. The packet interarrival
distribution is log-normal
3GPP
Release 6 169 3GPP TR 25.896 V2.0.0 (2004-03)
The model is very general and can be adjusted easily in terms of required data rates and burstiness by changing the
datagram size and the mean data gram interarrival time, equivalently the mean reading time. Table A - 10 shows the
parameter settings to be used in the simulations.
Table A - 10 - Parmeter Settings for the Modified Gaming model

Parameter Value Comment
Value set 1 Value Set 2
Mean packet call duration 5s 5s Exponential distribution
Mean reading time 5s 5s Exponential distribution
Datagram size 576 bytes 1500 bytes Fixed
Mean datagram interarrival time 40 ms 40 ms Log-normal distribution,

40 ms standard deviation
Resulting mean data rate during 115 kbps 300 kbps

packet call
The burstiness results mainly from the datagram interarrival time and the packet call reading time, while the bit rate
results from the interarrival time and size of the datagrams.
b) Near Real Time Video Model:

The following section describes a model for streaming video traffic on the forward link. Figure A - 5 describes the
steady state of video streaming traffic from the network as seen by the base station. Latency of starting up the call is
not considered in this steady state model.
A video streaming session is defined as the entire video streaming call time, which is equal to the simulation time for
this model. Each frame of video data arrives at a regular interval T determined by the number of frames per second
(fps). Each frame is decomposed into a fixed number of slices, each transmitted as a single packet. The size of these
packets/slices is distributed as a truncated Pareto. Encoding delay, Dc, at the video encoder introduces delay intervals
between the packets of a frame. These intervals are modeled by a truncated Pareto distribution.
The parameter TB is the length (in seconds) of the de-jitter buffer window in the Node-B used to guarantee a continuous
display of video streaming data. This parameter is not relevant for generating the traffic distribution but is useful for
identifying periods when the real-time constraint of this service is not met. At the beginning of the simulation, it is
assumed that the Node-B’s de-jitter buffer is full with (TB x source video data rate) bits of data. Over the simulation
time, data is “leaked” out of this buffer at the source video data rate and “filled” as reverse link traffic reaches the Node-
B. As a performance criterion, the Node-B can record the length of time, if any, during which the de-jitter buffer runs
dry. The de-jitter buffer window for the video streaming service is 5 seconds.
3GPP
Release 6 170 3GPP TR 25.896 V2.0.0 (2004-03)
Video Streaming Session (= simulation time)
time
0 T 2T (K-1)T KT
TB (Buffering Window)
DC (Packet Packet Size

Coding Delay)
Figure A - 5 - Video Streaming Traffic Model

Using a source video rate of 64 kbps, the video traffic model parameters are defined in Table A - 11.
Table A - 11 - Typical Video Streaming Traffic Model Parameters
Information Inter-arrival Number of Packet (slice) Inter-arrival time

types time between packets (slices) size between packets
the beginning in a frame (slices) in a frame
of each frame
Distribution Deterministic Deterministic Truncated Truncated Pareto

Pareto
(Based on (Mean= 100bytes, (Mean= 6ms,
Max= 250bytes)
Max= 12.5ms)
10fps)
100ms 8 K = 40bytes K = 2.5ms
Distribution
Parameters α = 1.2 α = 1.2
e) FTP Model:
In FTP applications, a session consists of a sequence of file transfers, separated by reading times. The two main
parameters of an FTP session are:
1. S : the size of a file to be transferred
2. Dpc: reading time, i.e., the time interval between end of download of the previous file and the user request for
the next file.
The underlying transport protocol for FTP is TCP. The model of TCP connection will be used to model the FTP traffic.
The packet trace of an FTP session is shown in Figure A - 6. The FTP traffic model parameters are shown in Table A -
12.
3GPP
Release 6 171 3GPP TR 25.896 V2.0.0 (2004-03)
Packet calls
Dpc
Packets of file 1 Packets of file 2 Packets of file 3
Figure A - 6 - Packet Trace in a Typical FTP Session
Table A - 12 - Typical FTP Traffic Model Parameters

C om ponent D is tr ib u tio n P a r a m ete rs PDF
F ile s iz e (S ) T ru n c a te d M ean = 2 M B
− (x / µ)
2
lo g n o rm a l S td . D e v .= fx =
1
exp  ln , x ≥ 0
2πσx σ
2
 2 
0 .7 2 2 M B
σ = 0 . 35 , µ = 14 . 45
M ax. = 5 M B
R e a d in g E x p o n e n tia l M ean = 180 sec. − λx
f = λ e ,x ≥ 0
tim e (D pc ) x
λ = 0 . 006
Based on the results on packet size distribution [10], 76% of the files are transferred using and MTU of 1500 bytes and
24% of the files are transferred using an MTU of 576 bytes. For each file transfer a new TCP connection is used whose
initial congestion window size is 1 segment (i.e. MTU).
The three-way handshake mechanism for TCP connection set-up and release is shown in Figure A-7.
After the call setup process is completed, the procedure for a UE to set up a TCP session is as follows:
1. UE sends a 47-byte5 SYNC packet and wait for an ACK from remote server.
2. UE starts TCP in slow-start mode (The ACK flag is set in the first TCP segment).
The procedure for a UE to release the TCP session is as follows:
1. UE sets the FIN flag in the last TCP segment.
2. UE receives ACKs for all TCP segments from the remote server and terminates the session.
5 The TCP/IP header of 40 bytes + 7 bytes PPP framing overhead = 47 bytes for the SYNC packet.
3GPP
Release 6 172 3GPP TR 25.896 V2.0.0 (2004-03)
Figure A-7: Modeling of TCP three-way handshake
The amount of outstanding data that can be sent without receiving an acknowledgement (ACK) is determined by the
minimum of the congestion window size of the transmitter and the receiver window size. After the connection
establishment is completed, the transfer of data starts in slow-start mode with an initial congestion window size of 2
segments. The congestion window increases by one segment for each ACK packet received by the sender. This results
in an exponential growth of the congestion window.
3GPP
Release 6 173 3GPP TR 25.896 V2.0.0 (2004-03)
Figure A-8: TCP Flow Control During Slow-Start; τl = Transmission Time over the Uplink; τrt = Roundtrip
Time
3GPP
Release 6 174 3GPP TR 25.896 V2.0.0 (2004-03)
The round-trip time in Figure A-8, τrt, consists of two components:
τrt = τcr + τl ,where
• τcr = τ2 + τ3 + τ4
o τ2 = Nominal time taken by a TCP data segment to travel from Node-B to the server plus the time
taken by an ACK packet to travel from the server back to Node-B
o τ3 = Time taken by the ACK to travel from Node-B to client.
o τ4 = Constant delay to account for RLC retransmissions (nominally zero)
• τl = Transmission time taken by TCP data segment from the client to Node-B
The individual delay distribution parameters are given in Table A-13.
Table A-13 Delay components in the TCP model for the RL upload traffic


segment to travel from Node-B to the server
and the time taken by an ACK packet to travel Mean = x ms.
from the server to Node-B
Time taken by the ACK to travel from Node- τ3 Lognormal distribution

B to client
Mean = y1 ms
Standard deviation = y2 ms

retransmissions from residual uplink physical
layer BLER = 0 ms, if packet is not in error after all
physical layer retransmissions
= z ms, else
From Figure A-8, during the slow-start process, the UE receives two segments back-to-back after an interval of τcr for
every ACK packet received.
The upload procedure is illustrated in Figure A-9 and described as follows.
1. Let S = size of the FTP upload file in bytes. Compute the number of packets in the file, N = S/(MTU-40). W =
size of the congestion window of TCP. Initially, W = 2
2. If N>W, then W packets are put into the queue for transmission; otherwise, all packets of the file are put into the
queue for transmission in FIFO order. Let P = the number of packets remaining to be transmitted beside the W
packets in the window. If P=0, go to step 6
3. Wait until a packet of the file in the queue is transmitted over uplink
4. Schedule arrival of next two packets (or the last packet if P=1) of the file after the packet is successfully ACKed. If
P=1, then P=0, else P=P-2
5. If P>0 go to step 3
6. End.
3GPP
Release 6 175 3GPP TR 25.896 V2.0.0 (2004-03)
Figure A-9 Packet Arrival Process for the Upload of a File Using TCP
Annex B:
Lognormal description
The attenuation between a mobile and the ith cell site is modeled by
Xi
−µ
Li = k o Di 10 10
Ri2
where Di is the distance between the mobile and the cell site, µ is the path loss exponent and X i represents the
shadow fading which is modeled as a Gaussian distributed random variable with zero mean and standard deviation σ .
X i may be expressed as the weighted sum of a component Z common to all cell sites and a component Z i which is
independent from one cell site to the next. Both components are assumed to be Gaussian distributed random variables
with zero mean and standard deviation σ independent from each other, so that
3GPP
Release 6 176 3GPP TR 25.896 V2.0.0 (2004-03)
X i = aZ + bZ i such that a 2 + b 2 = 1
Typical parameters are σ = 8.9 and a = b = 1 for 50% correlation. The correlation is 0.5 between sectors
2 2
2
from different cells, and 1.0 between sectors of the same cell.
Annex C:
Uplink Rise Outage Filter
To determine average interference rise outage a short term average rise filter is defined.
A simple 3-tap rectangular filter is used to compute the ratio of total uplink received power to thermal noise over a radio
frame interval (2 ms). The filter is applied to each set of three Rssi/thermal noise samples computed every 0.67 ms.
Z(k) = ( Rssi[j]+Rssi[j+1]+Rssi[j+2] )/3, j=3k
where
Rssi = ½[(Io1+No)/No + (Io2 + No)/No]
No – thermal noise
Ion – uplink CDMA interference for antenna n, n=1 primary, n=2 diversity antenna.
Annex D:
Speech Source (Markov) Model
The simplified speech source model with an average voice activity of 0.32 is given by
IF PrevState=0 then
IF RAND()<0.01 then
NewState=1 /* go to voice active state */
Else
NewState=0 /* remain in voice inactive state */

Else
IF RAND()<0.9785 then
NewState=1 /* remain in voice active state */
Else
NewState=0 /* go to voice inactive state */
3GPP
Release 6 177 3GPP TR 25.896 V2.0.0 (2004-03)
S p eech Ac tivity T im e S eries
0 .8
0 .6
Activity
0 .4
0 .2
0
0 20 0 4 00 60 0 8 00 10 00
20m s Fram e Inte rva ls
Figure D – 1 - Speech Source Example using simple Markov Model

Voice user’s should meet an outage criteria which can be defined as:
a. average FER being less than 2%,
b. short term FER exceeding 2% no more than 10% of the time.
The short term FER of the voice service is calculated by averaging over 2 seconds. An AMR vocoder with a rate of 12.2
kbps will be used. The uplink voice activity factor should be set to 0.32 by randomly choosing on and off periods of
appropriate duration. A simple speech source model is given above.
Annex E:
Modeling of the effect of channel estimation errors on Link
performance
As mentioned in Section A.1.1, the effect of channel estimation errors on link performance should be modeled for an
accurate comparison of different techniques. Two methods for modeling this effect are provided in [13]. The methods
described are applicable to the Quasi-static approach discussed further below. We provide below a brief overview of
techniques used in [11]:
• Demodulation with imperfect channel estimates affects the SNR of the demodulated symbols. The SNR of the
demodulated symbol – as seen by the turbo decoder – can be characterized analytically. This SNR is a function
of the packet parameters such as transport block size and data rate, transmit data and pilot energies, channel
gain, interference power, quality of channel estimates and combining method. Note that all of the parameters
would already be generated in a system level simulation and nothing additional needs to be generated for this
approach. An effective Eb/No for the block is then readily computed (analytically). The probability of error for
the transmission is then obtained by using appropriate lookup curves (after adjusting the analytically calculated
effective Eb/No by applying the Doppler penalty, puncturing penalty, and other terms, as appropriate). See
[11] for more details.
In cases that do not involve the use of H-ARQ combining, in addition to the methods in [11], the following method may
be used:
• FER Vs traffic Eb/No curves are generated for each TFC, over each fading channel model, via link level
simulations. A family of curves is produced for each data rate with each curve being parameterized by the
average pilot SNR over the frame. For a single packet transmission in the system simulation, the average pilot
3GPP
Release 6 178 3GPP TR 25.896 V2.0.0 (2004-03)
SNR during the frame, and the received traffic channel Eb/No are computed. Performance is read off from the
corresponding error curve (one which is parameterized by the same pilot SNR) obtained in the link level
simulations, at the received traffic channel Eb/No value observed in the system simulation. If an error curve for
this average pilot SNR does not exist for this TFC, the FER curve for this average pilot SNR is interpolated
from the curves for pilot SNR immediately above and below this value, and read at the same received traffic
Eb/No.
If the effect of channel estimation errors is not modeled, then several techniques, such as the ones in [3], [5] or [6], may
be used:
1. Quasi-static approach [5] (QSA) with appropriate Doppler, Demapping, Puncturing penalties.
2. The modelling of link level performance at the system level is done with Eb/N0 to BLER mapping, called the
“Actual Value Interface” (AVI), described in [3].
If a comparison of schemes is based on such models – that do not incorporate the effect of channel estimation errors –
then justification should be provided for not accounting for this effect.
Annex F:
Change history
Change history
Date TSG # TSG Doc. CR Rev Subject/Comment Old New
10-2002 RAN1 R1-02-1218 Initial TR skeleton presented for discussion 0.0.1
#28bis
10-2002 RAN1 #29 R1-02-1259 Modifications to the document structure 0.0.1 0.0.2
12-2002 RAN1 #30 R1-02-1271 + Requirements to chapter 5 Requirements 0.0.2 0.0.3
comments
12-2002 RAN1 #30 R1-030065 Traffic models to Annex A 0.0.2 0.0.3
12-2002 RAN1 #30 R1-030066 Simulations assumptions to Annex A, B, C and D 0.0.2 0.0.3
01-2003 RAN1 #30 R1-030061 Reference Techniques – Uplink TFCS management by RRC 0.0.3 0.0.4
signaling to chapter 6.2 and modification to Table A - 8
01-2003 RAN1 #30 R1-030062 Reference Techniques – TFC selection in UE to chapter 6.3 0.0.3 0.0.4
01-2003 RAN1 #30 R1-030126 Revised Simulations assumptions, changes to Annex A and C 0.0.3 0.0.4
01-2003 RAN1 #30 R1-030005 Added sentence to Editor's Note in chapter 8 about the physical 0.0.3 0.0.4
channel timing requirements.
01-2003 RAN1 #30 R1-030131 TR25.896 version 0.0.4 agreed and promoted to 0.1.0 0.0.4 0.1.0
01-2003 RAN1 #30 R1-030150 Correction to Table A - 8 due to wrong implementation of a text 0.1.0 0.1.1
proposal in Tdoc R1-030126.
02-2003 RAN1 #31 R1-030311 Revision marks approved. 0.1.1 0.2.0
02-2003 RAN1 #31 R1-030209 E-DCH definitions + additional comment 0.2.0 0.2.1
02-2003 RAN1 #31 R1-030210 Fast DCH Setup 0.2.0 0.2.1
02-2003 RAN1 #31 R1-030325 E-DCH Scheduling, 1st chapter of the text proposal added 0.2.0 0.2.1
02-2003 RAN1 #31 R1-030326 Signalling Method for Fast TFCS Restriction Control 0.2.0 0.2.1
02-2003 RAN1 #31 R1-030330 Hybrid ARQ Overview 0.2.0 0.2.1
02-2003 RAN1 #31 R1-030331 Enhanced uplink DCH physical layer structure – TTI vs HARQ 0.2.0 0.2.1
structure
02-2003 RAN1 #31 R1-030332 Multiplexing Alternatives for Uplink Enhancements + additional 0.2.0 0.2.1
sentence
02-2003 RAN1 #31 R1-030341 Description of Node B controlled scheduling by fast TFCS 0.2.0 0.2.1
restriction control
02-2003 RAN1 #31 R1-030349 A method for Node B controlled scheduling by fast TFCS 0.2.0 0.2.1
restriction control
02-2003 RAN1 #31 R1-030332 Correction to the incorrect inclusion of the text proposal 0.2.1 0.2.2
03-2003 R1-030381 Changes approved after an email review 0.2.2 0.3.0
05-2003 RAN1 #32 R1-030563 Text proposal for E-DCH scheduling in SHO 0.3.0 0.3.1
05-2003 RAN1 #32 R1-030592 Node B Controlled Time and Rate Scheduling 0.3.0 0.3.1
05-2003 RAN1 #32 R1-030594 Modifications to Section 7.1 0.3.0 0.3.1
05-2003 RAN1 #32 R1-030598 On HARQ Timing, additional row to table 8.2.1 0.3.0 0.3.1
05-2003 RAN1 #32 R1-030620 Text for TCP Modeling to Annex A.5 0.3.0 0.3.1
05-2003 RAN1 #32 R1-030621 Fast DCH Setup – Synchronization 0.3.0 0.3.1
06-2003 Editorial corrections (8.2.1 and figures A-7 and A-8) 0.3.1 0.3.2
08-2003 RAN1 #33 Addition of modified gaming model's std in table A-10 0.3.2 0.3.3
08-2003 RAN1 #33 R1-030889 Changes approved 0.3.3 0.4.0
08-2003 RAN1 #33 R1-030897 HARQ performance results with and without soft combining 0.4.0 0.4.1
08-2003 RAN1 #33 R1-030899 Changes to HARQ operation during Soft Handover 0.4.0 0.4.1
3GPP
Release 6 179 3GPP TR 25.896 V2.0.0 (2004-03)
Change history
08-2003 RAN1 #33 R1-030911 Two new issues to be studied (Impacts of TTI to TFC selection 0.4.0 0.4.1
and multiple CCTrCH to higher layers) added to chapter 8.3
08-2003 RAN1 #33 R1-030915 Shorter framesize for improved QoS overview to Chapter 7.4 0.4.0 0.4.1
09-2003 RAN1 #33 R1-030911 Added the text proposal that dropped out from the last version.. 0.4.1 0.4.2
09-2003 R1-030890 R'99 voice capacity results to Annex A.4.1.3, modification of 0.4.1 0.4.2
Markov model's voice outage criteria to Annex D
09-2003 R1-030891 R'99 cell throughput results with no TFC control, AWGN, full 0.4.1 0.4.2
buffer added to Annex A.4.1.1
09-2003 R1-030892 R'99 cell throughput results with no TFC control, AWGN, traffic 0.4.1 0.4.2
models added to Annex A.4.1.2
09-2003 R1-030896 HARQ efficiency results 0.4.1 0.4.2
09-2003 Changes approved and sent for RAN#21 for information 0.4.2 1.0.0
10-2003 RAN1 #34 Updated the 2nd page copyright notification 1.0.0 1.0.1
10-2003 RAN1 #34 R1-030989 HARQ performance results in soft handover 1.0.0 1.0.1
10-2003 RAN1 #34 R1-031035 Correction of DL synchronisation delay to 7.3.2 1.0.0 1.0.1
10-2003 RAN1 #34 R1-031045 Node B Controlled Rate Scheduling by Persistence Control 1.0.0 1.0.1
10-2003 RAN1 #34 R1-031097 Chapter structure 9.5 PAR Analysis 1.0.0 1.0.1
10-2003 Corrected broken references and 4 values in Table A – 6 1.0.0 1.0.1
10-2003 R1-031120 + Scheduling overview and scheduling strategies 1.0.1 1.0.2
comments
10-2003 R1-031122 Node B controlled scheduling with scheduling weight 1.0.1 1.0.2
10-2003 R1-031151 Physical layer structures in code domain 1.0.1 1.0.2
10-2003 R1-031130 + Physical layer structures in time domain 1.0.1 1.0.2
comments
10-2003 R1-031131 E-DCH Transport Channel Structure 1.0.1 1.0.2
11-2003 RAN1 #35 R1-031358 Changes of 1.0.1 and 1.0.2 approved by RAN1 #35. 1.0.2 1.1.0
11-2003 RAN1 #35 R1-031173 + Downlink signalling overview 1.1.0 1.1.1
comment
11-2003 RAN1 #35 R1-031223 Physical layer structure and backward compatibility in SHO 1.1.0 1.1.1
11-2003 RAN1 #35 R1-031233 Short-term Link Performance 1.1.0 1.1.1
11-2003 RAN1 #35 R1-031239 Physical layer structure in code domain 1.1.0 1.1.1
first part
11-2003 RAN1 #35 R1-031381 Full Buffer E-DCH Cell Throughput Gain 1.1.0 1.1.1
11-2003 RAN1 #35 R1-031382 E-DCH Cell Throughput Gain with Mixed Traffic Model 1.1.0 1.1.1
12-2003 Corrected Annex C noise rise outage filer 1.1.1 1.1.2
12-2003 RAN1 #35 R1-031256 E-TFC Signalling results to chapter 9.2.4.1 1.1.1 1.1.2
12-2003 R1-031361 Relationship between scheduling and HARQ to chapter 7.1 1.1.1 1.1.2
12-2003 R1-031372 Support for enhanced channel estimation to chapter 7.6 1.1.1 1.1.2
12-2003 R1-031430 PAR results for various multiplexing alternatives to 9.5.1.1 1.1.1 1.1.2
12-2003 R1-031432 Comparison of R'99 and E-DCH schedulers in chapter 9.1.1.1 1.1.1 1.1.2
12-2003 R1-031433 Rel-99 Cell Throughput with TFC Control, Full Buffer and AWGN 1.1.1 1.1.2
to Annex A.4.1.1.3
12-2003 R1-031434 Uplink signalling overview to chapter 7.5.2 1.1.1 1.1.2
12-2003 R1-031435 PAR results for case 8 to chapter 9.5.1.1 1.1.1 1.1.2
12-2003 R1-031439 Uplink signalling of scheduling information to chapter 7.1.2.5.1.1 1.1.1 1.1.2
01-2004 R'6 Ad-hoc R1-040105 Changes of 1.1.1 and 1.1.2 approved by RAN1 R'6 Adhoc 1.1.2 1.2.0
01-2004 R'6 Ad-hoc R1-040002 HARQ Complexity on 9.2.2.1 1.2.0 1.2.1
01-2004 R'6 Ad-hoc R1-040010 Comparison between Short Term and ECM Approach to A.1.4.3 1.2.0 1.2.1
01-2004 R'6 Ad-hoc R1-040022 Node B scheduling of HARQ retransmission, Change to 7.1 1.2.0 1.2.1
01-2004 R'6 Ad-hoc R1-040079 Enhanced Uplink Scheduling by Availability of the Knowledge of 1.2.0 1.2.1
Buffer Status of each UE to other UEs, changes 7.1.2.2&7.1.2.3
01-2004 R'6 Ad-hoc R1-040086 Compatibility of the enhancements with existing releases, 9.7 1.2.0 1.2.1
01-2004 R'6 Ad-hoc R1-040095 Link performance with different pilot overhead to A.2.3 1.2.0 1.2.1
02-2004 RAN1 #36 R1-040346 Changes of 1.2.1 approved by RAN1 #36 1.2.1 1.3.0
02-2004 RAN1 #36 R1-040264 Short term LL performance of 2 ms TTI changed to A2.2.1 1.3.0 1.3.1
02-2004 RAN1 #36 R1-040265 Short term LL performance of 10 ms TTI added to A.2.2.2 1.3.0 1.3.1
02-2004 RAN1 #36 R1-040266 E-DCH Link Performance – BPSK vs. 8PSK added to 9.1.5 1.3.0 1.3.1
02-2004 RAN1 #36 R1-040267 System Performance with Full Buffer - E-DCH vs. Rel-99 1.3.0 1.3.1
changed in chapter 9.6.1.1
02-2004 RAN1 #36 R1-040268 System Performance with Traffic Models - E-DCH vs. Rel-99 1.3.0 1.3.1
changed in chapter 9.6.1.2
02-2004 RAN1 #36 R1-040269 Results on shorter frame size to 9.4.1 1.3.0 1.3.1
02-2004 RAN1 #36 R1-040172 On E-DCH scheduling, additional paragraph to 7.1.5.2 1.3.0 1.3.1
02-2004 RAN1 #36 R1-040350 R'99 short term FER table to A.2.4 1.3.0 1.3.1
02-2004 RAN1 #36 R1-040370 E-DCH System performance (rate control) to chapter 9.6.2 1.3.0 1.3.1
02-2004 RAN1 #36 R1-040337 Text correction to PAR section (9.5.1.1) 1.3.0 1.3.1
02-2004 RAN1 #36 R1-040271 Complexity aspects to chapter 9.5.1.2 1.3.0 1.3.1
02-2004 RAN1 #36 R1-040217 PAR Results to 9.5.1.1 1.3.0 1.3.1
02-2004 RAN1 #36 R1-040371 On shorter TTI complexity to chapter 9.4.2 1.3.0 1.3.1
3GPP
Release 6 180 3GPP TR 25.896 V2.0.0 (2004-03)
Change history
02-2004 RAN1 #36 R1-040254 PAR maintaining backwards compatibility (tables 9.5.1.1.xc) 1.3.0 1.3.1
02-2004 RAN1 #36 R1-040347 E-DCH Timing considerations to chapter 8.5 1.3.0 1.3.1
02-2004 RAN1 #36 R1-040363 RAN2 input to chapters 10 (Joint RAN1/RAN2 session) 1.3.0 1.3.1
02-2004 RAN1 #36 R2-040409 DRAC description to chapter 6.4 (Joint RAN1/RAN2 session) 1.3.0 1.3.1
02-2004 RAN3 #41 R3-040257 RAN3 input to chapter 11, merged with RAN2 input in 363 1.3.0 1.3.1
02-2004 RAN1 #36 R1-040372 Conclusions and recommendations to chapter 12 1.3.0 1.3.1
02-2004 RAN1 #36 R1-040345 PAR result for backward compatibility cases (table 9.5.1.1.3b) 1.3.1 1.3.2
02-2004 Editorial correction to figure A-4, axis were wrongly scaled 1.3.1 1.3.2
3GPP

RP 040046

Uploaded by

Copyright:

Available Formats

RP 040046

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RP 040046

Uploaded by

Copyright:

Available Formats

Presentation of Specification to TSG RAN

Presentation to: TSG RAN Meeting # 23

Changes since last presentation to TSG RAN:

3rd Generation Partnership Project;

3GPP support office address

No part may be reproduced except as authorized by written permission.

7.4 Shorter Frame Size for Improved QoS.................................................................................................................. 31

9.2.1.3 HARQ Efficiency ............................................................................................................................................ 65

9.7.1.2 Transparent functionality............................................................................................................................... 120

Annex A: Simulation Assumptions and Results........................................................................................ 126

A.4.1.1 Release-99 Performance With Full Buffer .................................................................................................... 160

x the first digit:

1 presented to TSG for information;

2 presented to TSG for approval;

3 or greater indicates TSG approved document under change control.

• For a specific reference, subsequent revisions do not apply.

[3] Hämäläinen S., P. Slanina, M. Hartman, A. Lappeteläinen, H. Holma, O. Salonaho, ”A Novel

[6] 3GPP TR 25.942 V3.3.0 (2002-06), RF System Scenarios, June 2002.

[12] 3GPP2, 1xEV-DV Evaluation Methodology.

[14] TS 25.214, v5.3.0, “Physical layer procedures (FDD)”, December 2002

3 Definitions, symbols and abbreviations

- Adaptive modulation and coding schemes

- Hybrid ARQ protocols

- Node B controlled scheduling

- Physical layer or higher layer signalling mechanisms to support the enhancements

- Fast DCH setup

- Shorter frame size and improved QoS

6 Reference Techniques in Earlier 3GPP Releases

6.1 DCH Setup Mechanisms

Figure 6.1.1: Connection states.

6.1.1 Uplink/Downlink Synchronization

6.2 Uplink TFCS Management with RRC Signalling

6.3 Transport Format Combination Selection in the UE

Table 6.3.1: X, Y, Z parameters for TFC selection

Elimination criterion is met Blocking criterion is met

Recovery criterion is met

Recovery criterion is met

Figure 6.3.1: State transitions for the state of a given TFC

Table 6.3.2: UE transmitted power absolute accuracy

UE transmitted power=PUEMAX dBm +1/-3 ±2

UE transmitted power=PUEMAX-1 dBm +1.5/-3.5 ±2.5

UE transmitted power=PUEMAX-2 dBm +2/-4 ±3

UE transmitted power=PUEMAX-3 dBm +2.5/-4.5 ±3.5

PUEMAX-10≤UE transmitted power<PUEMAX-3 dBm +3/-5 ±4

(Tnotify + Tmodify+ TL1_proc)

Tmodify equals MAX(Tadapt_max,TTTI)

TL1 proc equals 15 ms

Tadapt_max equals MAX(Tadapt_1, Tadapt_2, ..., Tadapt_N)

N equals the number of logical channels that need to change rate

Table 6.3.3: Tadapt

1. belong to the TFCS.

2. not be in the Blocked state.

3. be compatible with the RLC configuration.

4. not require RLC to produce padding PDUs

6.3.2 TFC selection method as a reference case for Enhanced Uplink

6.4 RNC controlled scheduling: DRAC and TFCS Restriction

7 Overview of Techniques considered to support

7.1 Scheduling <NodeB controlled scheduling, AMC>

TFC Minimum Set