Tmo18247d0sgdeni2 0

9300 WCDMA
TMO18247 9300 WCDMA UA07

HSxPA Radio Principles
TMO18247 Issue D0 SG DEN I2.0
STUDENT GUIDE
All Rights Reserved © Alcatel-Lucent 2010
All rights reserved © Alcatel-Lucent 2010

Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent

TMO18247 9300 WCDMA UA07 HSxPA Radio Principles - Page 1
Terms of Use and Legal Notices
1. Safetyto
Switch Warning
notes view!
Both lethal and dangerous voltages may be present within the products used herein. The user is strongly advised not to
wear conductive jewelry while working on the products. Always observe all safety precautions and do not work on the
equipment alone.
The equipment used during this course may be electrostatic sensitive. Please observe correct anti-static precautions.
2. Trade Marks
Alcatel-Lucent and MainStreet are trademarks of Alcatel-Lucent.
All other trademarks, service marks and logos (“Marks”) are the property of their respective holders, including Alcatel-
Lucent. Users are not permitted to use these Marks without the prior consent of Alcatel-Lucent or such third party owning
the Mark. The absence of a Mark identifier is not a representation that a particular product or service name is not a Mark.
Alcatel-Lucent assumes no responsibility for the accuracy of the information presented herein, which may be subject to
change without notice.
3. Copyright
This document contains information that is proprietary to Alcatel-Lucent and may be used for training purposes only. No
other use or transmission of all or any part of this document is permitted without Alcatel-Lucent’s written permission, and
must include all copyright and other proprietary notices. No other use or transmission of all or any part of its contents may
be used, copied, disclosed or conveyed to any party in any manner whatsoever without prior written permission from
Alcatel-Lucent.
Use or transmission of all or any part of this document in violation of any applicable legislation is hereby expressly
prohibited.
User obtains no rights in the information or in any product, process, technology or trademark which it includes or
describes, and is expressly prohibited from modifying the information or creating derivative works without the express
2written consent of Alcatel-Lucent. All Rights Reserved © Alcatel-Lucent 2010
9300 WCDMA
TMO18247 9300 WCDMA UA07 HSxPA Radio Principles
All rights reserved © Alcatel-Lucent 2010
4. Disclaimer
In no event will Alcatel-Lucent be liable for any direct, indirect, special, incidental or consequential damages, including
lost profits, lost business or lost data, resulting from the use of or reliance upon the information, whether or not Alcatel-
Lucent has been advised of the possibility of such damages.
Mention of non-Alcatel-Lucent products or services is for information purposes only and constitutes neither an
endorsement, nor a recommendation.
This course is intended to train the student about the overall look, feel, and use of Alcatel-Lucent products. The
information contained herein is representational only. In the interest of file size, simplicity, and compatibility and, in some
cases, due to contractual limitations, certain compromises have been made and therefore some features are not entirely
accurate.
Please refer to technical practices supplied by Alcatel-Lucent for current information concerning Alcatel-Lucent equipment
and its operation, or contact your nearest Alcatel-Lucent representative for more information.
The Alcatel-Lucent products described or used herein are presented for demonstration and training purposes only. Alcatel-
Lucent disclaims any warranties in connection with the products as used and described in the courses or the related
documentation, whether express, implied, or statutory. Alcatel-Lucent specifically disclaims all implied warranties,
including warranties of merchantability, non-infringement and fitness for a particular purpose, or arising from a course of
dealing, usage or trade practice.
Alcatel-Lucent is not responsible for any failures caused by: server errors, misdirected or redirected transmissions, failed
internet connections, interruptions, any computer virus or any other technical defect, whether human or technical in
nature
5. Governing Law
The products, documentation and information contained herein, as well as these Terms of Use and Legal Notices are
governed by the laws of France, excluding its conflict of law rules. If any provision of these Terms of Use and Legal
Notices, or the application thereof to any person or circumstances, is held invalid for any reason, unenforceable including,
but not limited to, the warranty disclaimers and liability limitations, then such provision shall be deemed superseded by a
valid, enforceable provision that matches, as closely as possible, the original provision, and the other provisions of these
Terms of Use and Legal Notices shall remain in full force and effect.

Blank Page
Switch to notes view!
3 All Rights Reserved © Alcatel-Lucent 2010

9300 WCDMA
This page is left blank intentionally

Course Outline
Section
About This1.Course
HSDPA Introduction
4. Topic/Section is Positioned Here
Module 1. TMO18247
Course outline
Technical supportKey Introduction
Section 2. HSDPA 5. Topic/Section is Positioned Here
Course objectives
Module 1. TMO18247
Section 3. HSDPA
1. Topic/Section is Key Channel Here
Positioned 6. Topic/Section is Positioned Here
Xxx Module 1. TMO18247
Xxx
Section 4. HSDPA Key HARQ 7. Topic/Section is Positioned Here
Xxx
Module 1. TMO18247
Section 5. HSDPA Key Fast Scheduling
Module 1. TMO18247
Section 6. HSDPA Key AMC
Module 1. TMO18247
Section 7. HSDPA Protocol
Module 1. TMO18247
Section 8. HSDPA Scenario
Module 1. TMO18247
Section 9. HSDPA AL Implementation
Module 1. TMO18247
4 Section 10. HSUPA Fund
9300 WCDMA

Module 1. TMO18247
Section 11. HSUPA Channel
Module 1. TMO18247
Section 12. HSUPA Scheduling
Module 1. TMO18247
Section 13. Module4 HSUPA HARQ
Module 1. TMO18247
Section 14. Module5 HSUPA UTRAN Protocols
Module 1. TMO18247
Section 15. Module6 HSUPA Scenario
Module 1. TMO18247
Section 16. Module7 HSUPA AL Implementation
Module 1. TMO18247

Course Outline
About This Course 4. Topic/Section is Positioned Here

Course outline
Technical support
Course objectives
1. Topic/Section is Positioned Here 6. Topic/Section is Positioned Here

Xxx
Xxx 7. Topic/Section is Positioned Here
Xxx

9300 WCDMA

Course Outline [cont.]

9300 WCDMA

Course Objectives
Welcome to TMO18247 9300 WCDMA UA07 HSxPA Radio Principles
Upon completion of this course, you should be able to:
describe the evolution of 3G system with HSDPA / HSUPA describe UTRAN

functions and state protocols related to HSUPA/HSDPA

9300 WCDMA

Course Objectives [cont.]

9300 WCDMA

About this Student Guide

Conventions
Switch used
to notes in this guide
view!
Note
Provides you with additional information about the topic being discussed.
Although this information is not required knowledge, you might find it useful
or interesting.
Technical Reference
(1) 24.348.98 – Points you to the exact section of Alcatel-Lucent Technical
Practices where you can find more information on the topic being discussed.
Warning
Alerts you to instances where non-compliance could result in equipment
damage or personal injury.
Where you can get further information

9300 WCDMA
If you want further information you can refer to the following:

Technical Practices for the specific product
Technical support page on the Alcatel website: http://www.alcatel-lucent.com

About this Student Guide [cont.]

9300 WCDMA

Self-assessment of Objectives
Contract number :
At the end of each section you will be asked to fill this questionnaire
Course title :
Please, return this sheet to the trainer at the end of the training
Client (Company, Center) :
Language :
Switch to notes view! Dates from : to :
Number of trainees : Location :
Surname, First name :
Did you meet the following objectives ?

Tick the corresponding box
Please, return this sheet to the trainer at the end of the training
Yes (or No (or

Instructional objectives globally globally Comments
yes) no)
1 To be able to XXX
2
9300 WCDMA

Self-assessment of Objectives [cont.]
Yes (or No (or

Instructional objectives Globally globally Comments
yes) no)

9300 WCDMA
Other comments
Thank you for your answers to this questionnaire


Do not delete this graphic elements in here:
1
Section 1
HSDPA Introduction
9300 WCDMA
TMO18247 Edition D0 SG DEN I2.0

Section 1 Pager 1
Blank Page

HSDPA Introduction
9300 WCDMA TMO18247 9300 WCDMA UA07 HSxPA Radio Principles
Document History
Edition Date Author Remarks
01 YYYY-MM-DD Last name, first name First edition
02 2010-05-12 Nolan, Vincent Update to UA07

Section 1 Pager 2
Objectives
This section will enable you to

Describe HSDPA introduction technological context
List HSDPA main concepts and benefits
List HSDPA target applications and services
Compare HSDPA approach with existing technologies
Describe HSDPA future evolutions

HSDPA Introduction

Section 1 Pager 3
Objectives [cont.]

HSDPA Introduction

Section 1 Pager 4
Table of Contents
Page
What is HSDPA?
HSDPA
1What Key Points
is HSDPA? 7
Radio Resource
1.1 HSDPA Key PointsAllocation 8
1.2 What HSDPA
User Throughput has been designed for?
Management 9
1.3 A new shared channel: HS-DSCH 10
HSDPA
2HSDPA Main Main
Solution Concepts
Facts & Benefits 11
2.1 Theoretical Peak User Data Rates 12
2.2 HSDPA
HSDPA Market Applications
Solution Main Facts 13
2.3 Typical Data Rates 14
Theoretical
2.4 Peak User Data Rates
Factors of HSDPA Performances 15
HSDPA
2.5 HSDPAMarket
Solution Applications
Key Values 16
HSDPA
3HSDPA Solutionand
deployment Keyevolution
Values 17
3.1 Deployment and evolution of HSDPA 18
3.2 Configurations of Deployment inside UMTS 19
3.3 Evolutions of HSDPA 20

HSDPA Introduction

Section 1 Pager 5
Table of Contents [cont.]

HSDPA Introduction This page is left blank intentionally

Section 1 Pager 6
1 What is HSDPA?

HSDPA Introduction

Section 1 Pager 7
1 What is HSDPA?
1.1 HSDPA Key Points
Radio Access Downlink

Technology Only
High Low
Throughputs Latency
Shared PS
Channels Dedicated

HSDPA Introduction
HSDPA (High Speed Downlink Packet Access) is a UMTS packet air interface (add-on solution on top of
3GPP R4 architecture) that allows higher downlink peak data rates than UMTS.
In addition, HSDPA provides lower latency with reduced Round Trip Delays enabling great interactive
applications like multi-user gaming.
HSDPA introduces a new common high speed downlink channel shared by several users. It also introduces
enablers for the high speed transmission at the physical layer (see next slide).
The various system evolutions triggered by HSDPA implementation are restricted to the access network
and there is no modification to the core network and traffic classes.

Section 1 Pager 8
1 What is HSDPA?
1.2 What HSDPA has been designed for?
HSDPA standardized by 3GPP R5 to:

increase the Downlink data throughput
manage Non-Real Time applications (interactive and background class)
provide instantaneous high data rates in the PS domain
(e.g. Internet browsing, video on demand)
HSDPA could be deployed in both Frequency Division Duplex (FDD) and Time
Division Duplex (TDD) modes (both high and low chip rates)
DL
UL
In the following material we will only refer to HSDPA in FDD mode

HSDPA Introduction
“HSDPA is based on techniques such as Adaptive Modulation and Hybrid ARQ to achieve high data
throughput, high peak rates and reduce delay.
It relies on a new type of transport channel, the HS-DSCH, which is terminated in the Node B.
HS-DSCH is applicable only on PS domain RABs.” [refer to 3GPP TS 25.308]
It can significantly increase user data rates but only for ‘best effort’ services such as Internet access or
file download.
In a first step, HSDPA is not intended as a solution for real-time services that require guaranteed QoS and
also places heavy demands on terminals – initial deployments are expected to be confined to 3G data
cards on laptops.

Section 1 Pager 9
1 What is HSDPA?
1.3 A new shared channel: HS-DSCH
with DCH with HS-DSCH
A shared channel is much more efficient than a dedicated channel to

carry bursty packet traffic
1 10 All Rights Reserved © Alcatel-Lucent 2010

HSDPA Introduction
Why is a shared channel more efficient to carry packet bursty traffic than a dedicated channel?
With a bursty traffic, the demand for high data rate is sporadic. Indeed once the UE will demand for a
high data rate to download a file for example, and between 2 such a demands, it won’t need it
anymore.
So with the use of a dedicated channel, the channel with its resources are “dedicated” to this UE.
Consequently between 2 demands like web browsing, the resources are lost.
On the contrary, a shared channel is able to allocate most of its resources to one UE when it asks for,
and the rest of the time, shares those resources with other UE in order to maximize the use of the
channel.
To summarize: dedicated channels are more adapted to symmetrical and constant traffic because they
are able to ensure a certain level of Quality of Service (QoS), they are NOT efficient at all for PS non-
real time traffic.
HSDPA is then based on the use of a shared channel: the High Speed Downlink Shared Channel (HS-DSCH).
The High Speed Downlink Shared Channel is a downlink transport channel shared by several UE. In the
Evolium solution the HS-DSCH is associated with a Dedicated Channel DCH for the RRC and NAS
signalling.To know more about those channels refer to the section “HSDPA Channel” in the chapter
“key concepts for HSDPA”.
The HS-DSCH is transmitted over the entire cell or over only part of the cell using beam-forming antennas
(i.e. smart antennas). [refer to 3GPP TS 25.211]
Note: No Soft Handover/ No fast Closed Loop Power Control as the link adaptation is now performed by
the adaptation of the Modulation with the Coding Rate.
What are the disadvantages of a shared channel?

Not adapted to real-time application (such as a voice call, video games) as it is should be much more
complex to ensure a certain QoS
Section 1 Pager 10
2 HSDPA Solution Main Facts

HSDPA Introduction

Section 1 Pager 11
2.1 Theoretical Peak User Data Rates
21.6M
14.4M
3.6M
2.4M 3.1M
2M
0.31 M 0.38 M
UE Category 14
UE Category 10
UE Category 6
1xRTT
1xEV-DV
1xEV-DO
W-CDMA
EGPRS
HSDPA
HSDPA
1 12
HSDPA Introduction
HSDPA
HSDPA provides impressive enhancements over W-CDMA R4 for the downlink. It offers peak data rates of
up to 10 Mbps, resulting in a better end-user experience for downlink data applications.
The HSDPA-capable UE are classified in categories depending on their receiving capabilities (processing,
modulation, number of codes,...). A single user can receive up to 15 multi-codes, the maximum
specified peak data rate with HSDPA is 21.6 Mbps (Layer1 throughput) when higher order modulation is
used with no coding (effective code rate of one) and with 15 multi-codes.
Achieving this rate in a real system remains very unlikely as it would require an unloaded system serving
a single user extremely close to the NodeB.
Nevertheless, the ability to offer higher peak rates for an increasingly performance-demanding end user
at a substantially lower cost will create a significant competitive advantage for HSDPA operators.
Supporting rich multimedia applications and content and more compelling devices at lower user costs
will enable early adopters to differentiate themselves with advanced services, resulting in higher
traffic per user and increased subscriber growth

Section 1 Pager 12
2.2 HSDPA Market Applications
Business Market Consumer Market
Virtual Office Multiplayer Gaming

Corporate VPN Video Streaming & TV
Remote Applications / Tools Advertising / News Broadcast
Web Browsing Music & Video Downloads
Massive Downloads Web Surfing
... ...
Working Anywhere! Having Fun!

HSDPA Introduction
HSDPA will change wireless communications by delivering broadband in wireless access. This is the next
big technological advancement needed to increase usage. It will boost usage in business sectors by
providing a virtual office environment anywhere and it will also trigger usage by the consumer market
by leveraging the end-user experience of fixed broadband.
The first trend will be for the business market by extending Wireless LAN applications to everywhere
providing a virtual office to sales force, and all nomadic jobs. Indeed, HSDPA allows for broadband to
be truly ubiquitous for the very first time without the inconvenience of looking for hotspots or wireless
access points.
One of the most dramatic changes the telecom sector has faced in recent years has been the diminishing
time lag between the corporate sector and the consumer market in their uptake for new technology.
As far as the consumer market is concerned, HSDPA will blend the boundary between their fixed
broadband access and their mobile services: HSDPA will provide the seamless access to all applications
already used at home for entertainment like music and video downloads, multiplayer gaming, and TV.
HSDPA has a great opportunity to enter the triple play market by addressing residential access with a
bundle offer for TV, Internet Access, and Voice and Mobile services.

Section 1 Pager 13
2.3 Typical Data Rates
Peak user bit rate with first handsets

1.8 Mbps for Line of Sight (LoS)
(Categories 11&12: QPSK only, 5 codes max.)
Example of user bit rate performance (UA06) with different

mobility scenarios with the best UE categories.
7 Mbps
10.8 Mbps Pedestrian
3 Mbps
at 30km/h
for LoS at 3km/h

HSDPA Introduction

Section 1 Pager 14
2.4 Factors of HSDPA Performances
User Equipment Infrastructure

Capabilities Performances
HSDPA
Throughput
Radio Traffic Load

Conditions in the cell

HSDPA Introduction
The theoretical 21.6 Mbps of cell Throughput shared among users can be achieved only under several
criteria:
The UE must be capable to support highest modulation and coding schemes.
The UE must experience optimum channel conditions (e.g. very high SINR)
The load of the cell should allow the Node-B to provide all resources to HSDPA users.
The radio Resource Management or the type of scheduling algorithm of the infrastructures can also
impact the performances for a sake of fairness or of priority among users.

Section 1 Pager 15
2.5 HSDPA Solution Key Values
Software Upgrade Only
PA
HSD DY
REA
45W/60W MCPA
Ready for HSDPA Applications
• Strong partnership with leading device manufacturers

• Major contribution to 3GPP HSDPA working group

HSDPA Introduction
A key attribute of Alcatel-Lucent W-CDMA infrastructure is its flexibility for future upgrades. New
features, some of which were in the earliest stages of standardization at the time of the system
specification, have been taken into account in the Radio Access Network architecture and system
design. This proactive approach enables Alcatel-Lucent to implement HSDPA with simple upgrades to
its current RAN platforms.
Being able to integrate HSDPA and R4 traffic into the same carrier is essential. With the Alcatel-Lucent
solution this is achieved without changing the base station RF elements. Alcatel-Lucent high power
MCPA is already sized for indoor and outdoor HSDPA high demanding power applications. Consequently
HSDPA can boost user and system performance using the initial 5 MHz frequency layer. This does not
prevent from choosing to allocate HSDPA services on a dedicated carrier, this option being also
completely supported by the current Alcatel-Lucent base station RF elements.
The Alcatel-Lucent HSDPA Solution is also fully backwards compatible with 3GPP R4, allowing HSDPA to
be introduced into networks gradually. Both R4 and HSDPA capable terminals can share the same radio
carriers.

Section 1 Pager 16
3 HSDPA deployment and evolution

HSDPA Introduction

Section 1 Pager 17
3.1 Deployment and evolution of HSDPA
HSDPA should cover Dense Urban and Indoor environments
Global
Satellite
Suburban Urban
Indoor
MSS
EDGE UTRA/FDD HSDPA

HSDPA Introduction
HSDPA is particularly efficient in “Line of Sight” environment such as Micro-cells. In those

environments, HSDPA have more possibilities to use high combination with 16-QAM/64-QAM which
results in very high throughput.
Outdoor
* source: Users
DoCoMo 30%
Engineering Indoor
Users 70%
Studies show that Broadband Mobile users are generally connecting inside buildings as shown on the
figure above. Then we can expect an efficient usage of HSDPA for those users.
Indoor coverage + HSDPA

= a Winning combination

Section 1 Pager 18
3.2 Configurations of Deployment inside UMTS
Dedicated Configuration
HSDPA on dedicated carrier
R99 only cell

HSDPA cell
R99/HSDPA cell
HSDPA on shared carrier
Mixed Configuration
HSDPA on two carriers

HSDPA Introduction
Support of HSDPA on dedicated cells

Several carrier configurations exist for the support of HSDPA. Operators are given the possibility to
dedicate cells to HSDPA. This will for example lead to the configuration illustrated in the following
figure, with 2 cells per sector, one supporting DCH traffic and the other supporting HSDPA traffic.
The carrier dedicated to HSDPA will support:
In Downlink, the HS-DSCH channels as well as the associated DCH and the common channels
In Uplink, the DCH and signalling HS-DPCCH channels
Operators can thus benefit from an early HSDPA deployment configuration offering:
Full HSDPA capacity (full carrier power and set of codes) and high throughputs, in order to have
appealing services for the capture of new subscribers
A secured transition to HSDPA with a stepwise approach, limiting the impact of this new technology
introduction on the existing DCH services and QoS.
This corresponds to the Alcatel-Lucent recommended configuration for the launch of HSDPA services. It is
also very well suited for Laptop applications (data cards).
Support of mixed DCH bearers and HSDPA bearers in the same cell
Another HSDPA carrier configuration available with EVOLIUM™ Release R5 provides the ability to mix DCH
and HSDPA traffic in the same cell. In this case, DCH and HSDPA traffic will share the cell’s resources in
terms of power and codes.
Alcatel-Lucent recommends going for this configuration as soon as the optimization of HSDPA has been
performed successfully on the dedicated carrier, not to harm the current QoS of DCH services. Then,
this mixed configuration will enable operators to take full benefit of HSDPA handsets capable of multi-
call support. Indeed, the mixed carrier configuration offers the ability to have a voice call on DCH
simultaneously with a Packet call on HSDPA.
There is a third configuration with 2 layers: one freq. dedicated to DCH/another one mixed: HSDPA and
DCH, that also enables multi-calls.
Section 1 Pager 19
3.3 Evolutions of HSDPA
HSPA+ / LTE (3GPP R7 / R8)

- Up to 42/100 Mbps (DL)
- Up to 11/50 Mbps (UL)
HSUPA (3GPP R6)

- Up to 5.7 Mbps (UL)
HSDPA (3GPP R5)

- Up to 14.4 Mbps (DL)
2005 2006 2007 Beyond

HSDPA Introduction
HSDPA (3GPP R5): HSDPA (3GPP R7/R8):

(Frozen in June 2002) New multiplexing technique : Orthogonal
HS-DSCH Frequency Division Multiplexing (OFDM)
AMC (QPSK/16-QAM) Higher frequency bandwidth
H-ARQ Higher carrier frequency
MAC-hs Extended modulation technique: 64-QAM
Spatial Multiplexing using Multiple Input
Multiple Output (MIMO) systems
HSDPA (3GPP R6):

(Frozen in March 2005)
CQI enhancement for FDD mode
Fractional dedicated physical channel
…. refer to [3GPP TR 25.899] for more information
HSUPA (with Enhanced-DCH in UL) about those improvement
Smart antennas
Some key aspects of the E-DCH are:

Dedicated channel operating in the cell_DCH
state
Fast node B based scheduling
Capable of operating with/without HSDPA in DL
Significant latency reduction enhancement due
to fast Node B scheduling, fast HARQ and
shorter TTI.
HSPA+ / LTE (3GPP R7/8): Section 1 Pager 20
HSPA + is an improvement of HSDPA/HSUPA :
Self-Assessment on the Objectives
Please be reminded to fill in the form

for this module
The form can be found in the first part
of this course documentation

HSDPA Introduction

Section 1 Pager 21
End of Module

HSDPA Introduction

Section 1 Pager 22
2
Section 2
HSDPA Key Introduction
9300 WCDMA

Section 2 Pager 1
Blank Page

Document History
01 2007-06-26 Schweikart, Hans- Conversion to ALU template standards

Jürgen

Section 2 Pager 2
Objectives
After this section, you will be able to

List HSDPA key features


Section 2 Pager 3
Objectives [cont.]


Section 2 Pager 4
Table of Contents
Page
1 HSDPA Key Features 7
1.1 HSDPA Main Concepts & Benefits 8
1.2 Radio Resource Allocation 9
1.3 User Throughput Management 10
2 HSDPA Technical Overview 11
2.1 Code and Time Multiplexing 12
2.2 Scheduling Principle 13
2.3 Adaptive Modulation and Coding 15
2.4 Fast Retransmission Combining: Hybrid-ARQ 17
2.5 NodeB Role 18


Section 2 Pager 5

HSDPA Key Introduction This page is left blank intentionally

Section 2 Pager 6
1 HSDPA Key Features


Section 2 Pager 7
1.1 HSDPA Main Concepts & Benefits
HSDPA
Higher User
• No Fast Power Control (100% of available power used) Data Rates
• No Variable Spreading (SF = 16)
• No Soft Handover (for DL user data channel) Lower Service
Response Time
• Time & Code Multiplexing of User Data (Shared Channel) Higher Packet
• Adaptive Modulation & Coding (Rate Adaptation) Data Capacity
• Fast Retransmission / Scheduling Layer in NodeB
• Short Radio Framing (2ms) Better Services
Availability
- resource allocation
- fast retransmission
H SD
PA
Better End-
End-User Perceived Quality
HSDPA introduces a completely new strategy to handle downlink high data rate packet services and two
of the most fundamental features of W-CDMA (fast power control and spreading factor variability) are
disabled. In addition, the new downlink channel used to carry the PS data does not support Soft
Handover.
Basically, HSDPA introduces a new common High Speed Downlink Shared Channel (HS-DSCH) shared by
several users. In addition, it introduces enablers for the high speed transmission at the physical layer
like the use of a shorter TTI (2 ms), the use of Adaptive Modulation and Coding, and the use of fast
retransmission based on hybrid ARQ (HARQ) techniques. These key mechanisms are located within the
UMTS BTS.
HSDPA considerably improves the 3G end-user data experience by enhancing downlink performance.
HSDPA significantly reduces the time it takes a mobile user to retrieve broadband content from the
network. A reduced delay is important for many applications such as interactive gaming. HSDPA notably
allows a more efficient implementation of interactive and background traffic classes as standardized
by 3GPP. HSDPA high data rates also improve the use of streaming applications, while lower roundtrip
delays will benefit Web browsing applications. In addition, HSDPA improved capacity opens the door
for new and data-intensive applications that cannot be fully supported with R4 because of bandwidth
limitations.

Section 2 Pager 8
1.2 Radio Resource Allocation
9
R9 Dedicated Channel
TS
UM
Dedicated Channel
Dedicated Channel
D PA
HS
Shared Channel

The WCDMA system normally carries user data over dedicated transport channels, or DCHs, which brings
maximum system performance with continuous user data. The DCHs are code multiplexed onto one RF
carrier. In the future, user applications are likely to involve the transport of large volumes of data that
will be bursty in nature and require high bit rates.
HSDPA introduces a new transport channel type, High Speed Downlink Shared Channel (HS-DSCH) that
makes efficient use of valuable radio frequency resources and takes into account packet data services
burstiness.
This new transport channel shares multiple access codes, transmission power and use of infrastructure
hardware between several users. The radio network resources can be used efficiently to serve a large
number of users who are accessing bursty data. To illustrate this, when one user has sent a data packet
over the network, another user gets access to the resources and so forth. In other words, several users
can be time multiplexed so that during silent periods, the resources are available to other users.

Section 2 Pager 9
1.3 User Throughput Management
9
R9 Same Throughput
TS
UM
Unused Power
Power Unused Power Data Power

Control
Data Power
D PA
HS
100%
Rate
Adaptation 100% Power

There is no more fast Power Control with HSDPA and the High Speed Downlink Shared Channel is
transmitted at a constant power while the modulation, the coding and the number of codes are
changed to adapt to the variations of radio conditions.
Where R4 dedicated downlink PS data channels offer a constant data rate using power adaptability,
HSDPA shared channel opposes PS data rate variability.

Section 2 Pager 10
2 HSDPA Technical Overview


Section 2 Pager 11
2.1 Code and Time Multiplexing
UE 1 UE 2
Codes UE 3 UE 4
e SF .
Code #4
ia bl ux
r M UMTS/FDD (R’99)
Va ime
Code #3
Code #2
o T
Code #1
n Time
Codes
2ms
= 16 s
Code #5
d SF 2m .
e I= x
Fix d TT e Mu
Code #4
HSDPA (R5)
Code #3
i xe Cod
Code #2
F & Time
Code #1 e
2 12
Tim All Rights Reserved © Alcatel-Lucent 2010
How are UE multiplexed in HSDPA?

Time multiplexing between UE
Code multiplexing between UE, and one or several codes per UE.
What is a radio resource in HSDPA?

An HSDPA radio resource is defined for one UE:
over a shared channel (HS-DSCH)
during a TTI fixed to 2ms
by a certain number of Codes (up to 15 channelization codes with a fixed Spreading factor SF=16)
by a certain amount of transmitted power

Section 2 Pager 12
2.2 Scheduling Principle
Different algorithms to perform the • Quality measurement reports

resource allocation based on: • Priorities between UEs
• Time since last transmission
Codes • …
2ms
Code #5
Code #4
Code #3
Code #2
Code #1 Time
HS-DSCH/HS-PDSCHs
RNC Node B

What happen if we don’t use scheduling?

Without Scheduling, if radio resources are equally shared between UE in order not to waste them, it may
happen that one UE is allocated some resources when it experiences bad radio conditions. We know
that in that case, the data will be corrupted at reception or even lost.
It will be required to retransmit the same data once again. Then it results in a loss of resources (as the
same resources could have been allocated to other UE in better radio conditions) and in loss of time (as
other UE are still waiting for resources and for this one the network will have to retransmit the same
radio frame).

Section 2 Pager 13
2.2 Scheduling Principle [cont.]
The UE are scheduled according to specific

criteria such as radio conditions
Fading
(Channel variation)
UE1
UE2
UE3
Time
UE 1 UE 2 UE 1 UE 3
2ms 2ms 2ms 2ms

Fast Scheduling: granularity of 2ms (HS-DSCH TTI)
TTI= Transmission Time Interval
How to schedule the UE?

Based on Channel Quality Measurements (CQI) performed by the UE and some other parameters (like
priorities between users, duration since the last transmission), the scheduler (based in the Node-B)
decides which TTI, which data rate with which codes and which power to allocate to each UE.
To perform this scheduling at the speed of the channel variation, it has been shown that the channel is
sufficiently constant for a bit rate lower than 5ms, which is why 3GPP decided to fix the scheduling
resolution (TTI) to 2ms.
Why UE 3 is scheduled on the last TTI?

It may have not been scheduled since a long time and this scheduler has implemented some fairness in
time between users.

Section 2 Pager 14
2.3 Adaptive Modulation and Coding
Radio
Link Ok, for this UE:
Quality • at the next TTI,
Quality Feedback
• I choose the 16-QAM modulation
• and a coding rate of 3/4
UA07
QPSK 16-QAM 64-QAM
Quadrature Phase Shift Keying 16 Quadrature Amplitude Modulation 64 Quadrature Amplitude Modulation
• 4 states • 16 states • 6 bits per symbol
• 2 bits per symbol • 4 bits per symbol
The user rate is adapted to the quality

of the radio link at each TTI by the selection of
a modulation and a coding rate
R’99 versus R5 regarding modulation and coding rate

Adapting the coding rate is already performed in R’99.
In R5, coding rate is adapted much faster, every TTI (=2ms) and 3GPP offers also the possibility to
change the modulation to 16-QAM when achieving very good channel conditions.
Link adaptation in R’99 different than the one in R5

Traditionally, WCDMA has used fast power control as link adaptation, but HSDPA holds the transmission
power constant over the TTI and uses Adaptive Modulation and Coding (AMC) as an alternative link
adaptation method to power control and variable SF in order to improve the spectral efficiency.
HSDPA provides a higher dynamic Link Adaptation by adapting the data rate and the power depending
on the radio conditions faster than with WCDMA in R’99. A good Link Adaptation allows to work under
good conditions everywhere: at cell edge (with low data rate and/or high power) and at cell center
(with high data rates and/or low power).

Section 2 Pager 15
2.3 Adaptive Modulation and Coding [cont.]
Throughput
[Kbps]
2500 16-QAM + coding rate 3/4
2000
1500
QPSK + coding rate 1/2
1000
Bad el od
Go nel
nn
500 cha itions n
ch itions
a
nd d
co c on
0
y Radio link quality
(SNR) [dB]
64QAM : Higher peak throughputs in very good radio conditions

16-QAM: High throughput in good channel conditions
QPSK: Robustness in case of bad radio conditions

SNR= Signal to Noise Ratio

CR = Coding Rate
How the AMC maximizes the spectral efficiency over scheduling resource allocation?
The Adaptive Modulation and Coding (AMC) optimizes the spectral efficiency by maximising the user bit
rate during its transmission time: indeed it changes the modulation and the coding rate to increase the
bit rate in the limit of a certain quality of the link (BLER threshold).
How AMC is working?

The AMC enables to select the most suitable combination of parameters (modulation/Nb. codes/coding
rate).
For example, it selects 16-QAM, CR=3/4 over 10 codes when SNR>y dB, and QPSK, CR=1/2 over 5 codes
when SNR<y dB.

Section 2 Pager 16
2.4 Fast Retransmission Combining: Hybrid-ARQ
Hybrid-Automatic Repeat reQuest (H-ARQ) reduces the delay and increases

the efficiency of retransmission data.
Packet transmission
RLC NACK On a DCH channel

RLC Re-Transm
ission
Serving Node-B UE
RNC RLC ACK
R & NT
Packet transmission
TE IE
On the
FAS FFIC H-ARQ NACK Combining
Rx packets HS-DSCH channel
E H-ARQ Re-Tx
O RE H-ARQ ACK
M RLC ACK
Serving
Node-B UE
RNC

What is the goal of H-ARQ?

The H-ARQ mechanism has been introduced to reduce the delay and increase the efficiency of
retransmitting data by allowing lower layer retransmission (at MAC layer).

Section 2 Pager 17
2.5 NodeB Role
RNC Capacity Request Capacity Allocation

Control FP Control FP Data FP
Flow Control
Dynamically fills the Queues of each UE
Queue IDs
Scheduler
Fills the TTIs with one or more users based on their
priority and feedback information
HARQ Processes
Retransmissions handling, TFRC selection, AMC…
Feedback Reception Radio Transmission

The main architectural shift with respect to R4 is the introduction of MAC entity, the Mac-hs layer,
located in the NodeB, near the physical channel, which allows s high reactivity in the resource
allocation according to the RF conditions changes. This Mac-hs layer manages the scheduling of users
and the retransmissions of packets.
This architectural evolution gives a new importance to the role of the NodeB in the UTRAN. It then
necessarily goes together with the introduction of some new functions managed by the NodeB among
which:
Flow Control: new control frames are exchanged in the user plane between NodeB and RNC to
manage the data frames sent by the RNC;
Scheduler: it determines for each TTI which users are going to be served and how many data bits
they are going to receive;
Hybrid Automatic Repeat Query: This ARQ schema is for error recovery at the physical layer (which
exists independently of the ARQ scheme at the RLC layer). This fast retransmission scheme is of
paramount importance for TCP as generally TCP has not performed well in a wireless environment;
Adaptive Modulation and Coding: new channel coding stages and radio modulations schemes are
introduced to provide data throughput flexibility;
Feedback demodulation and decoding in UL.

Section 2 Pager 18

for this module


Section 2 Pager 19
End of Module


Section 2 Pager 20
3
Section 3
HSDPA Key Channel
9300 WCDMA

Section 3 Pager 1
Blank Page

HSDPA Key Channel
Document History

Section 3 Pager 2
Objectives

Describe HSDPA channel operation

HSDPA Key Channel

Section 3 Pager 3
Objectives [cont.]

HSDPA Key Channel

Section 3 Pager 4
Table of Contents
Page
1 HSDPA New Channel Structure 7
1.1 HSDPA Channels 8
1.2 HSDPA Physical Layer Structure 9
1.3 Channel mapping in 3GPP/HSDPA (Downlink) 10
1.4 Channel mapping in 3GPP/HSDPA (Uplink) 11
1.5 Structure of HS-DSCH-associated Channels 12
2 Channel Features 13
2.1 HS-DSCH specific Characteristics 14
2.2 OVSF Code Tree Reservation 15
3 Power Management 16
3.1 Power Management Principles (first Tx) 17

HSDPA Key Channel

Section 3 Pager 5

HSDPA Key Channel This page is left blank intentionally

Section 3 Pager 6
1 HSDPA New Channel Structure

HSDPA Key Channel

Section 3 Pager 7
1.1 HSDPA Channels
What are the channels related to HSDPA?
Data in UL/DL (DTCH/DCH)

DL in option
Control in DL (HS-SCCH) UE Signaling (DCCH/DCH)
Resource allocation RRC/RLC Signaling
information (TTI, codes,…)
Channel quality feedback (HS-DPCCH) [UL]

Data in DL •Channel Quality Indicator (CQI) -HS-DPCCH
(HS-DSCH maps onto 1 up to
•ACK/NACK - HS-DPCCH
15 HS-PDSCHs)
Useful Data only

HSDPA Key Channel
[3GPP TS 25.211]
The HS-SCCH (High Speed-Shared Control CHannel) is a fixed rate (SF=128) downlink physical channel
used to carry downlink signalling related to HS-DSCH transmission (e.g. Transport Block size,
Modulation, number of codes).
All relevant Layer 1 information is transmitted in the associated HS-SCCH i.e. the HS-PDSCH does not
carry any Layer 1 information.
If the UE did detect consistent control information intended for this UE in the immediately preceding
subframe, it is sufficient to only monitor the same HS-SCCH used in the immediately preceding
subframe. [3GPP TS 25.214]
If the UE did not detect consistent control information intended for this UE on any of the HS-SCCHs in
the HS-SCCH set in the immediately preceding subframe, the UE shall monitor all HS-SCCHs in the HS-
SCCH set. The maximum size of the HS-SCCH set is 4.
[3GPP TS 25.321]
The Transport Block size [bits] for HS-DSCH (High Speed-Donwlink Shared CHannel) is derived from
the TFRI (Transport Format Resource Indicator) value signalled on the HS-SCCH and from the
modulation and the number of codes also signalled on the HS-SCCH. (See table of mapping in TS
25.321)
[see next slide for information about HS-DPCCH, HS-PDSCH, associated DCH]

Section 3 Pager 8
1.2 HSDPA Physical Layer Structure
(DL) HS-PDSCH (High Speed Physical Downlink Shared CHannel)

• Data information with fixed SF=16 (up to 15 per UE)
• Supports QPSK modulation and 16-QAM in option
(DL) HS-SCCH (High Speed Shared Control CHannel)

• Control information for only one UE with fixed SF=128
(allocated channelization codes, UE identity, Transport Block size, H-ARQ process …)
• 3GPP specifies a max. of 4 HS-SCCH/cell, then up to 4 UEs/TTI
(UL) HS-DPCCH (High Speed Dedicated Physical Control CH.)

• Control information (ACK/NACK and CQI) with fixed SF=256
(UL/DL) Associated DPDCH/DPCCH (associated DCH)

• Control information (RRC/RLC level)
• Data information (in UL at least)

HSDPA Key Channel
The UE shall transmit the ACK/NACK information received from MAC-hs in the corresponding HS-DPCCH
(High Speed-Dedicated Physical Control CHannel) sub-frame.[3GPP TS 25.211]
The HS-DPCCH (SF=256) carries uplink feedback signalling related to downlink HS-DSCH transmission.
The HS-DSCH-related feedback signalling consists of Hybrid-ARQ Acknowledgement (HARQ-ACK) and
Channel-Quality Indication (CQI).
There is at most one HS-DPCCH on each radio link. The HS-DPCCH can only exist together with an
uplink DPCCH.
[3GPP TS 25.211]
The High Speed Physical Downlink Shared Channel (HS- PDSCH) is used to carry the High Speed
Downlink Shared Channel (HS-DSCH).
A HS-PDSCH corresponds to one channelization code of fixed spreading factor SF=16 from the set of
channelization codes reserved for HS-DSCH transmission. Multi-code transmission is allowed, which
translates to UE being assigned multiple channelisation codes in the same HS-PDSCH subframe,
depending on its UE capability.
An HS-PDSCH may use QPSK or 16QAM modulation symbols.
An associated uplink DCH mapped on a DPCH is necessary to carry data of the UE as HS-PDSCH is just
carrying data in DL.
[see previous slide for information about HS-SCCH, HS-DSCH]

Section 3 Pager 9
1.3 Channel mapping in 3GPP/HSDPA (Downlink)
Logical Channels DTCH CTCH DCCH CCCH PCCH BCCH
Transport Channels
DCH HS-DSCH A
FACH PCH BCH
DP
HS
Physical Channels
DPDCH HS-PDSCHs
DPDCH and DPCCH + S-CCPCH P-CCPCH
multiplexed by +
time
DPCCH HS-SCCHs
A
DP
HS
Not associated
AICH PICH CPICH P-SCH S-SCH
with transport channels

HSDPA Key Channel
HS-DSCH definition: refer to [3GPP TS 25.301]

The HS-DSCH is a resource that exists in downlink only. It has only impact on the physical and transport
channel levels, so there is no definition of shared channel in the logical channels provided by MAC.
The HS-DSCH is a transport channel for which a common pool of radio resources is shared dynamically
between several UEs. The HS-DSCH is mapped to one or several physical channels such that a specified
part of the downlink resources is employed. For the HS-DSCH no macrodiversity is applied, i.e. a
specific HS-DSCH is transmitted in a single cell only.The HS-DSCH is defined as an extension to DCH
transmission. Physical channel signalling is used for indicating to a UE when it has been scheduled and
then the necessary signalling information for the UE to decode the HS-PDSCH.
In every HS-DSCH TTI, one or several HS-PDSCHs can be used in the downlink. Therefore, the HS-DSCH
supports code multiplexing. MAC multiplexing of different UEs shall not be applied within an HS-DSCH
TTI, i.e. within one HS-DSCH TTI an HS-PDSCH is assigned to a single UE. However, MAC multiplexing is
allowed on a TTI by TTI basis, i.e. one HS-PDSCH may be allocated to different UEs at each TTI.
Resource allocation and UE identification on HS-DSCH:

For each HS-DSCH TTI, each HS-SCCH carries HS-DSCH related downlink signalling for one UE, along with a
UE identity (via a UE specific CRC) that identifies the UE for which this information is necessary in
order to decode the scheduled HS-PDSCH.
Note: In Evolium R5, DCCH is not mapped on HS-DSCH

Section 3 Pager 10
1.4 Channel mapping in 3GPP/HSDPA (Uplink)
Logical Channels DTCH DCCH CCCH
Transport Channels DCH1 DCH2 RACH
CCTrCH
Physical Channels
DPDCH
DPDCH and DPCCH + HS-DPCCH PRACH
multiplexed by modulation A
DPCCH DP
HS
Note: In Evolium R5, DCCH is not mapped on HS-DSCH

HSDPA Key Channel

Section 3 Pager 11
1.5 Structure of HS-DSCH-associated Channels
Tslot=2560 chips, Mx10x2k bits (k=4)

M=2 for QPSK
Data (N bits)
HS-PDSCH Structure M=4 for 16-QAM
(Downlink Data Channel)
Slot #0 Slot #1 Slot #2
One HS-PDSCH subframe

(TTI=2ms =3 time slots)
•Transport block size
Hybrid-ARQ process number
•H-ARQ related info. Redundancy version
New-data indicator
TTI=2ms / 3 Time Slots
Part-1 Part-2 CRC HS-SCCH Structure
(Downlink Control Channel)
•Channelization codes to despread •UE Identity via UE
•Modulation scheme (QPSK or 16-QAM) specific CRC
TTI=2ms / 3 Time Slots
HS-DPCCH Structure ACK/NACK Downlink CQI

(Uplink Control Channel)
Subframe #0 Subframe #i Subframe #4
One radio frame (10 ms)

HSDPA Key Channel
Frame structure for HS-PDSCH (SF=16, turbo coding)

A HS-PDSCH corresponds to one channelization code of fixed spreading factor SF=16 from the set of
channelization codes reserved for HS-DSCH transmission. Multi-code transmission is allowed, which
translates to UE being assigned multiple channelization codes in the same HS-PDSCH sub-frame,
depending on its UE capability.
An HS-PDSCH may use QPSK or 16QAM modulation symbols, but n HS-PDSCH codes transmitted in parallel
for a UE shall use the same modulation.
M is the number of bits per modulation symbols i.e. M=2 for QPSK and M=4 for 16QAM.
For FDD, following information is carried on the HS-SCCH (SF=128, convolution coding r=1/2), refer to
[3GPP TS 25.858]
Transport-format and Resource related Information (TFRI): Channelization-code set: 7 bits,
Modulation scheme: 1 bit, Transport-block size: 6 bits
Hybrid-ARQ-related Information (HARQ information): Hybrid-ARQ process number: 3 bits (thus
corresponding to a maximum of 8 HARQ processes at UE), Redundancy version: 3 bits, New-data
indicator: 1 bit (“0” for the first MAC-hs PDU transmitted by a HARQ process), UE ID: 10 bits implicitly
encoded in the CRC
Frame structure for Uplink HS-DPCCH (SF=256, 15 kbps channel bit rate), refer to [3GPP TS 25.211]
The HS-DPCCH carries uplink feedback signalling related to downlink HS-DSCH transmission.
The HS-DSCH-related feedback signalling consists of Hybrid-ARQ Acknowledgement (HARQ-ACK) and
Channel-Quality Indication (CQI). Each sub frame of length 2 ms (3*2560 chips) consists of 3 slots, each
of length 2560 chips.
The HARQ-ACK (positive or negative) is carried in the first slot of the HS-DPCCH sub-frame. The CQI is
carried in the second and third slot of a HS-DPCCH sub-frame. There is at most one HS-DPCCH on each
radio link. The HS-DPCCH can only exist together with an uplink DPCCH.
Section 3 Pager 12
2 Channel Features

HSDPA Key Channel

Section 3 Pager 13
2 Channel Features
2.1 HS-DSCH specific Characteristics
Fixed TTI, 2 Modulations, lower Coding Rates, Multi-Code

Transmission, Code Multiplexing
Ex.: QPSK Ex.:16-QAM

Coding rate=1/4 Coding rate=3/4
Codes
UE 1 UE 2
UE 3 UE 4
User 5 User 3 User 5
UE 5
15 codes
(SF=16)
User 1
User 4 User 2
HS-PDSCH #5
User 4
Time
User 1 User 2 User 1 User 3 User 3
TTI=2ms

HSDPA Key Channel
The HS-DSCH has specific characteristics in many ways compared with existing Release’99 channels:
The Transmission Time Interval (TTI) or interleaving period has been defined to be 2 ms (3 slots) to
achieve short round-trip delay for the operation between the terminal and Node B for retransmissions.
The HS-DSCH 2-ms TTI is short compared to the 10-, 20-, 40- or 80-ms TTI sizes supported in
Release’99.
Adding higher order modulation scheme, 16 QAM, as well as lower encoding redundancy has increased
the instantaneous peak data rate.
In the code domain perspective, the SF is fixed; it is always 16, and multi-code transmission (up to 15
codes/UE) as well as parallel transmission (up to 4 UE/TTI) of different users can take place. The
maximum number of codes that can be allocated is 15, but depending on the terminal (UE) capability,
individual terminals may receive a maximum of 5, 10 or 15 codes.
Channel Coding
[25.858] HS-DSCH channel coding uses the existing rate 1/3 Turbo code and the existing Turbo code
internal interleaver, as outlined in 3G TS 25.212. Other code rates are generated from the basic rate
1/3 Turbo code by applying rate matching by means of puncturing or repetition.
[Holma] turbo coding is the only coding scheme used. However, by varying the transport block size, the
modulation scheme and the number of multi-codes and turbo code rates other than 1/3 become
available. In this manner, the effective code rate can vary from ¼ to ¾; i.e. the number of bits per
code can vary by changing the coding gain.

Section 3 Pager 14
2 Channel Features
2.2 OVSF Code Tree Reservation
SF4
SF8
SF16
SF32 HS-PDSCH
SF64
HS-SCCH
SF128 HSDPA
SF4
SF8
SF16
SF32
HS-PDSCH
SF64
SF128 cmCH
HSDPA + DCH
SF256 HS-SCCH

HSDPA Key Channel
The configuration of the OVSF code tree can provide up to 15 SF16 codes allocated to HS-PDSCH and up
to 4 SF128 codes for HS-SCCH.
All R99 common channels (P-CPICH, P-CCPCH, S-CCPCH) are allocated at the top of the tree, with a
minimal equivalent occupancy of SF32.
Immediately below the HS-SCCH SF128 codes are allocated. These codes are allocated at cell setup and
cannot be used or preempted for other services.
The HS-PDSCH SF16 codes are allocated and reserved by the RNC at the bottom of the tree.
All the remaining codes are therefore contiguous and left for further DCH allocations. This includes
associated DCH as well as any other calls mapped on DCH (e.g. speech calls, streaming, etc).
Note that the maximum configuration (15 HS-PDSCH codes and 4 HS-SCCH codes) leaves no room in the
OVSF tree for DCH (due to common channels occupancy) so it is not even possible to allocate
associated SRB for HSDPA calls.

Section 3 Pager 15
3 Power Management

HSDPA Key Channel

Section 3 Pager 16
3 Power Management
3.1 Power Management Principles (first Tx)
Cell
Power
PMAX
PHSDPA
HS-DSCH
HS-SCCH
DCH margin
DCH
CmCH

HSDPA Key Channel
HSDPA power management is based on the principle that HSDPA channels can use all the remaining
power left by dedicated and common channels. In order to compensate the DCH power fluctuation
mainly due to power control, a margin is considered.
The total available power for HSDPA corresponds to the difference between the maximum available
power in the cell and the power for R99 channels plus margin.
UE is scheduled only if there remains enough power to transmit at least the HS-SCCH. Otherwise the
NodeB try to schedule another UE in the TTI. If all UEs require power for HS-SSCCH higher than what is
available at NodeB level, none of them is scheduled.

Section 3 Pager 17
Summary

HSDPA Key Channel

Section 3 Pager 18

for this module

HSDPA Key Channel

Section 3 Pager 19
End of Module

HSDPA Key Channel

Section 3 Pager 20
4
Section 4
HSDPA Key HARQ
9300 WCDMA

Section 4 Pager 1
Blank Page

HSDPA Key HARQ
Document History

Section 4 Pager 2
Objectives

Describe H-ARQ process

HSDPA Key HARQ

Section 4 Pager 3
Objectives [cont.]

HSDPA Key HARQ

Section 4 Pager 4
Table of Contents
Page
1 Hybrid Automatic Repeat Query Principles 7
1.1 Fast Retransmission with Hybrid-ARQ 8
1.2 H-ARQ in HSDPA: How it works? 9
2 HARQ Processes 13
2.1 Multiple HARQ Processes 14
2.2 Parallel H-ARQ Processes 15
2.3 Stop And Wait Principles 16
3 Redundancy Version 17
3.1 HARQ Types 18
3.2 Two H-ARQ Combining Techniques 19
3.3 Answer the Questions 20
3.4 H-ARQ Combining Performances 21
3.5 Redundancy Version Parameters 22
3.6 Dynamic RV Table Selection 23

HSDPA Key HARQ

Section 4 Pager 5

HSDPA Key HARQ This page is left blank intentionally

Section 4 Pager 6
1 Hybrid Automatic Repeat Query
Principles

HSDPA Key HARQ

Section 4 Pager 7
1 Hybrid Automatic Repeat Query Principles
1.1 Fast Retransmission with Hybrid-ARQ
Packet transmission
R4/R5 on a
RLC NACK
DCH channel
RLC Re-Transm
ission The erroneous
Serving UE block
RNC RLC ACK is deleted!
Packet transmission
R5 on the
H-ARQ NACK Combining
Rx packets
HS-DSCH
H-ARQ Re-Tx
channel
H-ARQ ACK The erroneous block
RLC ACK
is stored for
Serving Node-B UE recombination!
RNC

HSDPA Key HARQ
What is the goal of H-ARQ?

The H-ARQ mechanism has been introduced to reduce the delay and increase the efficiency of
retransmitting data.
What are the advantages of H-ARQ implemented in R5 vs. R’99?

In previous releases of UMTS (R99), with H-ARQ type I, when the UE received a false block, it threw it
away and waited for a retransmission of the block from the RNC hoping it could decode this one.
Hybrid ARQ Type II/III is added in R5, whose aim is to recombine a retransmission with previous
transmissions in order to increase the probability to decode it. Time diversity is added: because of the
fast fading effect, transmitting twice a block at 2 distinct times with a power P and add the received
soft bits is much better than transmitting it only once with a power 2*P since the probability not to be
in a fading hole at least is increased.
What are the drawbacks of H-ARQ?

The disadvantage of H-ARQ is that the UE needs to store the false blocks and add the new soft bits
received to the previous ones he couldn’t decode correctly, which requires additional memory and
processing.
How it works?
1. The Node B transmits one packet in 1 HS-DSCH TTI.
2. The UE sends a ACK/NACK indicating if the packet was correctly received or not. In case of NACK, the
UE stores the received data in a buffer.
3. If the Node B has received a NACK, it will retransmit the same transport block (at the earliest 12 ms
after the previous transmission) and the UE will combine the packet with the previous transmission(s)
(which increases the probability to decode correctly the transport block).
4. If the Node B has received a ACK, it will transmit a new block.

Section 4 Pager 8
1.2 H-ARQ in HSDPA: How it works?
1st H-ARQ Process

at T0
HS-DSCH
block #1 NACK / CQI
HS-DPCCH
2. ACKNOWLEDGMENT
HS-DSCH
block #1
HS-PDSCHs
1. FIRST
TRANSMISSION
block #1
Soft buffer
HSDPA Key HARQ

Section 4 Pager 9
1.2 H-ARQ in HSDPA: How it works? [cont.]
2nd H-ARQ Process

at T0 + 2ms
HS-DSCH
block #2 ACK / CQI
HS-DPCCH
2. ACKNOWLEDGMENT
HS-DSCH
block #2
HS-PDSCHs
1. FIRST
TRANSMISSION
block #1 block #2
Soft buffer Re-Ordering

HSDPA Key HARQ

Section 4 Pager 10
3rd H-ARQ Process

at T0 + 4ms
HS-DSCH
block #3 ACK / CQI
HS-DPCCH
2. ACKNOWLEDGMENT
HS-DSCH
block #3
HS-PDSCHs
1. FIRST
TRANSMISSION
block #3
block #1 block #2

HSDPA Key HARQ

Section 4 Pager 11
1st H-ARQ Process
at T0 + 12ms
ACK / CQI
HS-DSCH HS-DPCCH
block #1
2. ACKNOWLEDGMENT
2nd decode attempt

1. FIRST HS-DSCH
success after
block #1
Re-TRANSMISSION combining
HS-PDSCHs
block #3
block #1 #3
block #2
block #1 #2
block #1

HSDPA Key HARQ
H-ARQ Combination mechanism may require new Mobile equipment with a larger memory to store MAC-hs
PDU until a decoding success.
Retransmission with errors, but thanks to combining of previous transmissions, the block is considered as
successfully received

Section 4 Pager 12
2 HARQ Processes

HSDPA Key HARQ

Section 4 Pager 13
2 HARQ Processes
2.1 Multiple HARQ Processes
HARQ
CK
/ NA HARQ
AC K HARQ
HARQ UE HARQ
Category Processes
Soft Bits
HSDSCH Combining Category 1 2
Category 2 2
ACK/NACK Category 3 3
HARQ Category 4 3
HARQ Category 5 6
Retransmission Soft Bits Category 6 6
Management Combining
ACK Category 7 6
/ NA
HARQ CK
Category 8 6
HARQ
Category 9 6
HARQ HARQ
HARQ Category 10 6
HARQ
HARQ Category 11 3
Soft Bits
HARQ Category 12 6
Combining
HARQ
HARQ

HSDPA Key HARQ
The retransmission mechanism selected for HSDPA is Hybrid Automatic Repeat Query (HARQ) with Stop
and Wait protocol (SAW). HARQ allows the UE to rapidly request retransmission of erroneous transport
blocks until they are successfully received. HARQ functionality is implemented at the MAC-hs layer,
which is terminated at the NodeB, as opposed to the RLC (Radio Link Control), which is terminated at
the S-RNC. Therefore the retransmission delay of HSDPA is much lower than for R4, significantly
reducing the delay jittering for TCP/IP and delay sensitive applications.
The HARQ consists in:

• Re-transmitting by the NodeB the Data Blocks not received or received with error by the UE.
• Combining by the UE the transmission and the re-transmission in order to increase the probability to
decode correctly the information. This is a form of soft combining.
There is a HARQ process assigned per transport block for all the retransmissions.
In order to better use the waiting time between acknowledgments, multiple processes can run for the
same UE using separate TTIs. This is referred to as Multiple Stop And Wait mechanism. While one
channel is waiting an acknowledgment, the remaining channels continue to transmit.
The number of processes per UE is limited and depends on UE category. The number of processes per UE
category is defined by 3GPP specifications. Once this number is reached, the UE is not be eligible by
the scheduler for new transmissions unless one of them is reset (ACK reception, max number of
retransmissions reached).

Section 4 Pager 14
2 HARQ Processes
2.2 Parallel H-ARQ Processes
Example: 2 UEs, several process each, different Inter-TTI intervals
N N A A A A A
HS-DPCCH UE1
(Uplink Control) ≈2.5 TTI) between the
(≈
reception of the packet and
when the node B receives the
ACK/NACK
UE1 UE1 UE1 UE1 UE1 UE1 UE1 UE1 UE1 UE1 UE1
HS-PDSCH UE1 packet1 packet2 packet3 packet4 packet5 packet6 packet1 packet2 packet7 packet8 packet9
(Downlink Data)
2 ms
Minimum of 12 ms before the same process can be used for the = 1 for UE1
Inter-TTI interval
transmission of a packet with new data or the retransmission of = 3 for UE2
this packet
UE2 UE2 UE2
HS-PDSCH UE2 packet1 packet2 packet1
(Downlink Data)
HS-DPCCH UE2 N A
(Uplink Control)
UE #1 UE #1 UE #1 UE #1 UE #1 UE #1
process #1 process #2 process #3 process #4 process #5 process #6
UE #2 UE #2
process #1 process #2

HSDPA Key HARQ
ACK/NACK delay and data processing (UE, Node B) allow to work with several H-ARQ processes during
unused TTI.
Up to a maximum of 8 simultaneous H-ARQ processes can be supported by the UE.
Time between 2 different H-ARQ processes (inter-TTI interval) depends on the UE category.

Section 4 Pager 15
2 HARQ Processes
2.3 Stop And Wait Principles
Wait for Transmission
HARQ
UE is Scheduled
TB HARQ
Update RV Parameters
TB HARQ
Transmit Data
HSDSCH
Wait for ACK/NACK Reception
Insert DTX
ACK ACK/NACK/DTX? DTX
Indication
NACK
Reset & Free ACK/NACK

Nret = Nret + 1
HARQ Process
YES Nret > Nret_max NO

HSDPA Key HARQ
Once a UE is scheduled, a HARQ process is assigned that may correspond to either a new Transport Block
transmission or a TB retransmission. The RV parameters are computed accordingly and data is
transmitted.
The HARQ process is then waiting for feedback information (ACK/NACK/DTX):
In case of ACK reception, the HARQ process is reset and corresponding MAC-d PDUs are removed
from memory. This HARQ process can now be used for a new transmission.
In case of NACK reception, the number of retransmissions must be incremented. If the maximum
number of retransmissions is not reached, the HARQ process is inserted in the “NACK list” of HARQ
processes asking for retransmission.
In case of DTX indication, the same actions as for NACK reception are performed, except that a
parameter must be updated to notify DTX detection (this changes the RV parameter update).
After a NACK reception or a DTX indication, the HARQ processes are just waiting for being re-scheduled
for a new retransmission.
Note:
DTX indication is used when there is no ACK/NACK reception.

Section 4 Pager 16
3 Redundancy Version

HSDPA Key HARQ

Section 4 Pager 17
3.1 HARQ Types
HARQ Blocks Decoding
New Block NO Deliver to Upper Layer
Combine Error?
RVBlocks YES Update RV Database
DATA DATA DATA DATA DATA

Combining
Chase
NACK NACK NACK NACK ACK
DATA DATA1 DATA2 DATA3 DATA4

Redundancy
Incremental
Combining
NACK NACK NACK NACK ACK

HSDPA Key HARQ
Different HARQ types are supported:

• Chase Combining is the basic combining scheme. It consists in the NodeB simply retransmitting the
exact same set of coded symbols of the original packet.
• Partial Incremental Redundancy: different redundancy information can be sent during re-
transmissions. For all redundancy versions the systematic bit must be transmitted (only RV parameters
with s=1 are taken in account)
• Full Incremental Redundancy corresponds to sequences where both systematic and non-systematic bits
can be punctured.

Section 4 Pager 18
3.2 Two H-ARQ Combining Techniques
Chase Combining Incremental Redundancy

Original useful data bits
Turbo coding Turbo coding

Rate 1/3 Rate 1/3
1st rate 1st rate

matching Node B side matching
2nd rate UE buffer size UE buffer size 2nd rate

matching matching
RV=6 1st transmission RV=0
RV=6 2nd transmission RV=2
RV=6 3rd transmission RV=5
RV=6 UE side
Eff. coding rate (RCC) = # data bits / (#data bits + # parity bits)
RIR < RCC Parity bits
⇒Better protection of the data bits (protection)
⇒higher probability to decode correctly

HSDPA Key HARQ
HOW are those data blocks combined to be able to recover a correct blocks from several corrupted
copies?
1st step Rate Matching:
3GPP TS 25.212] The first rate matching stage matches the number of input bits to the virtual buffer.
Note that, if the number of input bits does not exceed the virtual buffering capability, the first rate-
matching stage is transparent. The 1st rate matching performs segmentation at the maximum UE buffer
size when required.
The second rate matching stage matches the number of bits after first rate matching stage to the
number of physical channel bits available in the HS-PDSCH set in the TTI. The 2nd rate matching follows
transport format indications to achieve the effective coding rate expected during the TTI.
2nd step retransmission according to combining methods:
Chase Combining (CC)
Retransmit the same block with exactly the same bits at each retransmission
The UE buffer size is fixed for each transport block retransmission
Incremental Redundancy (IR)
Retransmit the same block with different redundancy information at each retransmission,
thanks to different rate matching version.
The use of different Redundancy Versions (RV) increases the performances of the channel
since the total effective coding rate is decreased (more protection bits) at each
retransmission
The UE buffer size increases for each transport block retransmission. IR requires a larger
memory and processing in the UE than the Chase Combining case.
The ARQ combining scheme is based on Incremental redundancy. Chase Combining is
considered to be a particular case of Incremental Redundancy.

Section 4 Pager 19
3.3 Answer the Questions
According to the previous slide:
What is the coding rate (Rbuffer) after the 1st rate matching for both combining
mechanisms?
What is the coding rate (RCC(#k)) of each block applying the Chase Combining
mechanism?
What is the coding rate (RIR(#k)) of each block applying the Incremental
Redundancy combining mechanism?
Compare the effective coding rates (RIR(UE) and RCC(UE)) at UE side

between CC and IR techniques after retransmissions.

HSDPA Key HARQ

Section 4 Pager 20
3.4 H-ARQ Combining Performances
coding rate 3/4, Pedestrian A, 3 km/h, H-ARQ = ON, N_max = 5

1
High error N = 1, CC
N = 2, CC
rate N = 3, CC
N = 1, IR
N = 2, IR
ns N = 3, IR
10% BLER 0.1 io
2dB gain iss
m
(N=3)
ans
BLER
-tr
Re g
o din al
c t
0.01
r de men
tte re cy
Be h Inc ndan
t
Low error wi Redu
rate Bad link Good link
quality ~2dB gain
0.001 (N=3)
quality
-10 -5 0 5 10
Ior/Ioc [dB]

HSDPA Key HARQ
What does this figure represent?

Error rate is function of the quality of the radio link
BLER= Block Error Rate
Ior/Ioc is representative of the radio conditions of the cell, in dB:
N represents the index of transmission
N=1 first transmission; N=2 second transmission (=first re-transmission)
IR = Incremental Redundancy is an H-ARQ combining technique
CC = Chase Combining is another H-ARQ combining technique
What happen without H-ARQ?
Without H-ARQ, to reach an error rate of 5%, an Ior/Ioc of 8 dB is required, meaning a good link
quality.
If the channel quality induces a BLER=0.1=10%, it means 10% chance to receive an erroneous block
(at N=1). If this block is effectively in error,
at the first retransmission (N=2), the chance to get the same block in error is now at the power of
2, i.e. BLER=10%x10%=0.01=1%,
for the second retransmission (N=3), the block has been received in error for the second time, your
chance to receive again the block in error for the third time is BLER=0.1%.
What are the advantages of H-ARQ?
You can notice that for the same number of re-transmission, both H-ARQ combining techniques achieve
better performances than without (much less errors for the same quality of the link).
What are the performances of the H-ARQ combining techniques?
We can notice that for a single retransmission (N=2), there is not much differences between Chase
Combining and Incremental Redundancy.
For the second re-transmission (N=3), IR achieves better performances than CC with a gain of 2dB.

Section 4 Pager 21
3.5 Redundancy Version Parameters
RV Coding
16QAM XRV s r b QPSK XRV s r HARQ Types
0 1 0 0 0 1 0
• Chase Combining
1 0 0 0 1 0 0
• Partial Incremental Redundancy
2 1 1 1 2 1 1 • Full Incremental Redundancy
3 0 1 1 3 0 1
4 1 0 1 4 1 2
5 1 0 2 5 0 2
6 1 0 3 6 1 3
7 1 1 0 7 0 3
RV Update
YES XRV=TRV[0]
New Tx?
k=0
Kmax NO
MIR RV Update Table
YES
k 0 1 2 3 4 5 6 7 DTX? XRV=XRV
QPSK XRV 0 2 5 6 1 3 4 7
NO
16QAM XRV 6 2 1 5 0 3 4 7
k=k+1
TRV[k] XRV= TRV[k mod Kmax]

HSDPA Key HARQ
The IR and modulation parameters necessary for the channel coding and modulation steps are the r, s
and b values. The r and s parameters (Redundancy Version or RV parameters) are used in the second
rate matching stage, while the b parameter is used in the constellation rearrangement step:
- s is used to indicate whether the systematic bits (s=1) or the non-systematic bits (s=0) are prioritized
in transmissions.
- - r (range 0 to rmax-1) changes the initialization Rate Matching parameter value in order to modify
the puncturing or repetition pattern.
- b can take 4 values (0,...,3) and determines which operations are produced on the 4 bits of each
symbol in 16QAM. This parameter is not used in QPSK and constitutes the 16QAM constellation
rotation.
These three parameters are indicated to the UE by the Xrv value sent on the HS-SCCH. The Xrv update
follows a predefined order stored in a table Trv.
A configurable parameter (CC/PIR/MIR) indicates the possibility to chose between Chase Combining,
Partial Incremental Redundancy or a mix between Partial and Full Incremental redundancy. It implies
that three different tables must be stored. Each HARQ type is characterized by its update table Trv.

Section 4 Pager 22
3.6 Dynamic RV Table Selection
k 0 1 2 3 4 5
First RTx? PIR QPSK XRV 0 2 4 6
16QAM
6 2 5 0 4 7
XRV
YES
k 0 1 2 3 4
FIR QPSK XRV 0 5 1 3 7
16QAM
6 1 3
Dynamic XRV
RV Table
Selection
k 0 1 2 3
CC+CoRe
16QAM
6 5 0 4
XRV
• maximum number of bits per HARQ

• number of RM2 punctured bits
• number of systematic bits k 0
• total number of radio bits CC
QPSK
0
XRV

HSDPA Key HARQ
The aim this feature is to optimize RV choice by dynamically selecting the most efficient HARQ type (and
its corresponding RV table) according to several parameters: UE category, number of HARQ processes
and applied AMC for first transmission.
In case this mode is activated for different HARQ types (each one being associated to a restricted
redundancy version set) that can be selected are: Chase Combining (CC), CC + Constellation
rearrangement (CC+CoRe), Partial Incremental Redundancy (PIR), and Full Incremental Redundancy
(FIR).
The principle is that Incremental Redundancy is only selected when required, i.e. only when punctured
bits by the second Rate Matching stage and total number of soft bits per HARQ process the UE can
handle are higher than the number of transmitted bits. Otherwise Chase Combining is efficient enough.
In case of IR, it is only necessary to puncture systematic bits (FIR) in case it is not possible to transmit
all parity bits punctured by the second RM stage in the first retransmission.
Note.
As the RV of the 1st transmission is identical whatever the HARQ type is, the HARQ Type only needs to be
determined when 1st retransmission occurs.

Section 4 Pager 23
Summary

HSDPA Key HARQ

Section 4 Pager 24

for this module

HSDPA Key HARQ

Section 4 Pager 25
End of Module

HSDPA Key HARQ

Section 4 Pager 26
5
Section 5
HSDPA Key Fast Scheduling
9300 WCDMA

Section 5 Pager 1
Blank Page

Document History

Section 5 Pager 2
Objectives

Describe NodeB Scheduler structure


Section 5 Pager 3
Objectives [cont.]


Section 5 Pager 4
Table of Contents
Page
1 CQI Measurements 7
1.1 CQI Reporting 8
1.2 Channel Quality Feedback 9
2 Fast Scheduling 10
2.1 Scheduler Type 11
2.2 NodeB Scheduler 12
2.3 UE, QId and SPI 13
2.4 SPI Management 14


Section 5 Pager 5

HSDPA Key Fast Scheduling This page is left blank intentionally

Section 5 Pager 6
1 CQI Measurements


Section 5 Pager 7
1 CQI Measurements
1.1 CQI Reporting
P-CP
I CH
HS-D
PCC
H
Cat.6 CQI Cat.6 D
0 0
1 0
... ...
22 0
23 -1
PHS-DSCH 24 -2
2ms
= Target BLER ≤ 10% 25 -3

PP-CPICH + Γ + ∆ 26 -4
27 -5
28 -6
29 -7
30 -8

The procedure to allocate power to the HSDPA traffic channel described in the standard is mainly based
on terminal measurements and reporting.
In this procedure the UE first estimates the Signal to Interference Ratio, from this SIR estimate it
determines the power of the HS-DSCH and then determines the corresponding CQI.
CQI determination is then performed by the UE with a HS-DSCH BLER target of 10%.
HS-DSCH power estimates are based on the UE measurement of the power of the Primary Common Pilot
CHannel (P-CPICH) (see formula in the above slide). Γ is the Measurement Power Offset, provided by the
RNC to the NodeB via NBAP signaling and to the UE via RRC signaling. This is a fixed offset relatively to
the power of the pilot. ∆ is the reference power offset which depends on the CQI processed based on
value reported by the UE and on the category of the UE (CQI mapping tables).
The power HS-DSCH is equally distributed around the physical channels HS-PDSCH.

Section 5 Pager 8
1 CQI Measurements
1.2 Channel Quality Feedback
The Channel Quality Indicator (CQI) is reported to the Node-B on the

UL control channel (HS-DPCCH)
Reported CQI
(estimated
by the UE) Transport Block Size
SCHEDULER H-ARQ parameters (RV)
Number of channelization codes
(every TTI) Allocated power
[TFRC selection] HS-PDSCH Modulation Type
Channel Quality
Feedback (CQI)
• available codes CQI ?

• available power • CQI 1
• CQI 2
• UE capabilities
•…
• ACK/NACK User data and
• CQI 30
Signalling

A CQI mapping table example is shown below for UE category 10.
Modulation
CQI Transport Number of Modulation CQI Transport Number of
Type
value Block Size HS-PDSCH Type value Block Size HS-PDSCH
1 137 1 QPSK 16 3565 5 16-QAM
2 173 1 QPSK 17 4189 5 16-QAM
3 233 1 QPSK 18 4664 5 16-QAM
4 317 1 QPSK 19 5287 5 16-QAM
5 377 1 QPSK 20 5887 5 16-QAM
6 461 1 QPSK 21 6554 5 16-QAM
7 650 2 QPSK 22 7168 5 16-QAM
8 792 2 QPSK 23 9719 7 16-QAM
9 931 2 QPSK 24 11418 8 16-QAM
10 1262 3 QPSK 25 14411 10 16-QAM
11 1483 3 QPSK 26 17237 12 16-QAM
12 1742 3 QPSK 27 21754 15 16-QAM
13 2279 4 QPSK 28 23370 15 16-QAM
14 2583 4 QPSK 29 24222 15 16-QAM
15 3319 5 QPSK 30 25558 15 16-QAM

Section 5 Pager 9
2 Fast Scheduling


Section 5 Pager 10
2 Fast Scheduling
2.1 Scheduler Type
UE Capabilities Available Power & Codes ACK/NACK/CQI Previously Transmitted PDUs
Retransmissions First
QId0 QId1 QIdN
New Transmissions
Round Robin Fair CQI Proportional Fair Alcatel-Lucent C1
UE #0 UE #1 UE #N
• power • power • power
• codes • codes • codes
• number of bits • number of bits • number of bits
The aim of the scheduler is to dynamically share available DL bandwidth among users in order to optimize
overall throughput and fulfill UTRAN and UE criteria.
The scheduler first receives as input, every TTI, the number of codes available and the remaining power for
HS-PDSCH and HS-SCCH. The received ACK/NACK and CQI, UE capabilities and configuration parameters
(provided by RNC) then can select the sub-flows of the users to schedule in order to optimally uses
available resources.
The main concepts of the scheduler are:
• Retransmissions are of higher priority then the new transmission and should be scheduled first.
• The Queue ID (Qid) is chosen according the radio condition (based on CQI) and the Scheduling Priority
Indicator (SPI or CmCH-PI).
• The transport blocks should be optimized according to the transmitted CQI and the available resources
(codes, power and CPU)
In UA5.0 the MAC-hs scheduler has been enhanced in order to support of various MAC-hs scheduler type
and manage SPI. Five scheduler types are available:
• Alcatel-Lucent scheduler: mobiles are chosen according to the number of transmitted bits and the CQI
reported;
• Classical Proportional Fair scheduler: mobiles are chosen according to reported a high CQI versus their
averaged CQI to take benefit from instantaneous good radio conditions vs. average conditions;
• Pure Fair scheduler: Throughput provided per UE must be equal;
• Max C/I scheduler chooses mobiles with the best CQI;
• Round Robin scheduler serves mobiles one after the other one.

Section 5 Pager 11
2 Fast Scheduling
2.2 NodeB Scheduler
Flow Control
(UEX, SPIY)
QId0 QId1 QIdK QIdN
• available codes
• available power
• UE capabilities
HARQ
• ACK/NACK/CQI
• Compressed Mode information
• UE HSDPA synchronisation state COST
COST = f(C1, C2)

C1 = f(Scheduler Type)
C2 = f(SPI, UE Category)
NodeB Scheduler
MAC-hs scheduling consists of choosing the MAC-D flow (QId) to serve.
The selection of a Qid to be scheduled is based on a single cost function which inputs are:
• C1 takes into account the Radio criteria (CQI) and the function depends on the scheduler type.
• C2 takes in account the priority of the QID and mainly depends on the base credit assigned to this SPI
priority and the average CQI. C2 is only used by Alcatel-Lucent and Classical Proportion Fair
schedulers.
The resulting cost is a function of these two costs, and is different according to the scheduler type.
Indeed, for Alcatel-Lucent Proportional Fair scheduler, the resulting cost should be equal to
α*C1+β*C2, while for the classical Proportional Fair, the resulting cost is rather equal to γ*C1*C2 (α, β,
γ being hard coded). The QId with the smallest cost is scheduled first. Costs are updated after the QId
has been served.

Section 5 Pager 12
2 Fast Scheduling
2.3 UE, QId and SPI
UE0 UEN
cmCH-PI 4
cmCH-PI 6
cmCH-PI 6
cmCH-PI 4
RNC
PDU flow0
PDU flow0
PDU flow0
CID m
CID n
CID l
QI0 QI0 QI1 QI2

NodeB
SP4 SP6 SP4 SP6

Each UE can be configured with one or more MAC-d flows according to the number of PS services
established and mapping rules on RNC side. Each MAC-d flow is associated to a CID for data Frame
Protocol.
One MAC-d flow is constituted of one or more logical subflows. If these subflows are assigned the same
priority, they are multiplexed at RNC side and this is transparent to NodeB and they are seen as a
single flow. If these subflows are assigned a different priority, they are discriminated by the
SPI/CmCH-PI parameter and are seen as different flows.
These resulting flows then constitute the priority queues for a UE and are assigned a Queue ID. Up to 8
queues can be defined per UE and are referred in the whole document as the QId.
For one UE, two QIds from the same MAC-d flow then necessarily have two different priorities, while two
QIds of two different MAC-d flows may have the same priority. A QId is then unambiguously defined by
its MAC-d flow CID and its priority (SPI).
In the scheduler the QId of all UEs are classified according to their SPI/CmCH-PI. This enables allocating
some bandwidth according to the priority. Up to 16 SPI can be defined in the scheduler.

Section 5 Pager 13
2 Fast Scheduling
2.4 SPI Management
TC CQIAV
C2
CQIAV TC
SPI QIdN
ARP THP SPI
QIdM
ARP THP
WEIGHT TBSAV
TBSAV WEIGHT
THROUGHPUTN
THROUGHPUTM

SPI management only applies to Alcatel-Lucent and Proportional Fair schedulers and is not supported by
the other schedulers.
The second cost function C2 is based on the priority of the QId, and mainly on the based credits
allocated to this SPI priority, and on the average CQI in order to share the HSDPA radio capacity of the
cell between users so that the throughput of each QId is be proportional:
to the weight of the SPI,
to the transport block size of the averaged CQI reported by the UE.
The base credits assigned per SPI priority provide the relative weight given per priority. The absolute
value is not meaningful, only the ratio between priorities is important.
Ratio on throughputs may be subject to a certain tolerance (around 10%) and are not fully respected in
case there is no resource limitation for some UEs (to avoid wasting resources by artificially restraining
some UEs while other UEs suffer very bad radio conditions).
Note:
SPI is determine based on the combination of the UMTS Traffic Class, the Allocation/Retention Priority
and the Traffic Handling Priority.

Section 5 Pager 14

for this module


Section 5 Pager 15
End of Module


Section 5 Pager 16
6
Section 6
HSDPA Key AMC
9300 WCDMA

Section 6 Pager 1
Blank Page

HSDPA Key AMC
Document History

Section 6 Pager 2
Objectives

Describe AMC schemes

HSDPA Key AMC

Section 6 Pager 3
Objectives [cont.]

HSDPA Key AMC

Section 6 Pager 4
Table of Contents
Page
1 Adaptative Modulation and Coding 7
1.1 AMC Principles 8
1.2 Modulation Schemes 9
1.3 AMC implementation with 16-QAM 10
1.4 Support of 16-QAM 11
1.5 Support of 64-QAM 12
1.6 New format for the HS-SCCH-Channel 13
1.7 Structure of HS-PDSCH Channel 14
1.8 64 QAM modulation and number of available HS-PDSCH 15
1.9 Layer 2 Enhancements : flexible RLC and Mac-ehs 16
1.10 Fixed RLC and Mac-hs Overview 17
1.11 Layer 2 Enhancements : flexible RLC and Mac-ehs 18
2 UE Categorization 19
2.1 UE Categories 20
2.2 New HSDPA UE Categories 21
2.3 UE Capabilities and Max Bit Rates 22
2.4 New CQI mapping 23
2.5 New CQI mapping – table F 24
2.6 New CQI mapping – table G 25

HSDPA Key AMC

Section 6 Pager 5

HSDPA Key AMC This page is left blank intentionally

Section 6 Pager 6
1 Adaptative Modulation and Coding

HSDPA Key AMC

Section 6 Pager 7
1.1 AMC Principles
UE Category Reported CQI AMC Illustration

800
700 QPSK ¼
QPSK ½
600 QPSK ¾
16QAM ½
Throughput (kbps)
500 16QAM ¾
AMC
2ms
400
300
200
100
0
Coding Modulation Number of -20 -15 -10 -5 0 5
Rate Scheme OVSF Codes Ior/Ioc (dB)
Maximum Throughput

HSDPA Key AMC
Adaptive Modulation and Coding (AMC) is a fundamental feature of HSDPA. It consists in continuously
optimizing the user data throughput based on the channel quality reported by the UE (CQI feedback.
This optimization is performed using adaptive modification of the coding rate, the modulation scheme,
the number of OVSF codes employed and the transmit power.
Different combinations of modulation and channel coding rate (based on the Transport Format and
Resource Combinations or TFRC) can be used to provide different peak data rates. Essentially, when
targeting a given level of reliability, users experiencing more favorable channel conditions (e.g. closer
to the NodeB) will be allocated higher data rates.
The above figure shows an illustration of the user throughput evolution for one single OVSF code in
function of the channel quality as a result of AMC.

Section 6 Pager 8
1.2 Modulation Schemes
16QAM
Q
QPSK
1011 1001 0001 0011 Q
10 00
1010 1000 0000 0010
I
I 11 01
1110 1100 0100 0110
1111 1101 0101 0111

2 bits per symbol
480kbps per OVSF
960 bits per TTI
4 bits per symbol

960kbps per OVSF
1920 bits per TTI
HSDPA Key AMC
In order to achieve very high data rates, HSDPA adds a higher order modulation (16QAM) to the existing
QPSK modulation used for R4 channels.
As the 16QAM requires 2 times more bits to define one radio modulation symbol, the resulting number of
bits per TTI is multiplied by a factor 2, same thing for the total maximum throughput at the physical
layer.
QPSK is mandatory for HSDPA capable UE, 16QAM is optional.

Section 6 Pager 9
1.3 AMC implementation with 16-QAM
The modulation and coding

rate are adapted to the
quality of the link
16-QAM is fully efficient in
Line of Sight environment
User data and

Signalling
CQI ?
Channel Quality
Feedback (CQI)

HSDPA Key AMC
Why not always use the 16-QAM modulation?

The curve above is deriving the Cell Throughput as a function of channel quality [C/(I+N)] are rather
explicit.
We see that the combination [16-QAM_15codes_21754bits] allows to achieve the highest throughput
(>12Mbps in LoS environment).
However with the same Modulation and Coding Scheme combination, we notice that the performance are
really low when the quality of the link is getting worse. In this situation, it is rather better to use a
lower coding rate and a more robust modulation technique in order to achieve a better throughput at
the end. Then the goal of the AMC is to dynamically adapt this combination (Modulation+Coding
Scheme) to maximize the throughput.

Section 6 Pager 10
1.4 Support of 16-QAM
Peak data rate achieved using 16-QAM

with the highest coding rate and 15 codes in parallel
(expecting favourable channels conditions)
QPSK 16-QAM
M=2 for QPSK
M=4 for 16-QAM
Signal Constellations for QPSK and 16-QAM modulations
NBCODES ⋅ RateTURBO ⋅ M ⋅ W 15 ⋅ 1 ⋅ 4 ⋅ 3.84 ⋅ 10 6

Throughput PEAK = = = 14.4Mbps
SF 16

HSDPA Key AMC
M: number of bits per symbol

W: UMTS chip rate (3.84 Mchip/s)
SF: spreading factor

Section 6 Pager 11
1.5 Support of 64-QAM
64 -QAM
UA07
6 bits per symbol

HSDPA Key AMC
With this feature the support of 64 Quadrature Amplitude Modulation (64-QAM) is introduced for HSDPA
in addition to 16-QAM and QPSK for the UE supporting the 64QAM modulation (XCEM only).
The 64-QAM modulation enables thus a higher peak data rate.The number of bits conveyed per modulation
symbol is 6 for 64QAM enabling versus 2 for QPSK, 4 for 16QAM.
64-QAM modulation can be used to obtain a throughput gain versus 16QAM for HSDPA users, provided the
following conditions are met:
· An equalizer, and preferably two receive antennas, are used at the mobile (i.e., a type-3 receiver)
· A reliable CQI is available so that 64-QAM could be chosen during channel peaks for high geometry
(Ior/Ioc) users. This requires low speeds and accurate CQI estimation at the UE.
The 64QAM usage allows to increase the HSDPA throughput in two cases:
- Case without code limitation: 64QAM allows higher peak throughputs in very good radio conditions (21.6
Mbps on the physical layer in the DL instead of 14.4 Mbps with 16QAM).
- Case with code limitation: 64QAM can also be used in code limited situations to increase the data rate for
users in good radio conditions.
Mobility of a 64QAM capable UE beetween two 64QAM capable serving cell is supported.
64AQAM is not supported over Iur as it requires radio condition close to cell centre and low mobility profile.
However 64QAM for HSDPA can be reconfigured following SRNS relocation.

Section 6 Pager 12
1.6 New format for the HS-SCCH-Channel
HS-SCCH Structure
(Downlink Control Channel)
Tslot = 2560 chips, 40 bits
Slot#0 Slot#1 Slot#2
TTI=2ms
•Channelization code set •Transport Block Size

information
•HARQ process information
•Modulation scheme
•Redundancy and costellation
(QPSK,16-QAM or 64-QAM )
version
• New data indicator
•Ue identity

HSDPA Key AMC
The current HS-SCCH format allows only to select 2 types of modulation:QPSK and 16QAM. The HS-SCCH
Format is modified in order to be able to select 3 types of modulation: QPSK,16QAM and 64QAM.
The HS-SCCH subframe containing control information among which:

• Channelization code set information ( 7 bits – slot # 0 of subframe)
• Modulation scheme information (1 bit – slot # 0 of subframe) can only tell the UE whether QPSK is used
(value 0) or not (value 1). The choice between 16-QAM and 64-QAM is known from the last bit of
channelization code set information.
A mobile decoding its identity in the slot #0 of an HS-SCCH knows that it has been assigned resources on
the HS-PDSCH channels (as indicated, with modulation, in this slot #0, other information are given in slots
#1 and 2): the mobile receives a transport block on one or several HS-PDSCH.

Section 6 Pager 13
1.7 Structure of HS-PDSCH Channel
HS-PDSCH Structure
(Downlink Data Channel) k= 4
M = 2 for QPSK,4 for 16QAM, 6 for 64QAM
Tslot=2560 chips, Mx10x2k bits
Data (N bits)
Slot #0 Slot #1 Slot #2
One HS-PDSCH subframe


HSDPA Key AMC
Frame structure for HS-PDSCH (SF=16, turbo coding)

A HS-PDSCH corresponds to one orthogonal code of fixed spreading factor SF=16.
Up to 15 codes can be reserved to HS-PDSCH per cell. One HS-DSCH can be mapped onto one or several
HS-PDSCH (the maximum number of codes is given by UE capabilities).
An HS-PDSCH may use QPSK,16QAM or 64QAM modulation symbols, but n HS-PDSCH codes transmitted in
Parallel for a UE shall use the same modulation.
M is the number of bits per modulation symbols i.e. M=2 for QPSK , M=4 for 16QAM and M=6 for 64QAM.
The teoretical peak data rate with 64-QAM is therefore 15 codes x 2880 bits/2ms = 21.6 Mbit/s (physical
channel bit rate), which have to be compared to the 14.4 Mbit/s peak rate with 16QAM.

Section 6 Pager 14
1.8 64 QAM modulation and number of available HS-PDSCH
SF8 SF16 SF32 SF64 SF128 SF256
0 P-CPICH
0 1 P-CCPCH + SCH
0 2 AICH
1 3 PICH
0 4
2 5
S-CCPCH #1
1 6
3 7
8
4 9
HS-SCCH #1
0 2 5 10
HS-SCCH #2
11
1 12
6 E-HICH + E + E-RGCH
13
3 14 E-AGCH
7 15
0 16
8 17
4 18
9
2 19
20
10 21
1 5 22
11 23
HS-PDSCH #15
24
12 25
6 26
13
27
3 14
28
29
7 30
15 31
HS-PDSCH #14
1 HS-PDSCH #13
HS-PDSCH #12
2 HS-PDSCH #11
HS-PDSCH #10
3 HS-PDSCH #9
HS-PDSCH #8
4 HS-PDSCH #7
HS-PDSCH #6
5 HS-PDSCH #5
HS-PDSCH #4
6 HS-PDSCH #3
HS-PDSCH #2
7 HS-PDSCH #1

HSDPA Key AMC
The maximum throughput by using 64QAM modulation is reached when the maximum number of HSPDSCH
codes are available (max throughput obtained with 15 HS-PDSCH).
The maximum number of HS-PDSCH codes can be obtained when the Fair Sharing feature is enabled (up to 15 HS-
PDSCH) but depends also on the codes configuration (number of S-CCPCH, number of HS-SCCH, number of E-
HICH/ERGCH, number of E-AGCH).
The configuration allows to have up to 15 HS-PDSCH codes is with Mono-S-CCPCH, 2 HS-SCCH, 1 E-HICH/E-
RGCH, 1 E-AGCH.
If the number of S-CCPCH or HS-SCCH or E-HICH/E-RGCH or E-AGCH is higher, the maximum number of available
HS-PDSCH codes will be lower than 15 and then the maximum throughput will not be reachable due to code limitation.

Section 6 Pager 15
1.9 Layer 2 Enhancements : flexible RLC and Mac-ehs
UA 0
7
RLC SDU User payload
RLC PDU
(flexible size)
MAC- d PDU MAC-d PDU 1 MAC-d PDU 2 MAC-d PDU 3

(=MAC-ehs SDU)
Reordering SDU2
MAC-ehs
Pad-
MAC-ehs header
MAC-ehs
header
Reordering SDU2 1
ReorderingSDU header ……
PDU
Reordering PDU Reordering PDU

HSDPA Key AMC
The UA7.0 feature ‘34388 Layer 2 Enhancements : flexible RLC and Mac-ehs’ allows to support the high HS-DSCH
data rate offered by Rel7 UEs (category 13, 14, 15, 16,17, 18).
It overcomes the RLC window blocking issues (thanks to bigger PDUs ) and the UE processing limits (RLC
reassembly) (less PDU to reassemble).
The protocols involved in this feature are
• the Mac-ehs (at Nodeb), the RLC (at RNC and UE sides)
• and the IUB Frame Protocol (at RNC and Nodeb).
MAC-ehs: enhanced MAC-hs layer. MAC-ehs brings the possibility to handle MAC-d PDU of variable size,
to multiplex MAC-d PDU from different priority queues in the same MAC-ehs PDU (not used in this release)
and to segment MAC-d PDUs over multiple MAC-ehs PDUs (and hence minimize padding at MAC-ehs level).
A MAC-ehs PDU is composed of one or several reordering PDU, where:
• Reordering PDU is a set of reordering SDUs belonging to the same priority queue
• Reordering SDU is a complete MAC-d PDU (ie. MAC-ehs SDU) or a segmented MAC-d PDU
In this release, a MAC-ehs PDU is composed of only one reordering PDU.
MAC-ehs supports up to 26 MAC-d PDUs per MAC-ehs frame.
Flexible RLC: instead of using fixed RLC PDU sizes (320 bits or 640 bits), the size of a RLC PDU can vary up to a
maximum size (internal to the RNC) which is determined based on the data rate offered over the radio.
When a call is configured with MAC-ehs, each RLC AM entity may operate in either fixed size mode (pre-Rel7) or
flexible size mode (Rel7).
With RLC flexible mode, the SRNC may determine the size of the RLC PDU independently of the other RLC PDU,
respecting a maximum PDU size (which can be up to 1500 bytes, i.e. a complete SDU. 1500 bytes is the maximum size
of an IP packet, as defined by the IP protocol). It permits to use big PDU sizes, thus avoiding RLC blocking situations. It
also permits to avoid adding padding to the data to fit the PDU size.

Section 6 Pager 16
1.10 Fixed RLC and Mac-hs Overview
RLC PDU (fixed size) Pad. (1)
MAC-d PDU
MAC-hs
MAC-hs PDU header MAC-hs SDU Pad. (2)
Transport Block Size (based on TRFC selection) (3)

HSDPA Key AMC
Fixed RLC and Mac-hs has the following :

(1) The RLC SDU segmentation into fixed size RLC PDUs may lead to padding in RLC PDU
(2) The Transport Block Size is the result of the TRFC selection algorithm. A non negligible number of
padding bits may be required to fit the Transport Block Size.
(3) In case of very bad radio condition, the selected Transport Block Size may be too small to contain a
fixed-size MAC-d PDU: the UE is not scheduled

Section 6 Pager 17
1.11 Layer 2 Enhancements : flexible RLC and Mac-ehs
UA 0
7
RLC PDU
(flexible size)
MAC- d PDU MAC-d PDU 1 MAC-d PDU 2 MAC-d PDU 3

(=MAC-ehs SDU)
Reordering SDU2
MAC-ehs
Pad-
MAC-ehs header
header ReorderingSDU 1 MAC-ehs ……
PDU header
Reordering PDU Reordering PDU

HSDPA Key AMC
The benefit of the flexible RLC and MAC-ehs are:

(1) No need for padding as RLC PDU size can be adjusted to fit exactly the size of the RLC SDU
(2) Padding bits are reduced as MAC-ehs can segment a MAC-d PDU in case it cannot fit into the selected
Transport Block
(3) Even if very bad radio conditions when the MAC-ehs transport block cannot fit an RLC PDU, a UE can
be scheduled thanks to segmentation at MAC-ehs level

Section 6 Pager 18
2 UE Categorization

HSDPA Key AMC

Section 6 Pager 19
2 UE Categorization
2.1 UE Categories
HS-DSCH Category HS-PDSCH Max Number Inter-TTI Min Interval Modulation Max Peak Rate
Category 1 5 3 QPSK & 16-QAM 1.2 Mbps
Category 11 5 2 QPSK only 0.9 Mbps
• QPSK mandatory for HSDPA capable UE

• 16-QAM optional

HSDPA Key AMC
Twelve categories have been specified by Release 5 for HSDPA UEs according to the value of several
parameters among which are the following:
Maximum number of HS-DSCH codes that the UE can simultaneously receive (5, 10 or 15).
Minimum inter-TTI interval, which defines the minimum time between the beginning of two
consecutive transmissions to this UE. If the inter-TTI interval is one, this means that the UE can
receive HS-DSCH packets during consecutive TTIs, i.e. every 2 ms. If the inter-TTI interval is two, the
scheduler needs to skip one TTI between consecutive transmissions to this UE.
Supported modulations (QPSK only or both QPSK and 16QAM),
Maximum peak data rates at the physical layer (number of HS-DSCH codes x number of bits per HS-
DSCH / Inter-TTI interval).
These twelve categories provide a much more coherent set of capabilities as compared to R99 which
gives UE manufacturers freedom to use completely atypical combinations.

Section 6 Pager 20
2 UE Categorization
2.2 New HSDPA UE Categories
HS-DSCH Category HS-PDSCH Max Number Inter-TTI Min Modulation Max Peak Rate
Interval Air interface
throughput
: : : : :
Category 13 15 2 QPSK,16QAM, 21.6 Mbps

64QAM

64QAM

64QAM,MIMO

64QAM,MIMO
Category 19 - - - -
Category 20 - - - -

HSDPA Key AMC
New UE category have been introduced in order to support the 64QAM modulation:
· Category UE 13 and 14 are supported (64 –QAM capable )
· Category 17 and 18 ( 64-QAM and MIMO capable).
Since MIMO is not supported in UA7, UE category 17 and 18 are handled respectively as category 13 and
14. These UE categories are MAC-ehs capable.
The theoretical peak data rate with 64-QAM is therefore 15 codes x 2880 bits / 2 ms = 21,6Mbit/s
(physical channel bit rate), which have to be compared to the 14,4Mbit/s peak rate available with
16-QAM.

Section 6 Pager 21
2 UE Categorization
2.3 UE Capabilities and Max Bit Rates
Category 6 UE CQI Mapping Table
CQI Value HS-PDSCH Number RLC Throughput Modulation
0 out of range
1 1 0 kbps QPSK
S oft CQI vs C/I - P edes trian_a 1 RX
2 1 0 kbps QPSK 25
3 1 0 kbps QPSK
4 1 0 kbps QPSK
5 1 144 kbps QPSK
6 1 144 kbps QPSK
20
7 2 144 kbps QPSK
8 2 288 kbps QPSK
s oftCQI
9 2 288 kbps QPSK
10 3 432 kbps QPSK
11 3 576 kbps QPSK 15
12 3 720 kbps QPSK
13 4 864 kbps QPSK
14 4 1008 kbps QPSK
15 5 1296 kbps QPSK
10
16 5 1440 kbps 16-QAM -10 -8 -6 -4 -2 0 2 4 6 8 10
C/I (dB)
... ... ... ...
29 5 3024 kbps 16-QAM
30 5 3024 kbps 16-QAM
Target BLER ≤ 10%

HSDPA Key AMC
The maximum achievable data rate depends on the UE category but also on the instantaneous radio
conditions it is exposed to. Each UE category has therefore a reference table specifying the supported
combinations between the reported CQI values, the number of codes and the radio modulation
(QPSK/16-QAM/64-QAM).
Instantaneous radio channel conditions are known at the UTRAN level thanks to the periodical decoding
of the Channel Quality Indicator sent by the UE to the NodeB onto the HS-DPCCH. The UE first
estimates the Carrier over Interference ratio (C/I). From this estimate the UE then determines a CQI
(with a maximum HS-DSCH BLER target of 10%) and then it sends this indication back to the NodeB. The
NodeB takes this input into consideration in order to adapt the throughput to the UE.
Note: a UE reporting a CQI value of 0 is not scheduled by the NodeB.

Section 6 Pager 22
2 UE Categorization
2.4 New CQI mapping

HSDPA Key AMC
New 64QAM modulation allows bigger Transport Blocks (TB) than before and hence a new TB size table is
introduced allowing TB size of up to 42192 bits (21.1 Mb/s @ mac-hs).
A new CQI mapping tables F, G, H have been defined for 64-QAM and MIMO. They are used to
translate the CQI value into a reccomended maximum TB size and Modulation scheme.

Section 6 Pager 23
2 UE Categorization
2.5 New CQI mapping – table F
CQI mapping table F.

HSDPA Key AMC

Section 6 Pager 24
2 UE Categorization
2.6 New CQI mapping – table G
CQI mapping table G

HSDPA Key AMC

Section 6 Pager 25

for this module

HSDPA Key AMC

Section 6 Pager 26
End of Module

HSDPA Key AMC

Section 6 Pager 27
7
Section 7
HSDPA Protocol
9300 WCDMA

Section 7 Pager 1
Blank Page

HSDPA Protocol
Document History

Section 7 Pager 2
Objectives

Describe new MAC architecture and data flows
List the HSDPA coding chains main steps

HSDPA Protocol

Section 7 Pager 3
Objectives [cont.]

HSDPA Protocol

Section 7 Pager 4
Table of Contents
Page
1 HSDPA Distributed Architecture 7
1.1 HSDPA Protocol Stack 8
1.2 HSDPA Layer2/Layer1 Flows 9
2 TFRC Selection and channel coding 10
2.1 MAC-hs Architecture (UTRAN side) 11
2.2 HS-DSCH Coding Chain 12
2.3 HS-SCCH Coding Chain 13

HSDPA Protocol

Section 7 Pager 5

HSDPA Protocol This page is left blank intentionally

Section 7 Pager 6
1 HSDPA Distributed Architecture

HSDPA Protocol

Section 7 Pager 7
1.1 HSDPA Protocol Stack
HS-PDSCH HS-SCCH
Data Transfer (PS I/B) Downlink Transfer Information
(UEid, OVSF,...)
Introduction of MAC-hs
RNC
Iub
HS-DPCCH
DPCH Feedback Information
Upper Layer Signaling (CQI, ACK/NACK)
New Transport Channel

New Frame Protocol
HS-DSCH
HS-DSCH
RLC RLC
MAC-d MAC-d
HS-DSCH Flow control HS-DSCH Flow control HS-DSCH
MAC-hs MAC-hs FP FP FP
L2 L2 L2
PHY Uu PHY L1 Iub L1 Iur L1
UE NodeB C-RNC S-RNC
HSDPA Protocol
HSDPA is an increment on UTRAN procedures, and it is fully compatible with R4 layer 1 and layer 2. It is
based on the introduction of a new MAC entity (MAC-hs) in the NodeB, that is in charge of scheduling /
repeating the data on a new physical channel (HS-DSCH) shared between all users.
This has a minor impact on network architecture, there is no impact on RLC protocol and HSDPA is
compatible with all transport options (AAL2 and IP).
On NodeB side, MAC-hs layer provides the following functionalities:

Fast repetition layer handled by HARQ processes.
Adaptive Modulation and Coding.
New transport channel High Speed Downlink Shared Channel (HS-DSCH)
Flow control procedure to manage NodeB buffering.
Some L1 new functionalities are introduced compared to R4:

3 new physical channels: High Speed Physical Downlink Shared CHannel (HS-PDSCH) to send DL
data, High Speed Shared Control CHannel (HS-SCCH) to send DL control information relative to HS-
PDSCH, and High Speed Dedicated Physical Control CHannel (HS-DPCCH) to receive UL control
information.
New channel coding chain for High Speed Downlink Shared CHannel (HS-DSCH) transport channel
and HS-SCCH physical channel.

Section 7 Pager 8
1.2 HSDPA Layer2/Layer1 Flows
RRC
RRC(RNC)
(RNC)
RLC
RLC(RNC)
(RNC)
MAC Control PCCH BCCH CCCH CTCH MAC Control MAC Control DCCH DTCH DTCH
MAC-hs
MAC-hs MAC-d
(NodeB)
(NodeB) (S-RNC)
MAC-c/sh
MAC-c/sh
(C-RNC)
(C-RNC)
Associated Associated
Downlink HS-DSCH Uplink PCH FACH RACH DCH DCH
Signaling Signaling
R5
R5L1:
L1:HSDPA
HSDPA(NodeB)
(NodeB) R4
R4L1:
L1:Channel
ChannelCoding
Coding/ /Multiplexing
Multiplexing(NodeB)
(NodeB)
HS-SCCH HS-PDSCH HS-DPCCH S-CCPCH S-CCPCH PRACH DPCH DPDCH/DPCCH

HSDPA Protocol
In terms of flow multiplexing, the 3GPP specifications allow 3 types of multiplexing:

Multiplexing at the logical channel level, meaning that several logical flows from a given user may
be multiplexed over the same MAC-d entity.
Multiplexing at the MAC-c/sh level, meaning that several MAC-d flows, either from the same or
from different users, may be multiplexed over the same MAC-hs entity.
Multiplexing at the MAC-hs level, which receives all the MAC-d flows and sub-flows.
In UA04.2 only one single DTCH is supported over HSDPA (as the DCCH is supported over the associated
DCH, and this version of HSDPA does not support multiple PS RAB for a single user).

Section 7 Pager 9
2 TFRC Selection and channel coding

HSDPA Protocol

Section 7 Pager 10
2.1 MAC-hs Architecture (UTRAN side)
to MAC-d
MAC-d flows
Example:
MAC-hs
TFRC Fields Value
Transport Block Size 2677 bits
Flow Control
# codes 4
Modulation QPSK
Min. HARQ buffer size 8103 bits
Scheduler
# MAC-d PDUs 4
Total Tx Power 21.5 mW
Power per code 5.4 mW
HARQ TTI 2 ms
TFRC Selection
Associated HS-DSCH Associated

Downlink Signaling Uplink Signaling

HSDPA Protocol
HSDPA induces an improvement of both the global throughput and the peak data rates per user and
reduces the DL packet transmission delay mainly due to the introduction of a fast repetition layer at the
NodeB characterized by:
a new MAC entity (the MAC-hs) located in the NodeB. It manages the scheduling of users and the
retransmissions of packets.
a new transport channel, the HS-DSCH, whose transmission is based on shorter sub-frames: 2ms
(TTI).
a retransmission protocol, the HARQ (Hybrid Automatic Repeat Query) that handles fast
repetitions of erroneous blocks (with possibly a change of the rate matching parameters that
increases the global coding rate).
a mechanism that adapts data format to radio conditions, the Adaptive Modulation and Coding
(AMC), with the possibility of choosing between two modulations (QPSK and 16QAM).
Refer to Appendix for more details about MAC-hs PDU construction

Section 7 Pager 11
2.2 HS-DSCH Coding Chain
CRC attachment
Bit Scrambling
Code Block Segmentation R99 Functionality
Turbo Coding
R99 Modified Functionality

HARQ Entity
Physical Channel Segmentation

New Functionality
HS-DSCH Interleaving
Constellation Rearrangement (16QAM)
Physical Channel Mapping

HSDPA Protocol
Some coding steps are identical to the R4 functionalities applied to DCH:

CRC attachment: 24 bits CRC length,
Code Block segmentation,
Channel coding: Turbo Code 1/3,
Physical channel segmentation,
HS-DSCH interleaving: R99 second interleaving (for 16QAM it is applied twice),
Physical channel mapping.
One step has been strongly modified: the HARQ functionality. It is a two-stage Rate Matching:
The first stage corresponds to the R4 rate matching, except that it matches the input bits to a
virtual buffer size instead of matching them to the number of physical channel bits (that’s the
purpose of the second stage).
The second stage keeps the same structure than the R4 rate matching but the computation of the
initial parameters is different and systematic bits may be punctured. The initial parameters are
determined by the RV parameters.
Two brand new functions are introduced:

Bit scrambling
Constellation rearrangement only applied in case of 16QAM.

Section 7 Pager 12
2.3 HS-SCCH Coding Chain
s, r, b
OVSF Code Set Modulation Scheme TBS HARQ RV Coding NDI
MUX MUX
CRC
CC 1/3 UEId UE Masking
Rate Matching CC 1/3 MUX
Puncturing CC 1/3
UE Masking Rate Matching
Slot #0: Code Set, Modulation Slot #1: TBS, HARQ Slot#2: RV, NDI
TSUBFRAME = 2ms
HSDPA Protocol
The HS-SCCH is coded in two parts:

the first part corresponds to the first slot and indicates the Transport Format and Resource
Indicator (TFRI) i.e. the HS-PDSCH codes the UE must demodulate, and the modulation used
(0:QPSK, 1:16QAM)
the second part corresponds to the two last slots and indicates the transport block size (TBS), the
RV parameters, the HARQ process index and the New Data Indicator (value updated for each new
Transport Block transmission).
Input bits of the first part are also injected for CRC computation.
On the two parts, the UEId (H-RNTI provided by the RNC) is applied as a mask. The coding chain is given
in the above figure.

Section 7 Pager 13
Summary

HSDPA Protocol

Section 7 Pager 14

for this module

HSDPA Protocol

Section 7 Pager 15
End of Module

HSDPA Protocol

Section 7 Pager 16
8
Section 8
HSDPA Scenario
9300 WCDMA

Section 8 Pager 1
Blank Page

HSDPA Scenario
Document History

Section 8 Pager 2
Objectives

Describe main procedures associated with
HSDPA call establishment and mobility.

HSDPA Scenario

Section 8 Pager 3
Objectives [cont.]

HSDPA Scenario

Section 8 Pager 4
Table of Contents
Page
1 Call Setup 7
1.1 Call Establishment 8
1.2 Initial Connection Establishment 10
1.3 RAB Assignment Phase 11
2 Mobility 12
2.1 Intra-Frequency Mobility 13
2.3 Inter-frequency HSDPA HHO with Measurements 15
3 Iub Flow Control 16
3.1 Flow Control Principles 17
3.2 HS-DSCH Capacity Allocation 18

HSDPA Scenario

Section 8 Pager 5

HSDPA Scenario This page is left blank intentionally

Section 8 Pager 6
1 Call Setup

HSDPA Scenario

Section 8 Pager 7
1 Call Setup
1.1 Call Establishment
How is HSDPA triggered by the network?
3. DCH ? HS-DSCH ?
Channel Type Selection
1. Request for service
(e.g. Web Browsing)
RNC
Node B Core
Network
2. RAB
Assignment
UE 4. HS-DSCH Request
Establishment

HSDPA Scenario

Section 8 Pager 8
HS-DSCH or
DCH ?
RAB assignment
request from CN
RAB Traffic Class Service = PS?
Traffic Class =
Streaming/
I/B
HS-DSCH
selection
UE Capabilities HSDPA UE?
Cell Capability
Primary Cell =
HSDPA Cell?

HSDPA Scenario
With the introduction of HSDPA in the UTRAN, a new type of transport channel can be allocated to serve
the RAB requested from the CN. Thus, the channel type selection algorithm allows selecting either DCH
or HS-DSCH depending on the RAB characteristics received from the CN.
At reception of a “RAB assignment Request”, the SRNC selects the transport channel type between DCH
and HS-DSCH according to the following constraints:
RAB traffic class

PS RABs with traffic class “interactive” and “background” are transported on HS-DSCH. In UA06
Alcatel-Lucent supports the “Streaming” traffic class over HSDPA and from UA07 Alcatel-Lucent
supports the “Streaming” traffic class over HSUPA.
RAB combinations from UA07
PS Str. + PS I/B over HSUPA/HSDPA
CS speech over DCH + PS Str. + PS I/B over HSUPA/HSDPA
UE capability to support HS-DSCH
HS-DSCH can be selected only if UE supports it, as indicated by the UE capability “Support of HS-
PDSCH”, and if UE supports the combination of already established DL DCH and HS-DSCH, as
indicated by the UE capability “DL capabilities with simultaneous HS-DSCH configuration”
Cell capability to support HS-DSCH
HS-DSCH can be selected only if one cell of the active set supports HSDPA or if one collocated cell
(on another carrier) supports HSDPA.
Channel type selection is performed prior to radio admission control. Then depending on the channel
type selection, either DCH RAC or HSDPA RAC is triggered.

Section 8 Pager 9
1 Call Setup
1.2 Initial Connection Establishment
UE NodeB RNC SGSN
Establishment Cause
AS Indicator
RRC / RACH / RRC Connection Request
NBAP / RL Setup Request
NBAP / RL Setup Response
SRB Definition (DCCH)

U-RNTI
Target RRC State (Cell_DCH)
RRC / FACH / RRC Connection Setup

HSDPA Capability
UE Category
RRC / RACH / RRC Connection Setup Complete
RRC / DCCH / Initial Direct Transfer (Service Request)
RANAP / Service Request
RRC / DCCH / Measurement Control
… … …

HSDPA Scenario
Most of the steps of this first phase are common to all type of calls. There are few elements specific to
HSDPA.
RRC Connection Request embeds the Establishment Cause and the AS Indicator that may be used for
Traffic Segmentation.
RRC Connection Setup states the properties of the SRB to be used and includes a first Radio Network
Temporary Identifyer (RNTI).
RRC connection Setup Complete indicates to RNC UE capabilities.

Section 8 Pager 10
1 Call Setup
1.3 RAB Assignment Phase
UE NodeB RNC SGSN
… … …
RANAP / RAB Assignment Request
Measurement Power Offset

Scheduler & HARQ properties
NBAP / RL Reconfiguration Prepare MAC-d PDU size
HS-DPCCH properties
NBAP / RL Reconfiguration Ready
NBAP / RL Reconfiguration Commit

HS-SCCH Codes
Number of HARQ
HS-SCCH Codes
HARQ number and properties
H-RNTI
RRC / DCCH / Radio Bearer Setup
Measurement Power Offset
HS-DPCCH properties
RRC / DCCH / Radio Bearer Setup Complete
RANAP / RAB Assignment Response
… … …

HSDPA Scenario
In this second phase only the NBAP Radio Link Reconfiguration procedure and RRC Radio Bearer
Reconfiguration are modified because of HSDPA.

Section 8 Pager 11
2 Mobility

HSDPA Scenario

Section 8 Pager 12
2 Mobility
2.1 Intra-Frequency Mobility
Core Network
Primary cell
change
RNC RNC
NodeB NodeB
HS-DSCH HS-DSCH HS-DSCH

Primary
Transition Mobility Mobility Cell
DCH only
R4 cell HSDPA cell HSDPA cell HSDPA cell
HS-DSCH+DCH
DCH HS-DSCH HS-DSCH

Fallback Mobility Mobility

HSDPA Scenario
As defined by 3GPP HS-DSCH is established in only one cell so is never in soft handover. In Alcatel-Lucent
implementation HS-DSCH is established in the primary cell because it is the best candidate (good radio
conditions and not changing too often).
Each time the primary cell changes the HS-DSCH RL is deleted on the former primary right after the RRC
Measurement Control procedure has been performed, and it is re-established under the new primary,
using a synchronous reconfiguration.
If the new primary cell does not support HSDPA then the RB is reconfigured to DCH (iRM CAC is
performed). If the new primary cell supports HSDPA while the former did not, and given that the UE
supports HSDPA, then the RB is reconfigured to HS-DSCH (HSDPA CAC is performed).

Section 8 Pager 13
HS-DSCH Primary Cell Change
RNC source Node target Node UE

B B
Primary cell
change
RL Reconfiguration Prepare
RL Reconfiguration Ready
RL Reconfiguration Commit (Activation CFN)
RL Reconfiguration Commit (Activation

CFN)
RB Reconfiguration (Activation CFN)
Measurement Control (new neighbouring list)

Activation CFN
RB Reconfiguration Complete

HSDPA Scenario
As defined by 3GPP HS-DSCH is established in only one cell so is never in soft handover. In Alcatel-Lucent
implementation HS-DSCH is established in the primary cell because it is the best candidate (good radio
conditions and not changing too often).
Each time the primary cell changes, the HS-DSCH RL is deleted on the former primary and it is
reestablished under the new primary, using a synchronous reconfiguration. During the reconfiguration
data transfer on HS-DSCH is suspended by the RNC.
If it is not possible to re-establish HS-DSCH on the new primary (CAC failure) then the radio bearer may
fall back to DCH.
If the new primary cell does not support HSDPA then the RB is reconfigured to DCH (iRM CAC is
performed). In case of CAC failure for the DCH then the PS RAB is released.
If the new primary cell supports HSDPA while the former did not and given the UE supports HSDPA, then
the RB is reconfigured to HS-DSCH. In case of CAC failure the radio bearer stays on DCH.
In the case the current primary cell is not present in the new active set, the HS-DSCH link is deleted right
after the Active Set procedure (and before the Measurement Control procedure) and the UE releases the
HSDPA link. A new HS-DSCH link is then setup using a normal SRLR procedure on the new primary cell
after the Measurement Control.

Section 8 Pager 14
2 Mobility
2.3 Inter-frequency HSDPA HHO with Measurements
Core Network
SRNC
HSDPA cell – Frequency 2
R99 cell
Frequency 1

HSDPA Scenario
The HSDPA Inter-freq mobility (HHO) with measurements (i.e. Compressed Mode on associated DCH) is
supported with UA05.
The feature values are to Enable HSDPA call handover to another cell based on criteria thresholds,
avoiding drop calls and to allow HSDPA mobiles entering an HSDPA cell through an alarm handover to
benefit from HSDPA service.
UE solution supporting the Compressed Mode on DCH once in HSDPA operation (i.e. HS-PDSCH(s) usage).

Section 8 Pager 15
3 Iub Flow Control

HSDPA Scenario

Section 8 Pager 16
3 Iub Flow Control
3.1 Flow Control Principles
RNC
Capacity Request Capacity Allocation
Data FP
Control FP Iub Control FP
RNC Buffers
QId0 QId1 QId2 QIdN QId0 QId1 QId2 QIdN
NodeB Buffers

HSDPA Scenario
With HSDPA, the effective throughput per UE is not deterministic and quite variable. A flow control
mechanism has been introduced between the RNC Mac-d and the NodeB MAC-hs entities in order to fill
the NodeB buffers with sufficient data to provide to the UEs and be quite reactive to throughput
variations.
This flow control mechanism is based on three main procedures:
the Capacity Request procedure that provides means for the RNC to indicate for each session of
each UE its buffer occupancy (at MAC-d level).
the Capacity Allocation procedure generated by the NodeB to indicate to the RNC how many PDUs
are required for the desired session and the interval in which data should be sent. This is based on
the estimated throughput for this session and the amount of unsent data in NodeB transmission
buffers.
the HS-DSCH data transfer procedure in which the RNC sends the MAC-d PDUs grouped in FP frames
(1 to 255 PDUs per FP frame). The updated buffer occupancy is also given. The RNC may choose to
send all the required MAC-d PDUs in a single FP frame, or to space out (within the notified interval)
the transmission in several FPs.

Section 8 Pager 17
3.1 Flow Control Principles
3.2 HS-DSCH Capacity Allocation
UE Node B Serving
RNC
7. HS-DSCH Capacity Request
HS-DSCH FP HS-DSCH FP
Priority Indicator, UE buffer Size
8. HS-DSCH Capacity Allocation

HS-DSCH FP HS-DSCH FP
HS-DSCH credits, inter-TTI interval, …
9. Data Transfer
10. HS-SCCH
After HS-DSCH
MAC-hs MAC-hs
Configuration
11. Data Transfer
NB.: The UE is in cell_DCH state

HSDPA Scenario
As soon as the SRNC detects the necessity to send HS-DL data on one HS-DSCH, it sends an HS-DSCH
Capacity Request control frame within the HS-DSCH Frame Protocol to the CRNC.
Parameters: Common Transport Channel Priority Indicator and User Buffer Size.
The CRNC forwards this message (HS-DSCH Capacity Request control frame) to the Node B. So in this
example sequence, the CRNC does not interfere with the HS-DSCH scheduling.
Parameters: Common Transport Channel Priority Indicator and User Buffer Size.
The Node B determines the amount of data (credits) that can be transmitted on the HS-DSCH and reports
this information back to the DRNC in a HS-DSCH Capacity Allocation control frame in the HS-DSCH
Frame Protocol.
Parameters: Common Transport Channel Priority Indicator, HS-DSCH Credits, HS-DSCH Interval, HS-
DSCH Repetition period, Maximum MAC-d PDU length.
The DRNC sends the HS-DSCH Capacity Allocation control frame to SRNC. So again, the DRNC does not
react itself to that message in this example.
Parameters: Common Transport Channel Priority Indicator, HS-DSCH Credits, HS-DSCH Interval, HS-
DSCH Repetition period, Maximum MAC-d PDU length.
The SRNC starts sending DL data to the Node B. This is done via the two HS-DSCH Frame Protocol "hops"
on Iur and Iub interface. The Node B schedules the DL transmission of DL data on HS-DSCH which
includes allocation of PDSCH resources.
The Node B transmits the control information for the concerned UE using the HS-SCCH.
The Node B sends the HS-DSCH data to the UE on the HS-PDSCH(s).

Section 8 Pager 18
Summary

HSDPA Scenario

Section 8 Pager 19

for this module

HSDPA Scenario

Section 8 Pager 20
End of Module

HSDPA Scenario

Section 8 Pager 21
9
Section 9
HSDPA AL Implementation
9300 WCDMA

Section 9 Pager 1
Blank Page

Document History

Section 9 Pager 2
Objectives

Compare HSDPA deployment options
Evaluate HSDPA introduction impacts on
UTRAN configuration


Section 9 Pager 3
Objectives [cont.]


Section 9 Pager 4
Table of Contents
Page
1 Deployment Scenarios 7
1.1 Cell Topology 8
2 Configuration Impacts 9
2.1 UTRAN HW Readiness 10
2.2 Scalable BTS Configuration 11
2.3 BTS Configurations Examples 12
2.4 Multi-mode BBU with xCEM 13
2.5 Interface Configuration with ATM 14
2.6 Smooth Evolution to IP 15
2.7 Core Network Impacts ATM configuration 16
2.8 Core Network Impacts Iu-PS interface over Ethernet 17


Section 9 Pager 5

HSDPA AL Implementation This page is left blank intentionally

Section 9 Pager 6
1 Deployment Scenarios


Section 9 Pager 7
1 Deployment Scenarios
1.1 Cell Topology
Coverage Options
HSDPA on shared carrier
R99 only cell

HSDPA cell
R99/HSDPA cell
HSDPA on dedicated carrier
HSDPA on two carriers

HSDPA cells are not restricted to HSDPA services, they also offer all R99 services so there is no need to
handover to the R99 layer to establish these services.
Several deployment configurations are possible depending on the number of carriers and on the choice
between dedicated carrier or shared carrier.
Mono-frequency deployment with shared carrier leads to smooth transitioning from R99 only networks to
HSDPA capable networks at minimum costs.
Dual carrier networks with dedicated carriers for R99 offers the possibility to have independent
management of the two types of traffic, providing more flexibility in terms of resource allocation,
interference and capacity.
Extra HSDPA capacity can be provided mixing dedicated and shared carrier cells inside a two-layered
network.
Some HSDPA hot-spots can also be introduced in single-carrier or dual-carrier networks.

Section 9 Pager 8
2 Configuration Impacts


Section 9 Pager 9
2.1 UTRAN HW Readiness
PA
HSD DY
REA RNC
HSDPA PA
L1 HSD DY
CP L2 (MAC-hs)
BTS REA
RNSAP
NBAP iCEM
RANAP .
.
MCPA DDM
UL . iTRM
RRC
DPDCH iCEM
.
DPCCH .
.
iCCM iTRM MCPA DDM
DL iCEM
DPDCH/DPCCH . iTRM
.
UP . MCPA DDM
α
CEMα DIGITAL SHELF RF BLOCK
RLC
MAC
product parts or modules handling HSDPA

There are no UTRAN HW impacts triggered by the introduction of HSDPA, the evolution is managed via SW
upgrade only.
From an RNC point of view, all functionalities on both the CN and IN are exactly the same. There is just
an evolution of the procedures and associated messaging protocols (NBAP, RRC...).
From a BTSEquipment perspective, at the Layer 1 level, all functionalities on both the CCM and TRM
boards (including the MCPA) are exactly the same. Only the introduction of the 16QAM modulation could
have induced some impacts on the iCEM board but this constellation is generated as two QPSK
modulations of different amplitudes. Consequently there are no HW impacts on the iCEM board as well.

Section 9 Pager 10
2.2 Scalable BTS Configuration
UL MAC-hs
HS-DPCCH • HARQ
DL • Scheduler
HS-PDSCH • Link Adaptation (AMC)
PA
HS-SCCH
HSD DY
BTS REA
H-BBU
iCEM128
H-BBU
iTRM MCPA DDM
H-BBU
iCEM128
D-BBU
UL H-BBU MCPA DDM

Associated/R4 DPDCH
iCEM64 iCCM iTRM
Associated/R4 DPCCH
D-BBU
iCEM64
DL MCPA DDM
Associated/R4 DPCH
cmCHs D-BBU iTRM
α
CEMα
D-BBU
DIGITAL SHELF RF BLOCK
H-BBU HSDPA dedicated
D-BBU DCH/cmCH dedicated

The HSDPA support on UMTS BTS requires Alcatel-Lucent second generation of CEM i.e. iCEM64 or
iCEM128. Alcatel-Lucent CEM Alpha is not HSDPA hardware ready.
Nevertheless, HSDPA support on Alcatel-Lucent UMTS BTS is possible assuming already installed CEM
Alpha modules. CEM Alpha and iCEM modules can coexist within the NodeB digital shelf while providing
HSDPA service with Alcatel-Lucent UMTS BTS.
Base Band processing is performed by BBUs of CEM and iCEM. One restriction of current BBUs is that one
BBU cannot process both Dedicated and HSDPA services. In order for the BTS to be able to manage both
dedicated and HSDPA services, the BTS has to specialize BBUs as:
D-BBU: BBU managing dedicated services,
H-BBU: BBU managing HSDPA services.
The partition between H-BBU and D-BBU is done by the BTS at BTS startup using OMC-B configuration
information. Once this allocation is done, it can only change after a BTS-iCCM reset or an iCEM plug-in or
plug-out.

Section 9 Pager 11
2.3 BTS Configurations Examples
iCEM128 D-BBU cell#0
D-BBU
MCPA DDM
cell#3
iTRM STSR2
cell#1
H-BBU
cell#0
3 cells/H-BBU
iCEM64 cell#1 iCCM MCPA DDM
cell#2 cell#4 F1 HSDPA cells
iTRM
F2 R99/HSDPA cells
H-BBU cell#2
cell#0
iCEM64 cell#1 MCPA DDM
cell#2 cell#5
H-BBU
iCEM128 cell#0 cell#0
H-BBU MCPA DDM
cell#1 cell#3
iTRM STSR2
H-BBU cell#1
cell#2 1 cell/H-BBU
iCEM128 iCCM MCPA DDM
D-BBU cell#4 F1 HSDPA cells
iTRM F2 R99 cells
D-BBU cell#2
α
CEMα
D-BBU MCPA DDM
cell#5

HSDPA is supported on STSR-1 and STSR-2 configurations (HSDPA can be deployed on one frequency or on
two frequencies), OTSR configuration is not supported with HSDPA.
The above figures present two different BTS configurations among the wide range of possible
combinations. The first case represents a STSR2 with a multi-cell per H-BBU case, while the second figure
illustrates a STSR2 configuration with one cell per H-BBU.

Section 9 Pager 12
2.4 Multi-mode BBU with xCEM
WARNING
256 CE for DCH

With a max of 128 CE
for sig.
Example: if 64 DCH
Nb CE = 256 – 64
=192 CE for HSDPA
Limited before
in the previous release

This feature introduces support for multi-mode Base-band Units (BBU) on the xCEM module.
Multi-mode is understood as support of DCH + HSDPA + HSUPA channel types by the same BBU.
This includes support of channel combinations {HSD+HSU}, {DCH+HSD}, {DCH+HSU}, and
{DCH+HSD+HSU} for a given user.
Multi-mode support includes the change from triple to single decoding.
The xCEM board supports 256 DCH, with any 128 of them supporting HSDPA and/or HSUPA.
This means that the initial xCEM capacity will be doubled with this feature by means of a SW upgrade.
The additionally available capacity can be activated through the Capacity Licensing mechanism and
requires purchase of respective licenses.

Section 9 Pager 13
2.5 Interface Configuration with ATM
INVccGroup
VCC OAM VPi/VCi
VCC NodeBCP VPi/VCi

VCC CCP VPi/VCi
RNC
VCC DS traffic VPi/VCi/PathId/QoSId
VCC NDS traffic VPi/VCi/PathId/QoSId

VCC HSDPA traffic VPi/VCi/PathId/QoSId
OAM DS
CP NDS
CCP HSDPA • New VCC
• New ATM Profile PCM link (1 up to 8 with IMA)
AAL5 AAL2
• New QoSId
ATM
PCM

As HSDPA is a system evolution limited to UTRAN, HSDPA activation have no impact beyond the RNC.
As HSDPA is not supported over Iur interface, the only interface modifications are related to Iub.
HSDPA activation does not impact UTRAN interfaces Control Plane configuration. As mentioned earlier
there is just a moderate evolution of the NBAP messaging. Evolution of RRC messaging does not impact
the interface configuration needs for DS VCC.
In fact the major evolution triggered by HSDPA introduction is the definition of a new type of VCC
dedicated to HS-DSCH operation.
There is just one HSDPA VCC per Iub, the configuration of this new VCC requires the definition of a
dedicated ATM Profile together with the introduction of a new AAL2 QoS.
The support of IMA with multi-PCM is necessary in order to be able to provide high user data rates,
otherwise this may constitute the first bottleneck. Up to 8 PCM links can be managed by a single NodeB.

Section 9 Pager 14
2.6 Smooth Evolution to IP
UA06 : Optimized HSPA Offload – UA07 : Native IP for Iub

Hybrid Iub
RNC RNC
IMA = nE1
R99 over ATM
E1 Leased Lines
STM1
x x
C
C Ethernet STM
C
C
Ethernet Ethernet Network with
M M Packet Sync.
HSPA over IP GigE
Low Cost Backhaul
Node B GigE Node B
SGW

HYBRID IUB introduces a hybrid transport (ATM & IP) on the Iub interface on the RNC & Node B, as shown in
Figure above. This functionality enables the operator to split delay sensitive traffic from non delay
sensitive traffic. R99 traffic is carried on E1 to secure voice transportation as well as all delay sensitive
traffic, whereas non-delay sensitive traffic is carried on IP over a private IP network.
In the hybrid Iub interface the R99, signaling and OAM traffic remains on the ATM/PCM and the HSPA
(HSDPA and E-DCH) is supported on IP/Ethernet. Hybrid Iub requires 100 BaseT Ethernet port (xCCM) in
the NodeB and a Gigabit Ethernet board on the RNC side.
All IP is introduced in UA07.

Section 9 Pager 15
2.7 Core Network Impacts ATM configuration
HLR Gr
new modified
parameters messaging
GGSN Gn
SGSN Iu-PS
RNC
VCC Streaming
RNC SGSN
VCC Interactive
HSDPA R99 & « HSDPA »
PA
specific HSD DY
REA
procedures VCC Background
R99 & « HSDPA »
PA
HSD DY VCC Conversational
REA

HSDPA is a UTRAN only feature and the changes triggered by HSDPA introduction stop at the RNC. Beyond
the RNC there is no R4 / HSDPA differentiation.
HSDPA does not introduce any new procedure into the core network. There are just some changes in the
QoS profiles and some new parameters introduced in the messaging.
On Iu traffic is mapped on different VCCs depending on Traffic Class (Conversational, Streaming,
Interactive or Background). R4 and HSDPA traffic with the same Traffic Class are mapped on the same
VCC. There is no specific HSDPA VCC on Iu.
HSDPA is expected to increase user traffic, which results in a higher throughput to be supported by the
SGSN and the GGSN. Depending on the call profile, more traffic processing modules may be necessary.
Dimensioning follows the same rules as for R4 traffic.

Section 9 Pager 16
2.8 Core Network Impacts Iu-PS interface over Ethernet
Iu-PS over ATM Iu-PS over IP/Ethernet

Iu-PS interface is an open interface between the RNC and SGSN for the packet domain.
ATM and IP stacks for Iu-PS are supported.
On this interface, the SCCP supports transport of RANAP messages used by the Control Plane.
ATM stack is like IU-CS interface refer to the description of previous slide.
AAL5/ATM is be used to transport IP packets across the Iu interface towards the packet switched domain.
IP stack uses the M3UA ( MTP-3 User Adaptation Layer) and SCTP ( Stream Control Transmission Protocol) to
transport the signalling on IP network.
UDP/IP is used for the User Plane.
Dynamic management of GTP tunnel is ensured by user plane towards PS domain.
The physical layer is supported by OC3/STM1 and aIP over Gigabit Ethernet.
The Transport Network Control plane is not necessary on IU-PS.

Section 9 Pager 17

for this module


Section 9 Pager 18
End of Module


Section 9 Pager 19
10
Section 10
HSUPA Fund
9300 WCDMA

Section 10 Pager 1
Blank Page

HSUPA Fund
Document History
01 2007-07-16 Scholle, Martin Conversion into Alcatel-Lucent template

Section 10 Pager 2
Objectives
After this section, you will be able to:

Describe the main objectives of the HSUPA solution.
Identify the benefits of the new UL channels for the
existing UMTS networks.
Identify the characteristics of the HSUPA technology.

HSUPA Fund

Section 10 Pager 3
Objectives [cont.]

HSUPA Fund

Section 10 Pager 4
Table of Contents
Page
Introduction
Definition
1 Introduction 7
1.1 Definition 8
Uplink before HSUPA
1.2 Uplink before HSUPA 9
HSUPA Principles
2 HSUPA Principles 10
2.1 Main characteristics
Main characteristics 11
2.2 Radio Resource Allocation 12
Radio Resource
2.3 NodeB level Allocation 13
NodeB
2.4 Main level
Benefits of HSUPA in UL 14
3 Exercise 15
Main Benefits of HSUPA in UL
3.1 Questions 16
Exercise
Questions

HSUPA Fund

Section 10 Pager 5

HSUPA Fund This page is left blank intentionally

Section 10 Pager 6
1 Introduction

HSUPA Fund

Section 10 Pager 7
1 Introduction
1.1 Definition
- resource mgmt
- retransmissions
Uplink Release
Release 66
HS
UP
High A
Throughputs
Dedicated
Channels
Throughput
&
Capacity
HSUPA Fund
HSUPA (High Speed Uplink Packet Access) is the last item introduced by 3GPP with the aim to improve
the Uplink (UL) data rate.
HSUPA is characterized by a high data rate for PS calls over the UL air interface.
The 3GPP objectives are to improve the performance of uplink dedicated transport channels by
scheduling the Uplink UE data rates depending on the interference and on the Node B processing
resources, while increasing the radio interface robustness with the HARQ (Hybrid Automatic Repeat
Request) protocol associated with TTI of 2 ms and 10 ms.
By reaching high spectrum efficiency and low latency for both the uplink and downlink with
HSDPA/HSUPA, wireless operators will be able to provide seamless access services like VoIP, which can
be challenging in UMTS R4 Network.
HSUPA is not only a HSDPA for the reverse link.
Of course, some of the mechanisms are inspired by the HSDPA solution (HARQ process, Incremental
Redundancy, Scheduling) but more generally HSUPA is an enhancement of classical dedicated channels.
Such new UL channels will be called in the following E-DCH channels.
With HSUPA a new set of channels is proposed for UL and DL.

Section 10 Pager 8
1 Introduction
1.2 Uplink before HSUPA
Poor spectral
Low User efficiency
Throughputs
(<384 kbps)
HSDPA UE Node B RNC
Low Number of
High data rate users Low coverage
For high data rate
applications

HSUPA Fund
Before the launch of the HSUPA solution, the operators have expressed their needs regarding the Access
Network capabilities.
Operator needs
Higher coverage for high data rate applications
A limited coverage for the UL DPCH @ 128kbps & 384kbps
Higher number of high data rate users from a cell RF capacity standpoint
NPole formula with 50% UL load, a limited number of high data rate DPCH in UL
Higher user throughput on the Uu interface
UMTS Rel’99 allows UL peak rate @ 384kbps
Most networks have been designed to ensure 64/128kbps
Higher UL spectral efficiency for uneven traffic
As HSDPA in DL, DCH usage in UL for uneven traffic leads to a waste of radio resource
usage.
PS call delay improvement
To face these requirements, the 3GPP had to introduce the E-DCH new channel coupled with HSDPA: the
HSUPA solution.

Section 10 Pager 9
2 HSUPA Principles

HSUPA Fund

Section 10 Pager 10
2 HSUPA Principles
2.1 Main characteristics
HSUPA
E-DCH, an enhanced Dedicated channel
Fast scheduling at Node B level
(TTI: 10ms => mandatory), 2ms =>optional)
Fast retransmission of data
QPSK modulation (~2 BPSK)
Uplink Noise Rise management in nodeB
Uplink resource management in nodeB

HSUPA Fund

Section 10 Pager 11
2 HSUPA Principles
2.2 Radio Resource Allocation
Dedicated Channel
99
T SR
UM Dedicated Channel
Dedicated Channel
D PA
HS
Shared Channel
Enhanced Dedicated Channel

A
UP
HS Enhanced Dedicated Channel
Enhanced Dedicated Channel
Allocated resources
User traffic

HSUPA Fund
The WCDMA system normally carries user data over dedicated transport channels, or DCHs, which brings
maximum system performance with continuous user data. The DCHs are code multiplexed onto one RF
carrier. In the future, user applications are likely to involve the transport of large volumes of data that
will be bursty in nature and require high bit rates.
HSDPA introduces a new transport channel type, High Speed Downlink Shared Channel (HS-DSCH) that
makes efficient use of valuable radio frequency resources and takes into account packet data services
burstiness.
That new transport channel (HS-DSCH) shares multiple access codes, transmission power and use of
infrastructure hardware between several users. The radio network resources can be used efficiently to
serve a large number of users who are accessing bursty data. To illustrate this, when one user has
received a data packet over the network, another user gets access to the resources and so forth. In other
words, several users can be time multiplexed so that during silent periods, the resources are available to
other users.
With HSUPA, the resource is also shared among the HSUPA users but they each have an E-DCH (Enhanced
Dedicated Channel). It uses a share of the uplink resources allocated in real time by the nodeB.

Section 10 Pager 12
2 HSUPA Principles
2.3 NodeB level
Implementation
•Fast retransmission
•Uplink resource management
•received power
•processing resources
•Iub bandwidth
Benefits
•Lower latency
•Increased radio interface robustness
•Overall UL QOS and throughput improvement
•Optimized resource sharing
•Increases more the nb of high data rate users

HSUPA Fund
At nodeB level, we implement fast retransmission, and uplink resource management.
The improvements allowed by this implementation are

lower latency (better network responsiveness)
Increased radio interface robustness, hence higher throughput
Optimized resource sharing (resource allocated only if UEs use them so resources not used by
some users are available for other users)

Section 10 Pager 13
2 HSUPA Principles
2.4 Main Benefits of HSUPA in UL
Bit
rates
UL throughput
Nb high speed users
Operational impacts:
Spectral Same
Efficiency hardware
UL resources
Resource
Sharing
Service Delay Network

Responsiveness

HSUPA Fund
Introduction of new UL channels allowing high bit rate and global quick resources sharing is useful to map
as a first step the best effort UL traffic (i.e. Interactive/Background traffic on E-DCH) keeping for DCH
the UL Conversational/Streaming traffic class.
E-DCH network introduction while being coupled with HSDPA (for which the same basic segmentation has
been done – DL Conversational/Streaming on DCH and DL Interactive/Background on HSDPA) enhances
the spectral efficiency of UMTS technology versus live uneven traffic.
Indeed, E-DCH/HSDPA maximizes the number of high data rate users from an air interface standpoint
while minimizing the UL/DL service delay.
By principle, E-DCH with HSDPA dynamically adapts and maximizes the peak data rate of each subscriber
according to cell load and UTRAN resource availability.

Section 10 Pager 14
3 Exercise

HSUPA Fund

Section 10 Pager 15
3 Exercise
3.1 Questions
What type of transport channel is E-DCH,

introduced with HSUPA? an Enhanced Dedicated Channel
Where are the main modifications NodeB

implemented in the network?
What is managed at that level? Fast retransmissions

(Level = previous answer) Uplink resources
Name 5 benefits of the HSUPA 1. Higher bit rates

technique.(In terms of throughput, 2. Higher number of high bit rate users
UL resources, network 3. Better resource sharing
responsiveness)
4. Higher spectral efficiency
5. Lower service delay

HSUPA Fund

Section 10 Pager 16

for this module

HSUPA Fund

Section 10 Pager 17
End of Module

HSUPA Fund

Section 10 Pager 18
11
Section 11
HSUPA Channel
9300 WCDMA

Section 11 Pager 1
Blank Page

HSUPA Channel
Document History

Section 11 Pager 2
Objectives

Describe the new HSUPA channels that have been
designed to allow high data rate for PS calls over the
UL air interface.

HSUPA Channel

Section 11 Pager 3
Objectives [cont.]

HSUPA Channel

Section 11 Pager 4
Table of Contents
Page
1 Introduction of new channels 7
1.1 HSDPA Channels 8
1.2 HSUPA Channels 9
1.3 Transport Channel 10
1.4 Physical Channels 11
1.5 Channels Roles 12

HSUPA Channel

Section 11 Pager 5

HSUPA Channel This page is left blank intentionally

Section 11 Pager 6
1 Introduction of new channels

HSUPA Channel

Section 11 Pager 7
1.1 HSDPA Channels
Logical DCCH DTCH DTCH

Signaling
Traffic Traffic
SRB
TRB TRB
Mobile x
Mobile x Mobile y
Transport DCH DCH HS-DSCH
DL UL UL DL
Physical DPCCH DPDCH HS-PDSCH

DPDCH DPDCH
HS-SCCH HS-DPCCH
HS-DSCH Transport High Speed Downlink Shared CHannel

HS-PDSCH Physical High Speed Physical Downlink Shared CHannel
HS-SCCH Physical High Speed Shared Control CHannel
HS-DPCCH Physical High Speed Dedicated Physical Control CHannel

HSUPA Channel
Here is the whole set of existing channels:

HSDPA channels:
HS-DSCH Transport High Speed Downlink Shared CHannel
HS-PDSCH Physical High Speed Physical Downlink Shared CHannel
HS-SCCH Physical High Speed Shared Control CHannel
HS-DPCCH Physical High Speed Dedicated Physical Control CHannel

Section 11 Pager 8
1.2 HSUPA Channels
Logical DCCH DTCH DTCH

Traffic
Signaling
TRB
SRB
Traffic Mobile x
Mobile x
TRB
Mobile y
E-DCH
Transport DCH HS-DSCH
UL
UL DL DL
E-DPDCH
Physical DPDCH DPDCH HS-PDSCH
E-HICH E-DPCCH
HS-SCCH HS-DPCCH
DPCCH
E-AGCH E-RGCH
E-DCH Transport Enhanced Dedicated CHannel

E-DPDCH Physical E-DCH Dedicated Physical Data CHannel
E-DPCCH Physical E-DCH Dedicated Physical Control CHannel
E-HICH Physical E-DCH HARQ Indicator CHannel
E-AGCH Physical E-DCH Absolute Grant CHannel
E-RGCH Physical E-DCH Relative Grant CHannel

HSUPA Channel
Here are the new HSUPA channels:
E-DCH Transport Enhanced Dedicated Channel
What is E-DCH?
It is an enhancement of classical dedicated channels. It can be divided into the following physical ones:
E-DPDCH Physical E-DCH Dedicated Physical Data Channel (data payload – SF=16)
E-DPCCH Physical E-DCH Dedicated Physical Control Channel (power control)
E-HICH Physical E-DCH HARQ Indicator Channel (Ack / Nack – SF=128)
E-AGCH Physical E-DCH Absolute Grant Channel (scheduling)
E-RGCH Physical E-DCH Relative Grant Channel (scheduling)
Note
In the next section of this course, we are going to describe the frame structure of the new HSUPA
channels.

Section 11 Pager 9
1.3 Transport Channel
New UL transport channel: E-DCH
Logical DCCH DTCH

Signaling Traffic
SRB TRB
Mobile i
Transport DCH HS-DSCH E-DCH

UL
UL DL DL
Physical DPDCH DPDCH HS-PDSCH E-DPDCH
HS-SCCH HS-DPCCH E-HICH E-DPCCH

DPCCH
E-AGCH E-RGCH

HSUPA Channel
A specific E-DCH transport channel is defined. As the classical DCH transport channel it allows to offer
transport services to higher layers.
The E-DCH transport channel is defined by the following characteristics:

Only for UL
Two possible TTI : 10ms and 2ms
Transport block size and Transport Block set size are free attributes of the transport format.
Possibility of HARQ process with retransmission procedures applied at Node B. Max number of
retransmission must be defined. Each transmitted blocks are numbered.
Possibility of smart redundancy management at Rx. The Redundancy Version (RV) used for the
transmission must be managed in order to apply Chase combining or Incremental Combining
mechanisms.
Turbo coding with rate 1/3 is used
CRC is 24 bits length
E-TFCI (Transport Format Combination Indication for E-DCH) indicates which format is currently used
for the UL transmission.

Section 11 Pager 10
1.4 Physical Channels
Logical DCCH DTCH

Signaling Traffic
SRB TRB
Transport DCH HS-DSCH E-DCH
UL
UL DL DL
Physical DPDCH DPDCH HS-PDSCH E-DPDCH
HS-SCCH HS-DPCCH E-HICH E-DPCCH

DPCCH
E-AGCH E-RGCH
E-DCH Transport Enhanced Dedicated CHannel
E-DPDCH Physical E-DCH Dedicated Physical Data CHannel
E-DPCCH Physical E-DCH Dedicated Physical Control CHannel
E-HICH Physical E-DCH HARQ Indicator CHannel
E-AGCH Physical E-DCH Absolute Grant CHannel
E-RGCH Physical E-DCH Relative Grant CHannel

HSUPA Channel
HSUPA includes a new set of new physical channels. Here are the basic functions of each channel:
E-DPCCH and E-DPDCH for UL. The first one is devoted to control. The second is for UL traffic.
E-HICH (HARQ Indicator Channel) in DL to indicate if the UL transmission are well received (ACK/NACK channel).
E-AGCH (Absolute Grant Channel) and E-RGCH (Relative Grant Channel) in DL to indicate to the HSUPA UE
(individually or per group) what are their allocated UL resources. This indication can be done using an explicit
value (through e-AGCH) or relatively to the last allocated UL resources (with e-RGCH).
We are going to deeply discuss the role of each physical channel in the following pages.

Section 11 Pager 11
1.5 Channels Roles
Traffic & Signaling Scheduling
Dedicated Dedicated
E-HICH E-DPDCH E-DPCCH E-AGCH E-RGCH

HSUPA Channel
We can divide the new set of channels into 2 categories: traffic & scheduling.
Scheduling channels
E-AGCH carries E-DCH absolute grant. It indicates to the E-DCH UE (either individually or per group)
what their resources are (absolute UL resources limitation).
E-RGCH carries E-DCH relative grants. It is a dedicated channel for the Node B involved in the E-DCH
active set. This channel allows each node B dealing with E-DPDCH to reduce the UE emitted power in
order to avoid radio interferences.
Traffic & signaling channels
E-HICH carries feedback information (ACK/NACK) sent by the Node B to indicate whether the packets
are properly received. This channel is based on the Node B HARQ algorithm. Thanks to this channel,
the Node B can send back to the UE indications about the faulty packets.
E-DPDCH is the uplink channel that carries the user data; TTI is either 10ms (mandatory supported by
UE) or 2 ms (optional support). Modulation is the same as DCH.
E-DPCCH is used to carry the uplink L1 signalling required to demodulate the E-DPCH: E-TFCI identity
of the E-TFC selected, RSN (number of H-ARQ retransmissions) and “happy bit” (telling if the grants
allocated to this UE are sufficient vs the amount data waiting in the transmission buffer).

Section 11 Pager 12

for this module

HSUPA Channel

Section 11 Pager 13
End of Module

HSUPA Channel

Section 11 Pager 14
12
Section 12
HSUPA Scheduling
9300 WCDMA

Section 12 Pager 1
Blank Page

HSUPA Scheduling
Document History
02 2010-05-12 Nolan, Vincent Ûpdate to UA07

Section 12 Pager 2
Objectives

Identify the general principles of the scheduling
mechanisms, including the grant allocation rules.

HSUPA Scheduling

Section 12 Pager 3
Objectives [cont.]

HSUPA Scheduling

Section 12 Pager 4
Table of Contents
Page
1 Scheduling Overview 7
1.1 General Principles 8
1.2 Channel Assignment 9
2 Grant Allocation for Scheduling 10
2.1 Grant Allocation Principles 11
2.2 EDCH active set 13
2.3 E-DCH Macro-Diversity 14
2.4 Types of Scheduler 15
2.5 UL Load Estimation 16
2.6 Scheduling and granting criteria 17

HSUPA Scheduling

Section 12 Pager 5

HSUPA Scheduling This page is left blank intentionally

Section 12 Pager 6
1 Scheduling Overview

HSUPA Scheduling

Section 12 Pager 7
1.1 General Principles
Main Steps
Frame #0 Frame #1 Frame #i
• Scheduling info (SI) 1

• Format definition (TB) 3
• Traffic data (throughput) 4
Iub
interface
2 • Absolute Grant
5 • Ack / Nack
6 • Relative Grants

HSUPA Scheduling
Like the HSDPA solution, the Node B is in charge of allocating the resources in terms of TTI, one after the
other.
Here are the main steps involved in the dialogue between the UE and the BTS:
1. The UE sends Scheduling Information (SI) to tell the Node B that it has data to send (via E-
DPDCH).
2. The Node B sends an Absolute Grant corresponding to the maximum uplink power resource the
UE can use (via E-AGCH).
3. According to the grant it has received, the UE can select an E-TFCI in the E-TFCS table that is
compatible with the power granted, to send data in UL (via E-DPCCH). The Transport Block size is
agreed.
4. The UE sends data in uplink along with a throughput that can dynamically vary according to the
grants of power it receives.
5. The Node B sends either ACK or NACK on E-HICH. If the Node B sends a NACK, the UE retransmits
the data based on the same process.
6. The Node B may send Relative Grant on E-RGCH at any time to adapt (increase or decrease) the
maximum uplink power resource used by UE.
All these steps can take place at every TTI (Transmission Time Intervall). The TTI can be either 10 ms or
2 ms (optional).

Section 12 Pager 8
1.2 Channel Assignment
Scheduler
• Absolute Grant 2
• Ack / Nack 5
• Relative Grants 6
E-DPDCH E-AGCH E-DPCCH E-DPDCH E-HICH E-RGCH
1 2 3 4 5 6
• Scheduling info 1
• Format definition 3
• Traffic data 4
HSUPA Scheduling
This slide shows the role of each HSUPA channel when the UE requests to send data.
Scheduler goals
The Scheduler is the key element of the HSUPA solution.
It is in charge of two major tasks:
It manages E-DCH cell resources between UEs,
It deals with uplink radio interferences.
What is Scheduling Information? It is a message reported by UE to indicate the current status of its
waiting list.
The UE available power results from: UE Power headroom)/ highest priority level /queue total size
percentage occupied by the queue of higher priority
One main constraint of the scheduler consists in supporting fairness among users according to their
Queue priority level:
15 levels of priority,
ensure a minimum access for each active UE.
With the introduction of the MAC-e protocol in charge of the scheduling, the Node B becomes smarter as
a decision-making centre.
Protocol layers functions , including MAC-e, are thoroughly described in section 4 of this course.

Section 12 Pager 9
2 Grant Allocation for Scheduling

HSUPA Scheduling

Section 12 Pager 10
2.1 Grant Allocation Principles
Total interference contribution Allocated Power / interference

contribution decides which
transport format can be used, so
Absolute BTS which throughput is available
& relative
grants
UEn Interference
contribution
UE3 IC UEn UE knows which Transport

UE1 IC format it can use
UE2 IC
Required power to use the ETFC

RNC sends
UE1 correspon-
ETFC dence info at
UE2 UE3 ETFC call setup
ETFC
ETFC
Node-B
Grants a
ETFC z certain
ETFC power
ETFC
ETFC
UE might use
Acronyms ETFC all or part of
ETFC the allocated
TFC: Transport Format Combination (E-TFC => E-DCH)
power
TFCI: Transport Format Combination Indicator (E-TFCI => E-DCH)

HSUPA Scheduling
The scheduling principles give the ability to the Node-B to control the set of TFCs a UE may use.
More precisely, the MAC protocol layer is in charge of the selection of the appropriate Transport format
for each Transport channel, using the Transport Format Combination Set (TFCS) assigned by the RRC.
Grants are allocated to each E-DCH UE. These UEs can then tune the power level at which they are
allowed to transmit. Each UE can adapt its throughput according to the grants by selecting the E-TFC in
the E-TFCS that is compatible with the granted power.
Grants are valid until new ones are sent. Mobiles can be addressed individually (primary E-RNTI) or in
groups (secondary E-RNTI).
A UE may be active or inactive on E-DCH. Any inactive UE has no grant allocated (grants are zero). To
send data, it has to send a Scheduling Information (SI) message to ask for grants.
Grants functions
The scheduling system is based on grants. Grants are computed by the scheduler:
to ensure some fairness between al users.
to prevent the global UL interferences level from exceeding a threshold (RTWPmax standing for
Received Total Wideband Power).
to make sure each UE will adapt its throughput on E-DPDCH according to the grants it has received.

Section 12 Pager 11
2.1 Grant Allocation Principles [cont.]
Types of grants
Absolute grant Node-B
Absolute value
E-AGCH Scheduling:
(e-RNTI, Scheduling Grant) Help!
t
Bi More resources!
y
pp
C H Ha
AG
E-
C H
PC
E-
D
CH Relative grant
RG
E-
+/-
E-RGCH Scheduling :
(up, DTx, down)

HSUPA Scheduling
The serving cell directly controls the UE requests through the scheduling channels based on absolute /
relative grants:
Absolute grants (i.e. E-AGCH) are allocated to the UE by the serving cell.
Relative grants (i.e. E-RGCH) are very useful in order to dynamically regulate (up / down) the power
of the UE. They prevent the serving cell from interfering (called “basting”) with non serving cells.
(No RGCH in UA5.0)
The E-RGCH is in charge of sending scheduling messages to the UEs belonging to the UE Active Set:
Serving cell: E-RGCH = up, DTx, down
Non serving cell: E-RGCH = DTx, down
(where DTX stands for Discontinuous Transmission).
Receiving one “down” command, the e-DCH UE reduces its uplink data throughput (i.e. E-TFCI).
At one time, a given mobile phone listens to a signature sequence carried by a E-RGCH channelization
code (up to 40 different sequences can be carried by a E-RGCH code).
The “happy bit” carried by the E-DPCCH indicates if the grants allocated to this UE are sufficient to face
the amount of data waiting in the transmission buffer.

Section 12 Pager 12
2.2 EDCH active set
Non Serving EDCH
Node-B Radio Link Set Non Serving EDCH
Serving EDCH Node-B Radio Link Set
Radio Link Set
Node-B
1 HICH
Node-
B 1 HICH RGCH
Serving EDCH RGCH
cell AGCH
1 RGCH for this UE

1 HICH for this UE • 1 Serving EDCH cell: cell from which the UE receives
the Absolute Grant
• 1 Serving EDCH RLS: set of cells containing the
E-DPDCH + Serving EDCH cell from which the UE can receive and
EDPDCH combine 1 single RGCH (and 1 HICH). It contains cells
from the same nodeB.
•1 or more non-serving EDCH RLS: cells which belong
to the EDCH active set and from which the UE can
receive an RGCH
HSUPA capable UE
•Max 4 RL in the E-active set.
UA5.0: EDCH active set =serving EDCH RLS
HSUPA Scheduling
There is one single “serving” radio-link and up to four “non-serving” radio-links, forming the E-DCH
active set.
This E-DCH Active Set is a sub-set of the active set.
Channel Assignments
The UE is assigned one E-HICH channel per radio-link, allowing to perform a HARQ per-radio-link
control of the link.
The UE is assigned one E-AGCH channel (on the serving cell).
At the serving cell level, the UE is assigned one E-AGCH channel and possibly one E-RGCH (Up, down
or DTX commands) channel on which it will be assigned grants.
We call non serving RLS the other cells that belong to the E-DCH active set, excluding the serving RLS.
These RLS are able to send a Relative Grant to the UE.
At the non-serving cell level, the UE is assigned one E-RGCH channel (down or DTX commands) to allow
to control the level of interferences that it generates.

Section 12 Pager 13
2.3 E-DCH Macro-Diversity
EDCH Non
EDCH Non
Serving RLS
Serving RLS
EDCH Node-B Node-B
Serving
Node-B
RLS#1
Node-B
EDCH macro diversity: HSUPA channel repartition

E-DPDCH and EDPCCH
• 1 EDCH serving cell (ie 1 AGCH)
HICH • Multiple nodeB EDCH control (ie EDPCCH) and
Relative Grant data (ie EDPDCH)
Absolute Grant • One or more HICH and RGCH
HSUPA
Associated DCH
capable UE the E-active set. Is a subset of the active set
HSUPA Scheduling
Here are the functions of each involved cell shown in the slide above:
The serving cell (RLS#1) is the unique cell that directly controls the UE requests through the
scheduling channels (absolute / relative grants).
The non serving cells (RLS#2 & RLS#3 above) are only involved in case of the SHO (soft handover)
situation. Since their main objective consists in dealing with active UEs, they shouldn’t waste their
own radio resources to ensure radio-diversity.
The e-DCH Macro diversity can be defined in terms of HSUPA channels repartition:
One single serving e-DCH cell (i.e. E-AGCH)
Multiple Node-B E-DCH control (i.e. E-DPCCH) & data (i.e. E-DPDCH) demodulation
One or more E-HICH & E-RGCH (from serving and non-serving cells)
In short, the E-DCH macro-diversity depends on the available processing resources.

Section 12 Pager 14
2.4 Types of Scheduler
Interference Contribution
UL Load
Allocation of the whole

capacity, shared equally
by all mobiles.
Rate scheduling
=>the higher the cell
(UA05 & UA06)
capacity, the lower the
user data rate.
Time
Interference Contribution
UL Load
Allocation at each TTI,
allowing mobile
Time scheduling throughput to peak.
=>the higher the targeted
user data rate, the lower
Time the cell capacity.

HSUPA Scheduling
The main target of the scheduler is to grant UEs so that the total UL load of the cell stays near the target
load (RTWPmax), but not above.
If the uplink load gets above this limit, then the scheduler will reduce the grants of the E-DCH links.
In case of radio “overload” (due to other traffics : CCH, DCH, inter-cell interferences and other
interferences), the grants of E-DCH links may get down to 0. If the UL load is below the limit then the
E-DCH UEs will be granted more.
Two kinds of scheduler are available :

time scheduling scheme: similar to HSDPA. Allocation at each TTI, allowing mobiles throughput to
peak.
i.e. the higher the targeted user data rate, the lower the cell capacity
rate scheduling scheme. Allocation of the whole capacity shared equally by all mobiles.
i.e. the higher the cell capacity, the lower the user data rate.

Section 12 Pager 15
2.5 UL Load Estimation
RTWP = Received Total Wideband Power
Rise Over Thermal: RoT = RTWP / Thermal Noise
FDDCell
RTWPref + totalRotMax typical: 6dB (=75% UL load)
BTSCell
E-DCH traffic
Available load
rtwpMaxCellLoadNonEdch
R99 CAC, BTS level.
typical: 50% (=3dB)
Increase to Measure sent to RNC for
cope with cell color management
EDCH
interf.
R99 traffic
R99 traffic + Interference
+ Interference
RTWPref
Thermal Noise Thermal Noise
No E-DCH With E-DCH

HSUPA Scheduling
Rise Over Thermal: RoT = RTWP / Thermal Noise
Two thresholds are defined:

- Max RTWP for total UL traffic (R99/E-DCH).
- Max RTWP for non E-DCH traffic only used for R99 CAC at the cell level.
E-DCH traffic is assigned the unused UL load up to the max RTWP.
Once an R99 call is accepted, it will not be dropped even if the non E-DCH load exceeds the max
specified.
Non E-DCH load (i.e. R99 + interference) will increase to cope with the E-DCH interference (as it was the
case for HSDPA).
RTWP measure is regularly sent by the BTS to the RNC for cellColor.
The RNC calculates RoT using Thermal Noise value.

Section 12 Pager 16
2.6 Scheduling and granting criteria
Scheduling Criteria
NOK OK
RoT
RoT <
< RoTmax
RoTmax
•Algorithm:Rate or
time
•Fairness:data already
UE served, Prio,
UE UE
Sorting UE
Sorting Scheduling •MBR and GBR
(de-grant Scheduling
(de-grantmgt)
mgt)
Resource
Resource Status
Status Grant
Grant
Update
Update Management
Management
Grant
Grant
Transmission
Granting / de-granting
Transmission
Criteria
•Shared resources:UL cell
load, Processing resources, nb
AGCH and RGCH, Iub
bandwidth
•UE resources: Power
headroom, data
HSUPA Scheduling
HSUPA scheduling strategy will result from a trade-off between:

The max number of HSUPA users per cell,
The targeted average user data rate.
Scheduling criteria
The scheduling algorithm / strategy
UA05 & UA06: Rate scheduling i.e. the higher the cell capacity, the lower the user data rate.
Fairness
a) UA05: amount of data already served
b) UA06: Priority Information + UL radio link QoS + Iub bandwidth
Granting & De-granting Criteria
Grant on shared resources
UL cell load, Processing resource availability, Number of E-AGCH, E-RGCH available
Grant on private UE resources
UE power headroom information, UE payload (data already served).
Note: RoT = Rise over Thermal
UA07: HSUPA Scheduler evolution
For traffic with uplink GBR the MAC-e «Scheduled Data mode” is used. MBR and GBR are considered as
grant criteria in the Node B scheduler. When radio, hardware and Iub resources are available, the MAC-
e scheduler can grant additional resource to the streaming call to increase the user throughput above
the GBR and thus improve the streaming quality.
The Mac-e scheduler also evolves to better evaluate the radio load caused by non continuous traffic
pattern (E.g. some streaming codec may be delivering 15 frames per second).
Note: The MBR management in Node B and the scheduler evolution for non continuous traffic sources are
also available for Interactive and background radio bearers.

Section 12 Pager 17
Summary

HSUPA Scheduling

Section 12 Pager 18

for this module

HSUPA Scheduling

Section 12 Pager 19
End of Module

HSUPA Scheduling

Section 12 Pager 20
13
Section 13
Module4 HSUPA HARQ
9300 WCDMA

Section 13 Pager 1
Blank Page

Module4 HSUPA HARQ
Document History

Section 13 Pager 2
Objectives

Identify the general principles of the scheduling
mechanisms with H-ARQ.
Compare HSUPA characteristics with HSDPA ones

Module4 HSUPA HARQ

Section 13 Pager 3
Objectives [cont.]

Module4 HSUPA HARQ

Section 13 Pager 4
Table of Contents
Page
1 H-ARQ Process 7
1.1 Stop And Wait HARQ Processes 8
1.2 HARQ Mechanisms 9
1.3 Soft HO Data Transmission Example 10
2 Exercices 11
2.1 HSUPA versus HSDPA 12

Module4 HSUPA HARQ

Section 13 Pager 5

Module4 HSUPA HARQ This page is left blank intentionally

Section 13 Pager 6
1 H-ARQ Process

Module4 HSUPA HARQ

Section 13 Pager 7
1 H-ARQ Process
1.1 Stop And Wait HARQ Processes
HARQ Wait for Transmission
UE has resources for

transmission
Update RV Parameters
Transmit Data
E-HICH
Wait for ACK/NACK Reception

ACK/NACK
DTX Insert DTX

ACK ACK/NACK/DTX? Indication
NACK
Reset & Free

HARQ Process Nret = Nret + 1
TB HARQ
YES Nret > Nret_max NO TB HARQ

Module4 HSUPA HARQ
Once a UE is scheduled, a HARQ process is assigned that may correspond to either a new Transport Block
transmission or a TB retransmission. The RV parameters are computed accordingly and data is
transmitted.
The HARQ process is then waiting for feedback information (ACK / NACK / DTX):
In case of ACK reception, the HARQ process is reset and corresponding MAC-d PDUs are removed from
memory. This HARQ process can now be used for a new transmission.
In case of NACK reception, the number of retransmissions must be incremented. If the maximum
number of retransmissions is not reached, the HARQ process is inserted in the “NACK list” of HARQ
processes asking for retransmission.
In case of DTX indication, the same actions as for NACK reception are performed, except that a
parameter must be updated to notify DTX detection (this changes the RV parameter update).
After a NACK reception or a DTX indication, the HARQ processes are just waiting for being re-scheduled
for a new retransmission.
Note
DTX stands for Discontinuous Transmission: it is used on Radio interface to switch-off the radio activity
during the silent times until the conversation resumes. DTX indication is used when there is no
ACK/NACK reception.

Section 13 Pager 8
1 H-ARQ Process
1.2 HARQ Mechanisms
RV0 RV1 RV2
Process 0
Process 1
Data 1 Process 2
Ack Process 3
Data 2 Data 1
Data
Data 3 Nack Data 2
Data
Data 4 Ack Data 3
Data
Data 5 Transmissions Ack Data 4
Data 2
Data Ack Data 5 To next step
(demultiplexing)
Data 6 Nack Data 2 combining
Data 1
Data 7 Ack/nack Nack Data 6
Data 3
Data 8 Ack Data 7
Data 4
Data
Data 2 Ack Data 8
Data 5
Data 6 Ack Data 2
Data 7
Data 9 Ack Data 6
Data 8
Data 10 Ack Data 9 combining
Data 2
Data 11 Ack Data 10
combining Data 6
Data 12 Ack Data 11
Data 9
Data 13 Ack Data 12
Data 10
Ack Data 13
Data 11
Data 12
Data 13

Module4 HSUPA HARQ
The HARQ process (Hybrid Automatic Repeat reQuest) is based on a similar scheme as for HSDPA, directly
handled by Node B and UE.
The E-HICH relies on the Node B HARQ algorithm. It handles retransmissions. Thanks to this channel, the
Node B can send back to the UE indications about the faulty packets.
There are few differences between HSDPA & HSUPA solutions: HSUPA works in SHO and is based on
synchronous retransmissions in the uplink.
Downlink: HARQ based on synchronous ACK/NACK
There is a well-defined timing relationship between reception of the transport block and
transmission of the acknowledgement by the Node B.
Uplink: HARQ based on synchronous retransmissions
Fix number of Stop-and-Wait HARQ processes
8 processes for 2ms TTI
4 processes for 10ms TTI
Maximum number of retransmissions configured per MAC-d flow.

Section 13 Pager 9
1 H-ARQ Process
1.3 Soft HO Data Transmission Example
Physical Channels Transport Channels
E-AGCH
1. Absolute Grant Serving RNC
E-DCH FP
E-DCH
E-DPCCH
5. Void !
UE
cell
2a. E-TFCI(1) 9a. Data Tx(2) Ctxt
6a. E-TFCI(2) RLS 13a. Void
10a. E-TFCI(1)
E-DPDCH
3a. Data Tx(1)
7b. Data Tx(2)
11a. Data Tx(1)
E-HICH
4a. NACK(1)
8a. ACK(2) 14. Data
UE 12a. NACK(1) Reordering/
Non- Combining
E-DPCCH
2b. E-TFCI(1) serving
6b. E-TFCI(2) E-DCH
cell E-DCH FP
10a. E-TFCI(1)
5. Void
E-DPDCH RLS 9b. Data Tx(2)
3b. Data Tx(1) 13b. Data Tx(1)
7b. Data Tx(2)
11b. Data Tx(1)
E-HICH
4b. NACK(1)
8b. ACK(2)
12b. ACK(1)

Module4 HSUPA HARQ
This operation occurs in soft handover situations (SHO): Intra Node B and inter Node B macro-diversity
are supported by the HSUPA solution.
Multiple Node Bs transmit HARQ ACK/NACK in DL. The reliability of the signalling is essential to avoid de-
synchronisation of the Node Bs buffers and ACK/NACK errors.
In softer handover, cells belonging to the same Node B transmit the same HARQ ACK/NACK information
(same RLS).
Resynchronisation of HARQ instances at the Node B are implicitly performed, based on Retransmission
Sequence Number.

Section 13 Pager 10
2 Exercices

Module4 HSUPA HARQ

Section 13 Pager 11
2 Exercices
2.1 HSUPA versus HSDPA
Question: what are the differences and similarities between HSDPA and HSUPA?
HSDPA HSUPA
1. HS-PDSCH, a Shared channel 1. E-DCH, an enhanced Dedicated channel
2. Fast scheduling at Node B level (TTI: 2ms) 2. Fast scheduling at Node B level (TTI: 10ms =>
mandatory), 2ms =>optional)
3. Fast retransmission of data (H-ARQ usage) 3. Fast retransmission of data (H-ARQ usage)
4. Adaptable radio modulation (QPSK and 4. Basic radio modulation QPSK only (BPSK)
16-QAM)
5. Downlink radio quality & downlink 5. Uplink Noise Rise & uplink resource
resource management management

Module4 HSUPA HARQ
Obviously, HSDPA and HSUPA are two different techniques that share lots of basic mechanisms.
1+1
Coupling the usage of both HSDPA in DL and HSUPA, these mechanisms highly enhance the spectral
efficiency of UMTS technology versus live sporadic traffic.
Indeed, HSxPA maximizes the number of high data rate users from a air interface usage standpoint while
minimizing the UL/DL service delay with high peak rate.
By principle, HSUPA with HSDPA dynamically adapts and maximizes the peak data rate of each subscriber
according to cell load and UTRAN resource availability.
Implementation
The feature is a software-only upgrade based solution as far as the minimum processing power required
in the Node-B is available i.e. one iCEM BBU (E-BBU) at least to handle the Node-B HSUPA L1/L2
software.

Section 13 Pager 12

for this module

Module4 HSUPA HARQ

Section 13 Pager 13
End of Module

Module4 HSUPA HARQ

Section 13 Pager 14
14
Section 14
Module5 HSUPA UTRAN Protocols
9300 WCDMA

Section 14 Pager 1
Blank Page

Document History

Section 14 Pager 2
Objectives

Describe the MAC entities belonging to the
MAC architecture.
Identify the functional roles of the MAC-e and
MAC-es within the global architecture.
Identify the frame structure of each physical channel and their own
characteristics.


Section 14 Pager 3
Objectives [cont.]


Section 14 Pager 4
Table of Contents
Page
1 MAC Entities 7
1.1 Protocol Layers 8
1.2 UTRAN Protocol Layers 9
1.3 MAC Entities 10
1.3.1 NodeB 11
1.3.2 RNC 12
1.4 MAC-e Scheduling 13
2 Physical Channel Frame Structure 14
2.1 E-DPDCH / E-DPCCH Frame Structure 15
2.2 E-AGCH, E-RGCH, E-HICH Frame Structure 16
2.3 OVSF for DL control channels 17
3 Frame Protocols 18
3.1 Iub Frame Protocol Configuration 19
4 Exercise 20
4.1 Physical Channels 21


Section 14 Pager 5

Module5 HSUPA UTRAN Protocols This page is left blank intentionally

Section 14 Pager 6
1 MAC Entities


Section 14 Pager 7
1 MAC Entities
1.1 Protocol Layers
RLC (Radio Link Control)
Logical Channels
MAC (Medium Access Control)
Transport Channels
Transport sublayer
PHY
Physical Channels (PHYsical Layer)
Physical sublayer

UMTS relies on the concept of logical channels, characterized by the type of information that is
transferred and transport channels which are described by how and with what characteristics the data
is transferred over the air interface.
The mapping between the logical and transport channels is performed by the MAC (Medium Access
Control) sub-layer.
MAC main functions:
Mapping between logical channels and transport channels
Selection of appropriate Transport Format
Priority handling between data flows of one UE
Priority handling between UEs
Identification of UEs on common channels
Multiplexing/ demultiplexing of higher layer PDUs
Traffic volume monitoring
Ciphering
Access Service Class selection for random access transmission

Section 14 Pager 8
1 MAC Entities
1.2 UTRAN Protocol Layers
DTCH DCCH DCCH DTCH
MAC -d MAC -d
MAC -es
MAC -es /
MAC -e
MAC -e MAC -e EDCH FP EDCH FP
PHY PHY TNL TNL TNL TNL
Uu
Iub D RNC Iur
UE Node B SRNC

Here are the main functions of the new protocol layers within the UTRAN subsystem:
At UE level: MAC-es / MAC-e handles HARQ retransmissions, scheduling and MAC-e multiplexing, E-
DCH TFC selection.
At Node B level: MAC-e handles HARQ retransmissions, scheduling and MAC-e de-multiplexing.
At SRNC level: MAC-es provides in-sequence delivery (reordering) and handles duplication avoidance
(combining) in case of inter Node B soft handover.
Note
Layers above MAC are left unchanged.
In section 4, we will discuss more deeply the functions of the protocol layers.

Section 14 Pager 9
1 MAC Entities
1.3 MAC Entities
Logical Channels
BCCH PCCH BCCH CCCH CTCH DCCH DTCH
MAC
Control
(RRC)
MAC-b MAC-c/sh MAC-d

MAC-hs MAC-es
/MAC-e
Transport Channels
BCH PCH FACH RACH DCH DCH HS-DSCH E-DCH

(downlink) (uplink)

The diagram above describes the MAC architecture. It is built upon MAC entities.
The four entities are assigned the following names:
MAC-b is the MAC entity that handles the following transport channels. It is located in the Node B.
broadcast channel (BCH)
MAC-c/sh, is the MAC entity that handles the following transport channels:
paging channel (PCH)
forward access channel (FACH)
random access channel (RACH)
MAC-d is the MAC entity that handles the following transport channels:
dedicated transport channel (DCH)
MAC-hs is the MAC entity that handles the following transport channels:
high speed downlink shared channel (HS-DSCH).
MAC-e/es are the MAC entities that handle the following transport channels:
Enhanced dedicated transport channel (E-DCH)
Note
The exact functions completed by the entities are different in the UE from those completed in the
UTRAN.

Section 14 Pager 10
1.3 MAC Entities
1.3.1 NodeB
MAC-d flows
MAC-e
Flow Control MACes PDUs
Scheduling
Cell resources between Scheduling /
UE
De-multiplexing
requests
grants
Control
MACe PDUs
HARQ entity
HARQ entity
Fast transmisson. retrans
TRFC selection
Associated
Associated
Downlink
Uplink
signalling
signalling
E-HICH/
E-AGCH/E-RGCH E-DPCCH E-DPDCH

The MAC-e and E-DCH scheduler comprises the following entities:

E-DCH Scheduling:
This function manages E-DCH cell resources between UEs. Based on scheduling requests, Scheduling
Grants are determined and transmitted.
E-DCH Control:
The E-DCH control entity is responsible for reception of scheduling requests and transmission of
Scheduling Grants.
De-multiplexing:
This function provides de-multiplexing of MAC-e PDUs. MAC-es PDUs are forwarded to the associated
MAC-d flow.
HARQ:
One HARQ entity is capable of supporting multiple instances (HARQ processes) of stop and wait HARQ
protocols. Each process is responsible for generating ACKs or NACKs indicating delivery status of E-DCH
transmissions. The HARQ entity handles all tasks that are required for the HARQ protocol.

Section 14 Pager 11
1.3 MAC Entities
1.3.2 RNC
To MAC -d
MAC -es
MAC – Control
Disassembly Disassembly Disassembly
Reordering/ Reordering/ Reorderi ng/

Combining Combining Combining
Reordering Queue Reordering Queue

Distribution Distribution
MAC -d flow #1 MAC -d flow #n
From From
MAC -e in MAC -e in
NodeB #1 NodeB #k

The MAC-es comprises the following entities:

1. Reordering Queue Distribution:
The reordering queue distribution function routes the MAC-es PDUs to the correct reordering buffer
based on the SRNC configuration.
2. Reordering:
This function reorders received MAC-es PDUs according to the received TSN and Node-B tagging i.e.
(CFN, subframe number). MAC-es PDUs with consecutive TSNs are delivered to the disassembly
function upon reception. Mechanisms for reordering MAC-es PDUs received out-of-order are left up to
the implementation. There is one Re-ordering Process per logical channel.
3. Macro diversity selection:
The function is performed in the MAC-es, in case of soft handover with multiple Node-Bs (The soft
combining for all the cells of a Node-B takes place in the Node-B). This means that the reordering
function receives MAC-es PDUs from each Node-B in the E-DCH active set.
4. Disassembly:
The disassembly function is responsible for disassembly of MAC-es PDUs. When a MAC-es PDU is
disassembled the MAC-es header is removed, the MAC-d PDU’s are extracted and delivered to MAC-d.

Section 14 Pager 12
1 MAC Entities
1.4 MAC-e Scheduling
Max RoT provided by

Uplink RoT the RNC
NOK interferences OK
level acceptable?
Processing Processing performed in

UE the nodeB
UE UE
UE
capacity
Sorting
Sorting Scheduling
Scheduling
(de-grant
(de-grantmgt)
mgt)
Resource
ResourceStatus Grant
Status
Update
Grant
Management
Scheduling
Update Management
Grant
Grant
Transmission
Transmission

The grants computed by the scheduler are limited by two factors:

the global uplink interferences level must not go above a certain threshold (RTWPmax standing for
Received Total Wideband Power)..
the BTS processing capabilities dedicated to E-DCH.
The RNC will provide the RTWPmax and RTWPref to the BTS. This will be interpreted as the maximum
Rise Over Thermal that the scheduler shall consider.
The BTS will use a self-learned RTWPref for the scheduling, so the RTWPmax considered by the BTS may
be different (above or below) than the one given by the RNC.
BTS impacts
The scheduling functions are managed in the BBU (1 BBU per iCEM64, 2 BBU per iCEM128 and 4 BBU
per xCEM).
One E-BBU (a specific BBU managing HSUPA services) can handle up to 15 UEs in iCEM & 128 in xCEM
in UA06.
(BBU=Base Band Unit; CEM=Channel Element Module)

Section 14 Pager 13
2 Physical Channel Frame Structure


Section 14 Pager 14
2.1 E-DPDCH / E-DPCCH Frame Structure
Tslot=2560 chips, 10x2k bits (k=0 … 7)
Data (N bits)
E-DPDCH Structure
(Uplink Data Channel)
Slot #0 Slot #1 Slot #2 Slot #i Slot #14
One E-DPDCH subframe

Tslot=2560 chips
ETFCI RSN (HARQ) Happy Bit
E-DPCCH Structure
(Uplink Control Channel)
Slot #0 Slot #1 Slot #2 Slot #i Slot #14
Carries control signaling: One E-DPDCH subframe

• ETFCI: 7 bits (selected TFC) One radio frame (10 ms)

• RSN: 2 bits (number of HARQ retransmissions)
• Happy bit: 1 bit (grant OK for UE)

(The E-DCH transport channel is associated with 2 UL physical channels: E-DPDCH & E-DPCCH. )
E-DPDCH (UL)
It carries the UL traffic.
The Spreading Factors: 256, 128, 64, 32, 16, 8, 4, 2
TTI is either 10 ms (mandatory) or 2 ms (UE capability).
Multi-code is used only at SF=2 and SF=4.
E-DCH introduces the use of H-ARQ in uplink on the E-DPDCH (like HSDPA in downlink) directly handled by
Node B and UE, allowing for fast retransmissions. The number of H-ARQ processes is 8 (for TTI 2ms) or 4
(for TTI 10ms).
Recombining is done using Chase Combining or Incremental Redundancy.
Slot Format:
Slot Format Channel Bit SF Bits/ Bits/ Sub- Bits/Slot

#i Rate (kbps) Frame frame Ndata
0 15 256 150 30 10
1 30 128 300 60 20
2 60 64 600 120 40
3 120 32 1200 240 80
4 240 16 2400 480 160
5 480 8 4800 960 320
6 960 4 9600 1920 640
7 1920 2 19200 3840 1280

Section 14 Pager 15
2.2 E-AGCH, E-RGCH, E-HICH Frame Structure
E-AGCH Structure Power Grant Grant Scope CRC (by E-RNTI)
Carries EDCH absolute grant: Slot #0 Slot #1 Slot #2 Slot #i Slot #14
• Power granted (5 bits)
One subframe
• Grant scope: 1bit (TTI=2ms =3 time slots) One radio frame (10 ms)
• CRC XORed by E-RNTI (UE Id) (16 bits)
Tslot=2560 chips E-HICH Structure

b1,0 b1,0 b1,0
Carries H-ARQ ack:
• +1 = ACK
Slot #0 Slot #1 Slot #2 Slot #i Slot #14 • 0 = NACK by non serving nodeB
One subframe (=DTX)
(TTI=2ms =3 time slots) • -1= NACK by serving nodeB
E-RGCH Structure b1,0 b1,0 b1,0

Carries relative grant: Slot #0 Slot #1 Slot #2 Slot #i Slot #14
•+1 = up (serving nodeB only) One subframe
• 0 = DTX (TTI=2ms =3 time slots)
•-1= down One radio frame (10 ms)

E-AGCH (DL)
It carries E-DCH Absolute Grant. The structure is similar to HS-SCCH (UE specific CRC)
It indicates to the E-DCH UE what are their allocated UL resources (absolute UL power resources
limitation). It uses E-RNTI to target UE or groups of Ues, It works with serving E-DCH cell only
The SF is fixed to 256. AGCH can be transmitted in 2ms. In 10ms TTI, the AGCH lasts for 10ms. It consists
of repetitive sending of 2ms messages.
E-HICH (DL)
It shares the same OVSF codes as the E-RGCH and has the same structure. UEs are differentiated by the
signature. There is a set of 40 signatures per code, allowing to address several UEs at the same time.
E-HICH carries the H-ARQ acknowledgement indicator: +1 = ACK ; 0 = NACK by a non-serving Node B
(means DTX); -1 = NACK by the serving Node B.
The indicator is multiplied by the signature of the UE for the E-HICH (40 bits) When the E-DCH is in soft
handover (not supported in this release), the UE will consider that the HARQ process has been correctly
received if at least one Node B reports an ACK.
On the non serving cell, the HICH lasts for 10ms(not used in UA5.0)
E-RGCH (DL) (Not available in UA5.0)
It carries E-DCH Relative Grants:
1/0/-1 transmitted from serving RLS to indicate UP/HOLD/DOWN
0/-1 transmitted from non serving RLS to indicate HOLD/DOWN
It works with serving and non-serving E-DCH cells. It shares the same OVSF codes as the E-HICH and has
the same structure. It allows to increase or decrease the resource limitation.
UEs are differentiated by the signature: the E-RGCH relies on signature to target a UE or group of UEs. A
given mobile listens to a signature sequence carried by an E-RGCH channelization code. 40 different
sequences can be carried by a E-RGCH channelization code (can send information to 40 UEs per TTI per
E-RGCH+E-HICH)

Section 14 Pager 16
2.3 OVSF for DL control channels
SF128
SF256
SF16
SF32
SF64
SF4
SF8
0
0 Common channels (1 S-CCPCH)
0
1
0 4 S-CCPCH #2
2 2
1 5
3
1 S-CCPCH #3
4 6
2 3
5 7 HS-SCCH (2 for ex)
1
6 8
3 4 18
E-HICH and E-RGCH
7 DL HSUPA channels are allocated just
9
19 after the HS-SCCH codes
8 20 E-AGCHs
4 10
9 5 11
2 11
10
5
11
12
6 Free OVSF codes Dynamic DL code tree management
13
3
14
7 HS-PDSCH
15


Section 14 Pager 17
3 Frame Protocols


Section 14 Pager 18
3 Frame Protocols
3.1 Iub Frame Protocol Configuration
•Same VCC (possible addition for capacity
reasons),
•Different CID
EDCH FP contents
•User data transmission •DDI info (logical channel, MAC-D flow, MAC-D PDU size)
Only the correctly decoded MAC-es PDU
•CFN: indicates when HARQ decoded correctly (identifies the
•HARQ failure indications TB) +subframe nb in case of 2ms TTI
•RNC congestion indications •N: nb of HARQ retransmissions

The E-DCH Frame Protocol for the Iub interface has several objectives:
User data transmission of E-DCH traffic between BTS and RNC,
HARQ failure indication from BTS to RNC,
Transport Network Congestion indication from RNC to BTS.
The FP data PDU contains the MAC-es PDUs that have been correctly decoded in the MAC-e PDU of the
TTI.
If the MAC-e PDU contains several MAC-d flows then they are demultiplexed and sent on their respective
transport bearers (in UA5.0, only 1 MAC-d flow is supported on E-DCH so this is not applicable) so using
distinct E-DCH FP DATA frames.
For a HSUPA data session, there at least 3 Frame Protocol contexts used over the Iub, as illustrated by
the picture above.
1. The first Frame Protocol supports the associated DCH, i.e. uplink and downlink signaling, and is
mapped on a dedicated CID (DS QoS).
2. Another Frame Protocol on DCH may be used support a CS service established in parallel of the
PS I/B service.
3. The E-DCH Frame Protocol supports the uplink part of the user packet data traffic. It is mapped
on a dedicated CID on the UBR QoS VCC (which has lower priority that DS and NDS VCC) which is
the same VCC as the HS-DSCH one (but using different CIDs).
CID= AAL2 Channel ID, CFN=Connection Frame Number, TB=Transport Block

Section 14 Pager 19
4 Exercise


Section 14 Pager 20
4 Exercise
4.1 Physical Channels
Associated DPDCH for SRB traffic
Associated DPCCH
HS-DPCCH Feedback information

(CQI, Ack/Nack) Node-B
HS-SCCH Signaling part
(UE id, …)
HS-PDSCH for Mono PS I/B traffic
E-DPDCH for Mono PS I/B traffic (and

HSPA-capable optional SI)
Rel’6 UE
E-DPCCH Feedback information
(e-TFCI, RSN, Happy bit)
E-HICH Feedback information
Ack/Nack, signature)
E-AGCH Scheduling information
(e-RNTI, Absoute Grant)
R6
R99
R5 Task: Identify the physical channels used when making traffic in
HSUPA. In UA5.0 (No multiservice)


Section 14 Pager 21
Summary


Section 14 Pager 22

for this module


Section 14 Pager 23
End of Module


Section 14 Pager 24
15
Section 15
Module6 HSUPA Scenario
9300 WCDMA

Section 15 Pager 1
Blank Page

Document History

Section 15 Pager 2
Objectives

Describe the main procedures associated with E-DCH call
establishment and mobility


Section 15 Pager 3
Objectives [cont.]


Section 15 Pager 4
Table of Contents
Page
1 Call setup Procedure 7
1.1 Call Establishment 8
1.2 Initial connection 10
1.3 RAB allocation phase 11
2 Primary cell change 12
2.1 Intra-Frequency Mobility 13
2.2 HSUPA over Iur 16
3 DCH Fallback Procedure 17


Section 15 Pager 5

Module6 HSUPA Scenario This page is left blank intentionally

Section 15 Pager 6
1 Call setup Procedure


Section 15 Pager 7
How is HSUPA triggered by the network?
3. DCH ? E-DCH ?
1. Request for service
(e.g. Web Browsing)
RNC
Node B Core
Network
2. RAB
Assignment
UE 4. E-DCH Establishment Request


Section 15 Pager 8
E-DCH or
DCH ?
RAB assignment
request from CN
RAB Traffic Class Service = PS?
HSDPA in DL ?
E-DCH
selection
Cell Capability E-DCH in Cell?
UE Capabilities HSUPA UE?

With the introduction of HSUPA in the UTRAN, a new type of transport channel can be allocated to serve
the RAB requested from the CN. Thus, the channel type selection algorithm allows selecting either DCH
or E-DCH in UL depending on the RAB characteristics received from the CN.
At reception of a “RAB assignment Request”, the SRNC selects the transport channel type between DCH
and E-DCH according to the following constraints:
RAB traffic class

PS RABs with traffic class “interactive” and “background” are transported on HS-DSCH. In UA06
Alcatel-Lucent supports the “Streaming” traffic class over HSDPA and from UA07 Alcatel-Lucent
supports the “Streaming” traffic class over HSUPA.
RAB combinations from UA07
PS Str. + PS I/B over HSUPA/HSDPA
CS speech over DCH + PS Str. + PS I/B over HSUPA/HSDPA
UE capability to support E-DCH
E-DCH can be selected only if UE supports it, as indicated by the UE capability “Support of E-DCH”,
and if UE supports the combination of already established DL DCH and HS-DSCH, as indicated by the
UE capability.
Cell capability to support HS-DSCH
E-DCH can be selected only if the serving cell also supports HSDPA.
Channel type selection is performed prior to call admission control. Then depending on the channel type
selection, either DCH RAC or HSxPA RAC is triggered.

Section 15 Pager 9
1.2 Initial connection
UE Node B RNC SGSN

RRC/RACH / RRC connection Request Cause
Access Stratum Release Indicator (R6? R5?)
NBAP/ RL setup Request
NBAP/ RL setup Response
RRC/FACH/RRC connection Setup
RRC/DCH/ RRC Connection Setup Complete

EDCH? HSDPA? + UE Category
RRC/DCCH/Initial Direct Transfer (Service Request)
GMM/Service Request
RRC /DCCH/ Measurement control X 4

This step is similar to non E-DCH calls.

The RRC connection request establishment cause might be used for traffic segmentation, as well as
Access stratum release indicator.
After RRC connection complete, the RNC has a full knowledge of the UE capabilities.

Section 15 Pager 10
1.3 RAB allocation phase
UE NodeB RNC SGSN
Security functions: Authentication and Ciphering + Security mode
GMM activate PDP context Request
e-DCH-MACdFlow-ID, RANAP/RAB Assignment Request

PowerOffsets AGCH, RGCH, HICH,
PowerOffset EDPCCH), NBAP/Radio Link Reconfiguration Prepare
Reference ETFCI PO, TTI
HARQ (RV table, max retrans )
AGCH OVSF code

ERNTI (1&2) NBAP/Radio Link Reconfiguration Ready
RGCH HICH OVSF code HICH
signature
initial serving grant value
NBAP/Radio Link Reconfiguration Commit
Same as RL Reconf Prep + ERNTI (1&2)

RRC/Radio Bearer Setup AGCH, RGCH,HICH OVSF
HICH signature
Initial serving grant
RRC/Radio Bearer Setup Complete
RANAP/RAB Assignment Response
GMM activate PDP context accept

In this phase, only the NBAP Radio Link Reconfiguration procedure and RRC Radio Bearer
Reconfiguration are modified because of E-DCH.

Section 15 Pager 11
2 Primary cell change


Section 15 Pager 12
Node-B Node-B Node-B
Non Serving Serving Non Serving Non Serving

Cell#1 cell Cell#2 Cell#3
Primary cell change
E-DCH control and data

E-HICH
UE
Absolute Grant
E-DCH macro-diversity in UA06 Associated DCH (in SHO)

Mobility of associated DCH

Soft and softer handovers are handled on the associated DCHs. The Active Set is managed differently
according to the reporting mode (periodic or intra-frequency event triggered).
Mobility of HS-DSCH
As specified by the 3GPP standards, HS-DSCH is established in only one cell: never in soft handover. In
Alcatel-Lucent implementation, HS-DSCH is established on the primary cell (since good radio conditions
and not changing too often).
Each time the primary cell changes, the HS-DSCH RL is deleted on the former primary and established
under the new primary, using a synchronous reconfig. If the new cell does not support HSDPA then the
RB is reconfigured to DCH.
Moreover, anytime an HSDPA-capable mobile (operating in DCH mode) enters an HSDPA primary cell it is
reconfigured to HSDPA.
Mobility of E-DCH
There is only one serving E-DCH radio-link and it is established in the same cell as the HS-DSCH radio-link.
The mobility of the E-DCH serving link is based on the same principles as the HS-DSCH one. In case of
primary cell change, the E-DCH serving link and the HS-DSCH link are moved at the same time (one
procedure).
If the new primary cell does not support HSUPA then the RB is reconfigured to DCH in UL (maintained on
HS-DSCH in DL if the cell supports HSDPA). On the opposite, it is reconfigured to E-DCH if the mobile
returns to HSUPA coverage.

Section 15 Pager 13
Primary cell change E-DCH
RNC source Node B target Node B UE
Primary cell change
RB Reconfiguration (Activation CFN, new E-RNTI,

Serving E-DCH RL, E-AGCH info, E-HICH info)
Measurement Control (new neighbouring list)
Activation CFN
RB Reconfiguration Complete

E-DCH is established only on Primary cell of the Active Set

Each time the primary cell changes, the E-DCH RL is deleted on the former primary and it is re-
established under the new primary, using a synchronous reconfiguration. The HS-DSCH is reconfigured
at the same time.

Section 15 Pager 14
Event 1J
Event1J
CPICH_EC/No
E-ASET Cell
ASET Cell (B)
entering reporting range
leaving reporting range InE-ASET Cell (A)
Event 1J (specific to E-DCH Macro Diversity):
Definition: The CPICH of a cell that is in DCH AS but not in E-

DCH AS becomes better than the CPICH of a cell that is
already in E-DCH AS

Event 1J (specific to E-DCH Macro Diversity):
Definition: The CPICH of a cell that is in DCH AS but not in E-DCH AS (cell “B”) becomes better than
the CPICH of a cell that is already in E-DCH AS (cell “A”).
Action triggered: Cell ”A” is removed from the E-DCH AS and replaced by cell “B”
(provided that cell “B” supports current E-DCH Configuration).
Remark: Event 1J is only configured when the “Full-Event Triggered” reporting of measurements
mode is used for intra-frequency mobility.
Primary Cell change:

When Primary Cell changes, E-DCH serving cell is changed to the new Primary Cell.
If the new Primary Cell does not support current E-DCH Configuration:
- E-DCH Configuration is changed to match E-DCH capabilities of the new Primary Cell.
- If E-DCH Configuration is changed to a more restrictive one (e.g. 10ms TTI → 2ms TTI),
any cell of E-DCH AS not supporting the new E-DCH Configuration is removed from E-DCH AS.
If the new Primary Cell does not support E-DCH, the E-DCH RB is reconfigured to UL DCH.
Remark:
All cells removed from DCH AS and present in E-DCH AS are also removed from E-DCH AS

Section 15 Pager 15
2.2 HSUPA over Iur
Core Network
SRNC DRNC
E-DCH FP
E-DCH
Associated
Associated DCH
DCH
E-PDSCH(s)

The feature ensures a seamless mobility for HSUPA calls while a user moves from a SRNC to a D-RNC
through the Iur interface.
The HSUPA over Iur capability is required in both the S-RNC and D-RNC to allow the handling of the
configuration, maintenance, release of active HSUPA call over Iur.
In HSUPA mode, the SRNC configures the radio link with E-DPCH and E-DCH Information and the
characteristics of HSUPA service is decided by the property of Primary Cell.
As a Serving RNC, the decision to configure an existing RL over Iur with HSUPA is taken when a cell
belonging to a neighbouring RNC is added to the active set and the cell is able to be compliant with the
existing HSUPA service.
The request is sent to the neighbouring RNC using a RNSAP radio link setup/addition/reconfiguration
prepare message with E-DPCH and E-DCH information.
The UE is configured accordingly.
• As a Drift RNC, a radio link is configured to HSUPA when the DRNC receives a RNSAP radio link
setup/addition/reconfiguration prepare message with E-DPCH and E-DCH Information.
Bearing in mind the Iur dimensioning constraint for certain customers, the feature can be deactivated, in
which case a DCH fall back solution is offered to maintain the call continuity when crossing the Iur.
This may also be needed for IOT scenarios.

Section 15 Pager 16
3 DCH Fallback Procedure


Section 15 Pager 17
3 DCH Fallback Procedure
HSPA to DCH Fallback (1)
Max users
Primary cell HSU or HSD
change
Rab
assignment
Core
NBAP or
RNSAP
Network
failure
Inter RNC HHO

Alarm HHO

HSPA to DCH fallback feature allows establishing or reconfiguring the PS I/B Streaming RAB
into DCH in case of HSDPA or HSUPA CAC failure.
The following HSxPA CAC failure scenarios trigger such a fallback:
• RAB assignment (to establish or to release)
• IU release
• Primary Cell change
• Inter-RNC UE involved Hard Handover
• Alarm Hard Handover
In case of HSPA CAC failure, i.e. lack of resources, HSPA to DCH fallback feature
allows reconfiguring UL and/or DL into DCH as if UE was not HSUPA and/or HSDPA
capable, mainly based on failure causes:
• Internal to RNC: maximum number of HSDPA or HSUPA users
• External to RNC: NBAP or RNSAP failure causes

Section 15 Pager 18
Answer the Questions
1. In macro diversity, a non serving cell can

send E-AGCH message (yes/no)
2. What is the definition of the event 1J ?
3. Do we have such event in HSDPA ?


Section 15 Pager 19

for this module


Section 15 Pager 20
End of Module


Section 15 Pager 21
16
Section 16
Module7 HSUPA AL Implementation
9300 WCDMA

Section 16 Pager 1
Blank Page

Document History
01 2008-07-10 Gilardi, Stefania First edition

Section 16 Pager 2
Module Objectives
Upon completion of this module, you should be able to:
Describe the different scenarios of deployment for UMTS Radio Access

networks.
Identify the main parameters associated with the HSUPA / E-DCH solution.
Recognize the main hardware and software requirements for the BTS
configuration.


Section 16 Pager 3
Module Objectives [cont.]


Section 16 Pager 4
Table of Contents
Page
1 Deployment Scenario 7
2 BTS Hardware Configuration 13
3 HSUPA power Control 20


Section 16 Pager 5

Module7 HSUPA AL Implementation This page is left blank intentionally

Section 16 Pager 6
1 Deployment Scenario


Section 16 Pager 7
HSXPA/ R99 DEPLOYED IN 1 SHARED FREQUENCY
F1
Layer with R99/ HSxPA

HSxPA capable UE
HSDPA R99 UE
capable UE

This configuration does not require any 3G inter-layer mobility and iMCTA CAC by default to save the R99
call by performing HHO to 2G neighboring cells when necessary.
Concerning Performance aspect, HSXPA throughput could be limited by Power & by
Codes and R99 could potentially be impacted by interference generated during HSXPA activity period.
In term of hardware cost, it is the cheapest one with only 1 E-BBU and 1 H-BBU mandatory.

Section 16 Pager 8
HSXPA AND R99 DEPLOYED IN 2 DEDICATED CARRIERS
Layer with F2 HSDPA / HSUPA

capable UE
HSDPA / HSUPA
Traffic Segmentation feature (UA4.2)

launched at RRC connection establishment
Or iMCTA feature
(Intelligent MultiCarrier Traffic Allocation)
F1 R99 UE
R99 Layer

In this configuration, mobiles are spread over the layers:

either by Traffic Segmentation feature (UA4.2) launched at RRC connection establishment: it allows
to separate R99 UEs from R5/R6 UEs. It is not applicable in the case there are 2 layers which are both
HSDPA.
or at RAB assignment by the iMCTA service feature,
or at primary cell change by the iMCTA service feature.
Since HSxPA traffic and R99 traffic separated, neither HSxPA interference in R99 carrier nor HSxPA
Throughput limited by Power are expected.
Concerning capacity, Free codes and power available on layer 1 will not be available for HSXPA traffic
(and vice-versa).
The Hardware requirements are at least 1 H-BBU, 1 E-BBU & 1 TRM (if 1 carrier previously).
Globally, it should be a likely configuration chosen if already 2 dedicated carrier deployed in UA4.2 or
traffic increase.
Interesting U5.0 cell topology for 2 main reasons:
• to avoid R99/ HSXPA cohabitation issue & so safe configuration for R99/HSXPA performance.
• Traffic segmentation usage & avoid bad impact of Compress Mode for static HSxPA UE’s.

Section 16 Pager 9
MIXED HSxPA/ R99 SHARED CARRIER AND R6 HSxPA
DEDICATED CARRIER
Layer with F2 HSDPA / HSUPA

capable UE
HSxPA
F1 R99 UE
Layer with
HSxPA/R99
HSDPA
capable UE
RRC Traffic Segmentation is not possible in this configuration since the system can
not distinguish R6 and R5 HSDPA calls. Therefore, only usage of iMCTA Service is
possible to redirect R6 HSxPA on F2
Moreover, HCS activation is mandatory to select always F1
R99 could be potentially impacted by interference generated during HSxPA activity period and by
Compressed Mode generated at each HSUPA call established on F1.
On contrary, this is an optimum configuration for HSUPA Throughput since no cohabitation between
HSUPA and UL DCH traffic is forecasted.
iMCTA service partitioning is favored vs. load balancing and could lead to waste of resources.
The minimum hardware requirements are at least At least 2 H-BBU, 1 E-BBU & 1 TRM (if 1 carrier
previously).
Globally, this is an expensive UA5.0 Cell Topology which is possible in localized HSDPA hot spots inside
mono-carrier area.
• to reach the best HSUPA Performance (only R6 PS calls on F2)
• to allow R5 HSDPA service continuity in F1 inside mono-frequency area

Section 16 Pager 10
MIXED HSxPA/ R99 SHARED CARRIER AND HSXPA/ R99 SHARED
CARRIER
F2

HSxPA capable UE
R99 UE
HSDPA
capable UE
F1 R99 UE
Layer with
HSxPA/R99
HSDPA
capable UE
RRC Traffic Segmentation is not possible in this configuration since the system can
not distinguish R6 and R5 HSDPA calls. Therefore, only usage of iMCTA Service is
possible to redirect R6 HSXPA on F2.
Moreover, HCS activation is mandatory to select always F1
R99 potentially impacted by interference generated during HSXPA activity period and
by Compressed Mode generated at each HSUPA call established on F1.
R99 PS UL Traffic could degrade HSUPA Throughput.
Load balancing between frequencies is possible for R99 calls.
The minimum hardware requirements are at least 2 H-BBU, 1 E-BBU & 1 TRM (if 1
carrier previously).
This is an expensive UA5.0 Cell Topology interesting for its resource usage
capabilities but no guarantee on the HSUPA Performance.
Therefore no deployment is currently forecasted in UA5.0.

Section 16 Pager 11
DEDICATED R99 CARRIER AND HSxPA/ R99 SHARED CARRIER
R99 UE
F2

HSxPA capable UE
Traffic Segmentation feature (UA4.2)

launched at RRC connection establishment
Or iMCTA feature
(Intelligent MultiCarrier Traffic Allocation)
F1 R99 UE
R99 Layer

This is a scenario foreseen by some customers that wants to expand R99 capacity.
RRC Traffic Segmentation & iMCTA service will be used to redirect the R5+ call on HSDPA layer.
HSxPA throughput could be limited by DL Power limitation or by DL OVSF Code limitation. Therefore, it is
recommended to assess the DL Power Usage & the OVSF Code Usage to activate properly the Dynamic
Code Tree Management.
Load Balancing is triggered to re-direct R99 call when shared carrier is loaded (Red or Yellow color).
The minimum Hardware required is at least 1 H-BBU, 1 E-BBU & 1 TRM (if 1 carrier previously).
This is a probable configuration chosen if high traffic of R99 inside HSxPA/ R99 shared carrier area.
• to use iMCTA load balancing to share R99 load
• Traffic segmentation usage and to avoid bad impact of Compress Mode for static HSxPA UE’s

Section 16 Pager 12
2 BTS Hardware Configuration


Section 16 Pager 13
iCEM architecture (1)
MAC-e
• HARQ decoding
• E-DSC(s) scheduling
• UL Link demodulation/decoding
• DL scheduling PhCH(s)
MAC-hs
• HARQ
• HS-DSCH scheduling
• Link Adaptation (adaptive coding & modulation)
UL
DPCCH(s)
HS-DPCCH(s) UMTS BTS
DL
HS-PDSCH(s) H-BBU
iCEM128
HS-SCCH(s) E-BBU
iTRM MCPA DDM
UL D-BBU
DPCCH(s) iCEM128 D-BBU
E-DPCCH(s)
E-DPDCH(s) H-BBU
iCCM iTRM MCPA DDM
DL iCEM64
E-HICH
E-AGCH
D-BBU D-BBU
E-RGCH xCEM D-BBU D-BBU iTRM MCPA DDM
UL
Associated/R99 DPDCH(s) D-BBU
CEMa
Associated/R99 DPCCH(s) D-BBU
CCH(s)
Digital Shelf Radio Shelf
DL
Associated/R99
DPDCH/DPCCH(s)
CCH(s)

This slide shows the repartition of the roles between BBUs within the CEM boards.
It indicates where the radio links (physical channels) and retransmissions mechanisms (HARQ,
scheduling,…) are managed.
Here is the Node-B HSxPA software mapping architecture:

CEM BBU (H-BBU) with HSDPA software to handle HSDPA radio links
CEM BBU (E-BBU) with HSUPA software to handle E-DCH radio links
CEM BBU (D-BBU) with classical UMTS L1 software to handle the DCHs, the associated HSDPA DCH and
the Cell CCHs.
iCEM 64 has 1 BBUs that can be used as any of the above types.
iCEM 128 has 2 BBUs that can be used as any of the above types.
xCEM has 4 BBUs that can be used as any of the above types.
The CEM alpha can only be used for R99.

Section 16 Pager 14
iCEM architecture (2)
HS-DPCCH
iCEM 64
H-BBU Or iCEM 128
HS-PDSCH(s)
HS-SCCH(s)
E-DPCCH
E-DPDCH iCEM 64
E-BBU
Or iCEM 128
E-HICH
E-AGCH
E-RGCH
iCEM 64
DPCCH / DPDCH
D-BBU Or iCEM 128
Or CEM a
DPCCH & DPDCH
: Dedicated PhCH : Shared PhCH

Local cell allocation for HSUPA

When a local cell has to be configured in HSUPA, the BTS has to allocate the local cell on 3 BBUs:
1 D-BBU for the DCH part
1 H-BBU for the HSDPA part
1 E-BBU for the HSUPA part
Note
In UA5.1, an E-BBU can work only in “shared mode”. The E-BBU is managing 1 LCG (3 cells) on iCEM and 2
LGC (6 cells) on xCEM per NodeB.
• Only 1 iCEM E-BBU per NodeB is supported in UA5.1 in standard configuration

Section 16 Pager 15
E-BBU Capacity on iCEM
iCEM

The iCEM capacity for HSUPA is given by the E-BBU limitation in terms of:
• Maximum number of users = 15
• Maximum number of codes = 3 x ( 2x SF4)
• Throughput at MAC-E level = 2.1 Mbps
Number of cell per BBU = 3
The xCEM capacity for HSUPA is given by the E-BBU limitation in terms of:
• Maximum number of users = 64
• Throughput at air interface = 7.7 Mbps
• Number of Cells = 6
capacity for HSUPA is given by the E-BBU limitation in terms of:

• Maximum number of users
• Throughput
• Number of Cells
le: E-BBU Resources allocation at call admission

Section 16 Pager 16
E-BBU Capacity on xCEM
WARNING
256 CE for DCH

With a max of 128 CE
for sig.
Example: if 64 DCH
Nb CE = 256 – 64
=192 CE for HSDPA
Limited before
in the previous release

This feature introduces support for multi-mode Base-band Units (BBU) on the xCEM module.
Multi-mode is understood as support of DCH + HSDPA + HSUPA channel types by the same BBU.
This includes support of channel combinations {HSD+HSU}, {DCH+HSD}, {DCH+HSU}, and
{DCH+HSD+HSU} for a given user.
Multi-mode support includes the change from triple to single decoding.
The xCEM board supports 256 DCH, with any 128 of them supporting HSDPA and/or HSUPA.
This means that the initial xCEM capacity will be doubled with this feature by means of a SW upgrade.
The additionally available capacity can be activated through the Capacity Licensing mechanism and
requires purchase of respective licenses.

Section 16 Pager 17
xCEM HSPA capacity evolutions on 2 carriers
xCEM configuration example Strategy : STSR 2, 2xCEM, 2 carriers HSDPA + E-DCH

The feature increases HSPA capacity and performance, in particular
the Queuing Delay, if many HSUPA users want to become active at the same time
the number of HSUPA users supported per cell
the performance for HSDPA traffic that does not conform to FTP/HTTP, in particular for traffic with very
low packet sizes.
This will become essential for VoIP traffic in a future release.
For HSUPA,
the MAC-e scheduler on the xCEM supports at least 2 E-AGCH channels per cell – target
is 48 E-AGCH channels per xCEM board.
the Node B supports at least 4 E-HICH Channelization codes per cell.
The Node B provides a signature administration for 40 signatures per E-HICH channelization code.
A pre-defined number of 1..4 signatures will be reserved for common E-RGCH usage, the remainder is
available for dedicated E-RGCH/E-HICH usage on each E-HICH Channelization code.
For HSDPA,
the xCEM will support 4 HS-SCCH channels per cell (24 HS-SCCH channels per board).

Section 16 Pager 18
HSUPA UE Categories SF2 and 2ms TTI
E-DCH Maximum Minimum Support for 10 Maximum number Maximum number of

category number of E- spreading and 2 ms TTI E- of bits of an E-DCH bits of an E-DCH
DCH codes factor DCH transport block transport block
Transmitted transmitted within transmitted within a
a 10 ms E-DCH TTI 2 ms E-DCH TTI
Category 1 1 SF4 10 ms TTI 7110

only
Category 2 2 SF4 10 ms and 14484 2798

2 ms TTI

only

2 ms TTI

only

2 ms TTI

In UA7.1 SF2 and 2msTTI are supported only by the xCEM (UE categories 4, 5 and 6 are
supported)whereas the iCEM board keep the same capabilities as in UA5.
In term of bit rate, we can expect a maximum MAC-e throughput of:
• 2.0 Mbits/s for TTI = 10 ms
And a maximum RLC throughput of:
o Category 3: 1380 kb/s
• 5.76 Mbits/s for TTI = 2 ms
And a maximum RLC throughput of:

Section 16 Pager 19
3 HSUPA power Control


Section 16 Pager 20
3 HSUPA power Control
E-DCH signaling channels Power Control
The power control for AGCH is based on CQI

In UA5.1.1 AGCH Power
HS-DSCH E-DCH Control based on CQI
DL Data Transfer UL Data Transfer (PS I/B)
(PS I/B)
RNC
Iub
HS-DPCCH
E-AGCH Feedback Information
Absolute Grant (CQI)
The final AGCH Tx power = E-DCH reference Tx power + eagchPowerOffSet (OMC-B)

The E-DCH reference Tx power is given by a hard-coded LUT using the CQI

The power control for AGCH is based on CQI

The AGCH is only sent by the serving radio leg
Since HS-DSCH is the DL RB for HSUPA ⇒ CQI is always available
Fast update period (each CQI)
The final AGCH Tx power PAGCH is then given by

PAGCH = PEDCH base + eagchPowerOffSet (OMC-B)
The reference Tx power is given by a hard-coded Look Up Table using the CQI and the mean square error
of the CQI, i.e.
PEDCH base = LUT(CQI, MSE(CQI))+PCPICH+Γ-mean(CQI)+∆
The MSE takes the channel variations into account
∆ is set to +3 dB in UA05.1
The OMC-B parameter eagchPowerOffset allows further control of the Tx power
This offset is a positive or negative constant offset across all CQI values
The parameter range is from –45 dB to +65 dB

Section 16 Pager 21
Answer the Questions
1. What is the minimum number of BBUs to be present on a BTS to activate HSUPA ?
2. Which is the physical channel used to control the EDPCCH and EDPDCH power?
3. What is the maximum number of simultaneous EDCH active users on E-BBU?


Section 16 Pager 22
End of Module


Section 16 Pager 23
Last But One Page
1 All Rights Reserved © Alcatel-Lucent @@YEAR

@@PRODUCT
@@COURSENAME
All Rights Reserved © Alcatel-Lucent @@YEAR

@@COURSENAME - Page 1
All rights reserved © Alcatel-Lucent @@YEAR
Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent
All Rights Reserved © Alcatel-Lucent @@YEAR
@@COURSENAME - Page 2

Tmo18247d0sgdeni2 0

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tmo18247d0sgdeni2 0

Caricato da

Copyright:

Formati disponibili

9300 WCDMA

TMO18247 9300 WCDMA UA07

All Rights Reserved © Alcatel-Lucent 2010

All rights reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

All rights reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

3 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

TMO18247 9300 WCDMA UA07 HSxPA Radio Principles

All Rights Reserved © Alcatel-Lucent 2010

About This Course 4. Topic/Section is Positioned Here

1. Topic/Section is Positioned Here 6. Topic/Section is Positioned Here

2. Topic/Section is Positioned Here

3. Topic/Section is Positioned Here

5 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

6 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

Welcome to TMO18247 9300 WCDMA UA07 HSxPA Radio Principles

Upon completion of this course, you should be able to:

describe the evolution of 3G system with HSDPA / HSUPA describe UTRAN

7 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

8 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

9 All Rights Reserved © Alcatel-Lucent 2010

Where you can get further information

If you want further information you can refer to the following:

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

10 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Did you meet the following objectives ?

Yes (or No (or

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

Yes (or No (or

12 All Rights Reserved © Alcatel-Lucent 2010

Thank you for your answers to this questionnaire

All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

12 All Rights Reserved © Alcatel-Lucent 2010

Edition Date Author Remarks

01 YYYY-MM-DD Last name, first name First edition

02 2010-05-12 Nolan, Vincent Update to UA07

All Rights Reserved © Alcatel-Lucent 2010

This section will enable you to

13 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

14 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

15 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

16 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

17 All Rights Reserved © Alcatel-Lucent 2010

12 All Rights Reserved © Alcatel-Lucent 2010

13 All Rights Reserved © Alcatel-Lucent 2010

14 All Rights Reserved © Alcatel-Lucent 2010

15 All Rights Reserved © Alcatel-Lucent 2010

16 All Rights Reserved © Alcatel-Lucent 2010

17 All Rights Reserved © Alcatel-Lucent 2010

18 All Rights Reserved © Alcatel-Lucent 2010

19 All Rights Reserved © Alcatel-Lucent 2010

1 10 All Rights Reserved © Alcatel-Lucent 2010

1 11 All Rights Reserved © Alcatel-Lucent 2010

1 13 All Rights Reserved © Alcatel-Lucent 2010

1 14 All Rights Reserved © Alcatel-Lucent 2010

1 15 All Rights Reserved © Alcatel-Lucent 2010

1 16 All Rights Reserved © Alcatel-Lucent 2010

1 17 All Rights Reserved © Alcatel-Lucent 2010

1 18 All Rights Reserved © Alcatel-Lucent 2010

1 19 All Rights Reserved © Alcatel-Lucent 2010

1 21 All Rights Reserved © Alcatel-Lucent 2010

1 22 All Rights Reserved © Alcatel-Lucent 2010

22 All Rights Reserved © Alcatel-Lucent 2010

23 All Rights Reserved © Alcatel-Lucent 2010

24 All Rights Reserved © Alcatel-Lucent 2010