SF012249 Architecture Support of HSDPA

8/9/2019 SF012249 Architecture Support of HSDPA

1/165

UTRAN

Feature Description

Radio Subsystem

Support of HSDPAFD012249 - UMR5.0

A50016-G5000-Z180-3-7618ND-59083-180(E)-03


2/165

2Siemens AG: A50016-G5000-Z180-3-7618NEC Corporation: ND-59083-180(E)-03


Feature DescriptionRadio Subsystem

f Important Notice on Product SafetyDANGER - RISK OF ELECTRICAL SHOCK OR DEATH - FOLLOW ALL INSTALLATION INSTRUCTIONS.

The system complies with the standard EN 60950 / IEC 60950. All equipment connected to the system must

comply with the applicable safety standards.

Hazardous voltages are present at the AC power supply lines in this electrical equipment. Some components may

also have high operating temperatures.

Failure to observe and follow all installation and safety instructions can result in serious personal injury

or property damage.

Therefore, only trained and qualified personnel may install and maintain the system.

The same text in German:

Wichtiger Hinweis zur Produktsicherheit

LEBENSGEFAHR - BEACHTEN SIE ALLE INSTALLATIONSHINWEISE.

Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Alle an das System angeschlossenen

Gerte mssen die zutreffenden Sicherheitsbestimmungen erfllen.

In diesen Anlagen stehen die Netzversorgungsleitungen unter gefhrlicher Spannung. Einige Komponenten

knnen auch eine hohe Betriebstemperatur aufweisen.

Nichtbeachtung der Installations- und Sicherheitshinweise kann zu schweren Krperverletzungen oder

Sachschden fhren.

Deshalb darf nur geschultes und qualifiziertes Personal das System installieren und warten.

Caution:

This equipment has been tested and found to comply with EN 301489. Its class of conformity is defined in tableA30808-X3247-X910-*-7618, which is shipped with each product. This class also corresponds to the limits for a

Class A digital device, pursuant to part 15 of the FCC Rules.

These limits are designed to provide reasonable protection against harmful interference when the equipment is

operated in a commercial environment.

This equipment generates, uses and can radiate radio frequency energy and, if not installed and used in accor-

dance with the relevant standards referenced in the manual Guide to Documentation, may cause harmful inter-

ference to radio communications.

For system installations it is strictly required to choose all installation sites according to national and local require-

ments concerning construction rules and static load capacities of buildings and roofs.

For all sites, in particular in residential areas it is mandatory to observe all respectively applicable electromagnetic

field / force (EMF) limits. Otherwise harmful personal interference is possible.

Trademarks:

All designations used in this document can be trademarks, the use of which by third parties for their own purposes

could violate the rights of their owners.

Copyright (C) Siemens AG / NEC Corporation 2005.

Issued by:

Siemens AG, Communications, Hofmannstrasse 51, 81359 Mnchen, Germany and

NEC Corporation, 7-1, Shiba 5-chome, Minato-ku, Tokyo, Japan

Technical modifications possible.

Technical specifications and features are binding only insofar as they are specifically and expressly agreed upon in a wri tten contract.


3/165



Siemens AG: A50016-G5000-Z180-3-7618NEC Corporation: ND-59083-180(E)-03 3

Reason for Update

Summary:Mounting limitation taken into account: HSPRLC and PRLC can not be colocated in the

PRM module.

Details:

Chapter/Section Reason for Update

2.1.3.2 Chapter New HSPRLC Card.

Mounting limitation changed to: HSPRLC and

PRLC can not be colocated in the PRM module.

Issue History

IssueNumber

Date of issue Reason for Update

1 04/2005 First issue for new release.

2 08/2005 HSDPA cell configurations for NB-580 have been

added. The power reduction for 16QAM is no longer

required to achieve 3GPP-compliancy. HSDPA UE

Differentiation and Restriction Control for PS

Bearers are no longer part of this feature but sepa-

rate features (FD012254 and FD012255, respec-

tively). eqp, bldp d2, and atrk HMI commands

added to section Modified CLI Commands (RNC).

Editorial changes.

3 08/2005 Mounting limitation taken into account: HSPRLC and

PRLC can not be colocated in the PRM module.


4/165





5/165




This document consists of 165pages. All pages are issue 3.

Contents

1 Short Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.1 In General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2 Customer Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.3 Interworking / Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.4 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Modifications in the RNC Hardware and Software Architecture . . . . . . . . . 13

2.1 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.1 HSDPA Protocol Stack in UTRAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.2 HSDPA Traffic Within the RNC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.3 New/Modified RNC Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.3.1 New HSDST Card. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.1.3.2 New HSPRLC Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.1.3.3 Modified WLSC Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.1.3.4 Modified CMUX/CMUXE Firmware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.1.4 HSDST Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.1.4.1 MAC-d. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.1.4.2 HS-DSCH Frame Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.1.4.3 HS-DSCH DATA FRAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.1.4.4 HS-DSCH CONTROL FRAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.1.4.5 Handling of the Initial Capacity Allocation IE . . . . . . . . . . . . . . . . . . . . . . . 24

2.1.4.6 Internal FP (HSDPA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.1.5 HSPRLC Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.1.5.1 IP/UDP/GTP-U . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.1.5.2 Packet Data Convergence Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.1.5.3 Radio Link Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.1.5.4 Internal FP and Internal FP (HSDPA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.2 Functional Split . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.3 Man-Machine Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.4 Operating the Feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3 Modifications in the Node B Hardware and Software Architecture. . . . . . . 27


3.1.1 Modifications of the Node Bs Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . 333.1.1.1 CHC96 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1.1.2 hs-CHC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1.2 Modifications of Radio Frequency (RF) Issues . . . . . . . . . . . . . . . . . . . . . . 35

3.1.3 Modifications of Call Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.1.4 Modifications of the Transport on the Iub Interface and the Priority QueueManagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.1.4.1 Interworking Between RNC and Node B. . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.1.4.2 UTOPIA Connection Handling on the CC-BB Interface . . . . . . . . . . . . . . . 37

3.1.5 The MAC-hs Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.1.5.1 Handling of Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.1.5.2 Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
http://-/?-http://-/?-


6/165


7/165




4.1.2.5 Inward Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.1.2.6 Change of the Serving HS-DSCH Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

4.1.2.7 Outward Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

4.1.2.8 DRNC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994.1.2.9 Error Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

4.1.2.10 UE Differentiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

4.1.3 HSDPA Admission Control and Congestion Control. . . . . . . . . . . . . . . . . 102

4.1.3.1 Radio Resource Management (RRM) Issues . . . . . . . . . . . . . . . . . . . . . . 102

4.1.3.2 Load, Power, and Code Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

4.1.3.3 Admission Control in the CRNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

4.1.3.4 Restriction Control in the CRNC for HSDPA. . . . . . . . . . . . . . . . . . . . . . . 107

4.1.3.5 Admission Control in the Node B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

4.1.3.6 Congestion Control Algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

4.1.3.7 Integration of the Admission Control Algorithm for HSDPA . . . . . . . . . . . 109

4.1.4 HSDPA Code and Power Allocation and Redimensioning . . . . . . . . . . . . 1104.1.4.1 State Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

4.1.4.2 Common Measurements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

4.1.4.3 Code and Power Allocation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

4.1.4.4 Modification and Deletion of HSDPA Resources . . . . . . . . . . . . . . . . . . . 120

4.2 Functional Split . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

4.2.1 HSDPA RAB Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

4.2.2 HSDPA Mobility Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121


4.2.4 HSDPA Code and Power Allocation and Redimensioning . . . . . . . . . . . . 121

4.3 Man-Machine Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

4.3.1 HSDPA RAB Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

4.3.2 HSDPA Mobility Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123


4.3.4 HSDPA Code and Power Allocation and Redimensioning . . . . . . . . . . . . 125

4.4 Operating the Feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

5 Modifications within UTRAN Operation and Maintenance . . . . . . . . . . . . 126

5.1 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

5.1.1 RNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

5.1.1.1 Equipment Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

5.1.1.2 Transport Network Layer Management . . . . . . . . . . . . . . . . . . . . . . . . . . 128

5.1.1.3 Radio Network Layer Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

5.1.1.4 Optional Feature Handling Within the RNC . . . . . . . . . . . . . . . . . . . . . . . 131

5.1.2 Node B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

5.1.2.1 Equipment Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

5.1.2.2 Transport Network Layer Management . . . . . . . . . . . . . . . . . . . . . . . . . . 134

5.1.2.3 Radio Network Layer Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

5.1.2.4 Optional Feature Handling Within the Node B . . . . . . . . . . . . . . . . . . . . . 134



5.3.1 Impacts on the RC GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

5.3.2 Impacts on the LMT-RNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1375.3.2.1 New CLI Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137


8/165




5.3.2.2 Modified CLI Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

5.3.2.3 New Output Messages at the LMT-RNC . . . . . . . . . . . . . . . . . . . . . . . . . . 142

5.3.2.4 Modified Output Messages at the LMT-RNC. . . . . . . . . . . . . . . . . . . . . . . 142

5.3.3 Impacts on the LMT-Node B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1435.3.4 OAM Tool Set (OTS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

5.3.4.1 Extensions for South-Bound Import Operations and OTS Core . . . . . . . . 144

5.3.4.2 Extensions for South-Bound Export Operations . . . . . . . . . . . . . . . . . . . . 145

5.3.4.3 Consistency Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

5.3.4.4 Extensions for North-Bound Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

5.4 Operating the Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

6 Transport Network Layer (TNL) Modifications . . . . . . . . . . . . . . . . . . . . . . 147


6.1.1 Flow Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

6.1.1.1 Priority Queue Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

6.1.2 QoS Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148




7 Air Interface (Uu) Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150


7.1.1 Changes on the Uu Interface Layer 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151



7.1.3.1 Impacts on the Radio Resource Control (RRC) Protocol. . . . . . . . . . . . . . 152

7.1.3.2 Identification of a UEs 3GPP Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

7.1.3.3 Impacts of 3GPP Rel 5 on Previously Supported Features . . . . . . . . . . . . 155

7.1.3.4 RRC Error Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156




8 HSDPA Performance Measurement Counters. . . . . . . . . . . . . . . . . . . . . . 157





9 Operating HSDPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

10 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162


9/165




1 Short DescriptionThis chapter serves as short introduction to the High Speed Downlink Packet Access

(HSDPA) feature. The chapter is subdivided into the following sections:

In General

Customer Benefits

Interworking / Dependencies

Prerequisites

1.1 In General

Within UMTS, the acceptance of mobile data services strongly relies on high data

throughputs, high user peak rates with minimum delay. HSDPA (High Speed Downlink

Packet Access) is the breakthrough UMTS feature-set which satisfies highest capacity

demands thus providing the prerequisite for broadband services.

HSDPA is specified in the 3GPP Release 5 Standard. On the downlink, the HSDPA

standard implemented in UMR5.0 refers to a shared control channel (HS-SCCH) and a

shared data-bearing channel (HS-DSCH). The data-bearing channel is known as HS-

DSCH. Key characteristics of HSDPA are:

A downlink only service, the uplink service remains unchanged.

A packet data service. The network allocates resources for transmitting packets over

the air.

Typical achievable throughput rates are in the range of 1 5 Mbit/s.

The HSDPA key principles are:

Scheduling in the time domain (2 ms) and code domain (15 parallel codes) . This

reduces latency and improves the peak rate.

Adaptive Modulation and Coding (QPSK and 16 QAM) which leads to higher data

rates.

Hybrid ARQ which leads to higher efficiency in transmission and error correction.

HARQ (Hybrid Automatic Repeat Request) is an implicit link adaptation technique. In

HARQ, link layer acknowledgements are used for retransmission decisions. For

HSDPA, HARQ is performed by the MAC-hs protocol situated in the Node Bs and UEs,

where the latter deal with the main processing load.

The downlink transport channel for HSDPA is the HS-DSCH that is mapped to up to 15

HS-PDSCHs. The uplink channel is the HS-DPCCH which carries the feedback informa-

tion from each HSDPA-capable UE in the active set.

HSDPA terminal capabilities extend from 0.9 Mbit/s up to 14 Mbit/s. The HSDPA capa-bility is independent of Rel 99-based capabilities. If the HS-DSCH has been configured

for the terminal, however, the DCH capability in DL is limited to the value provided by

the terminal.

HSDPA Mobility

The High Speed Downlink Shared Channel (HS-DSCH) is a common transport channel

that is shared by several UEs in the same cell. The MAC-hs functionality of the Node B

performs scheduling of UEs on a per cell basis. Therefore, the UE receives the HS-

DSCH of one cell and can receive DCHs of multiple cells.


10/165


11/165




Modifications within UTRAN OAM

The following HSDPA-specific items cause modifications of the UTRAN OAM area:

New cards supporting HSDPA.

RNC: HSDST and HSPRLCNode B: HS-CHC and CHC96 (only new SW)

The packet scheduler for HSDPA data traffic is situated in the Node B, whereas the

scheduler for Rel 99 data is still in the RNC.

New transport channel HS-DSCH to carry user data

Users are time-multiplexed and code-multiplexed on this channel to free resources

during silent periods.

Control signaling on shared channel (HS-SCCH) that is common to a set of UEs

making use of HSDPA. In the HSDPA-capable Node Bs, the number of HS-SCCHs

can vary in the range of one to four channels per cell.

Configuration of new UTRAN HSDPA cells

New parameters for Radio Bearer Control, Admission Control, Power/Code settings,

new Measurement Control for Mobility Handling and HSDPA measurements with

RNC-wide scope.

Configuration of transport flow control, required for HSDPA

In order to fulfill complete Equipment Management, Transport Network Layer Manage-

ment, and Radio Network Layer Management, additional Operations & Maintenance

features have been implemented for all UTRAN elements supporting HSDPA (eRNC,

mixed configuration eRNC/cRNC, NB-420, NB-440, NB-441, NB-580, NB-860, NB-880,

NB-881, NB-341, RS-880, RS-381).

The Info Models and the Databases of all network elements have been adapted to HSD-

PA with additional enhancements to the Radio Commander, LMTs, and OTS.

New HMI commands are supplied in order to configure the new HSDST- and HSPRLC-cards. HSDST and HSPRLC cards can be associated with speech path equipment. New

HMI commands are therefore implemented to modify existing speech path equipment

with regard to HSDST and HSPRLC configuration.

New performance measurements have been developed and existing Rel 99 measure-

ments have been significantly enhanced.

HSDPA performance measurements will only be carried out in cells which are capable

of providing HSDPA services. With UMR5.0, the HSDPA standard (3GPP Rel 5) will be

supported for the first time. A new Managed Object Class is therefore introduced with

UMR5.0, the HSDPA Cell.

Transport Network Layer (TNL) modificationsWith HSDPA, the 3GPP principle of keeping Radio Network Layer (RNL) and Transport

Network Layer (TNL) independent of each other is also valid. However, introducing

HSDPA affects the TNL by the higher capacity demands of the air interface. The higher

system capacity with HSDPA also allows both higher data rates per user and many more

users per cell. Therefore, the Iub transport capacity demands will increase accordingly.

The transport channel HS-DSCH is used for interactive and background traffic classes.

Requirements apply for low delay and delay variation. The HS-DSCH is not used for

conversational traffic class which has stringent delay requirements. Real-time require-

ments for the transport of the HS-DSCH over Iub interfaces may be lower than for the

transport of all other channels. Therefore 3GPP TS highly recommends a separation of

HSDPA traffic from other CS traffic. Because of the bursty nature of HSDPA traffic in


12/165




combination with unknown traffic volume, the QoS of all traffic on the same AAL type 2

path may decrease.

Air Interface (Uu) modifications

The Node B has implemented the HSDPA MAC-hs protocol, which is responsible for

scheduling between terminals (UEs). Adaptive Modulation and Coding (AMC) and man-

agement of data queues for each UE are some of the new air interface functionalities of

the Node B.

1.2 Customer Benefits

With UMR5.0 making use of HSDPA services, the mobile phone subscriber will experi-

ence an improvement of QoS compared to Release 99 UMTS services. The improve-

ments become apparent in terms of:

Peak data rate

Average data rate (i.e. packet call throughput) Lower latency for interactive and background services

Higher availability of high data rate services

Network Operators will benefit from utilizing UMR5.0 with:

Lowest CAPEX for system capacity increase compared to other capacity-improving

technologies such as smart antennas or the installation of new Node Bs. With

UMR5.0, the Operator's costs per bit will be minimized.

Higher system throughput, i.e. more throughput per cell due to a higher Node B ca-

pacity. The Node Bs increased capacity leads to more users and, consequently,

more data throughput per square kilometer.

Higher benchmarking of UMR5.0 operators compared to Rel 99 and existing 2.5G

Operators, which already offer data rates up to 384 kbit/s today. Enabling of new billing categories, such as mobile flat rates combined with high peak

rates in order to compete with fixed network services like DSL.

Competition with WLAN operators via outdoor coverage, security advantage, and

mobility rather than indoor competition.

Higher performance (factor 3) than CDMA2000 systems (especially important for

Asian and US Markets).

1.3 Interworking / Dependencies

The introduction of HSDPA has a design impact on all UTRAN network elements. Net-

work Management systems have to be adapted as well as terminals which have to bespecially designed for HSDPA purpose.

Dynamic allocation of AMR traffic and HSDPA traffic will coexist. Customers will not ex-

perience significant degradations of conventional Rel 99 services by introducing

HSDPA. Since Rel 99 users and HSDPA users share the channelization code tree, a

degradation may occur if Rel 99 users run out of codes. The number of AMR users will

not be affected after UMR5.0 implementation.

1.4 Prerequisites

UEs have to be HSDPA-compliant. UE categories will specify the modulation scheme

supported and its throughput more precisely.


13/165




2 Modifications in the RNC Hardware and Soft-

ware Architecture

2.1 Functional Description

The High Speed Downlink Packet Access (HSDPA) feature enables downlink packet

transmission rates up to 14 Mbit/s on the radio interface, which may coexist with the cur-

rent Rel 99 services. The PRLC and DHT cards of the current RNC HW do not have suf-

ficient capacity to support the peak rate of HSDPA. Therefore, new hardware (HSDST,

HSPRLC) and a new transport channel (HS-DSCH) have been introduced to enable the

throughput of higher peak data rates compared to Rel 99 data rates. The HSDST card

supports the MAC-d entity and HS-DSCH frame protocol (FP), thus providing higher

throughput than the current DHT card (see 2.1.4 "HSDST Functionality"for details). The

HSPRLC card provides PRLC functionality with a higher throughput (see

2.1.5 "HSPRLC Functionality"for details).

2.1.1 HSDPA Protocol Stack in UTRAN

The protocol stack of HSDPA in UTRAN (see Fig. 2.1)introduces the HS-DSCH FP (as

specified in the 3GPP TS 25.435, Iub Interface User Plane Protocols for COMMON

TRANSPORT CHANNEL Data Streams) which performs the flow control taking into ac-

count the throughput between the UE and the RNC. It controls transmission delay and

data discarding in UTRAN by adjusting the transmission rate at the Iub interface to the

transmission rate at the Uu interface. The HS-DSCH FP is used by the Node B to inform

the RNC about the permitted transmission rate at the Uu interface. The RNC performs

data transfer at the transmission rate specified by Node B.

Fig. 2.1 Protocol stack of HSDPA for UTRAN

RLC

PDCP

ATM

AAL2MAC-hs

RLC

PDCP

MAC-hs

ATM

AAL2

ATM

AAL5

GTP-U

UDP

UE Node B RNC

Uu Iub Iu

Phy. Phy.Phy.

HS-DSCHFP

Phy.Phy.

HS-DSCHFP

MAC-dIP

MAC-d


14/165




2.1.2 HSDPA Traffic Within the RNC

Fig. 2.2summarizes the HSDPA traffic routed through different cards within the RNC.

Fig. 2.2 Cards and traffic routes for HSDPA

RNC

Iu

GMUX

M2C PRLC

MHC DHT HSDST

HSPRLC

DTI/

MDTI

DCCH DTCH(PS)

DCCH onFACH/RACH

DTCH on

FACH/RACH

DCCH onDCH

DTCH

on DCH

To/From Iub Interface

Iub Interface

DTCH (UL)

on A-DCH

DTCH (DL)

on HS-DSCH

Iub

CMP/WCMP

CLP

E1-IMA

E1-IMA

E1E1E1

TINFfor Iub

STM-1/OC-3

DTCH (DL) on HS-DSCH

DTCH (UL) on A-DCH

DTCH on DCH (HS-DSCH to DCH)

DCCH on DCH

DTCH on FACH/RACH (HS-DSCH to FACH)

DCCH on FACH/RACH


15/165




In addition to Fig. 2.1, the protocol stack of each card on the HSDPA traffic route within

the RNC is shown in Fig. 2.3.

Fig. 2.3 Protocol stack within the RNC on HSDPA traffic route

2.1.3 New/Modified RNC Hardware

HSDPA support comprises the following changes to the RNC HW (see Fig. 2.4):

New HSDST Card

New HSPRLC Card

Modified WLSC Firmware

Modified CMUX/CMUXE Firmware

iNOTEIf E1/J1/T1-IMA (8 lines of 2 Mbit/s each) is used for Iub physical lines, the peak rate of

RAB is restricted to less than 12 Mbit/s on the RLC Layer. If the peak rate of 14 Mbit/sis required, STM-1/OC-3 should be used for Iub physical lines. See chapter 6 "TransportNetwork Layer (TNL) Modifications"for details.

ATM

AAL2

ATM

AAL2-d

Iub Iu

CMP/WCMP

RNC

GMUX

UDP

HSDST

ATM

AAL2-d

ATM

AAL2-d

HSPRLC

ATM

AAL5

IPMAC-dHS-DSCH

Internal

FP

FP

(HSDPA)

ATM

AAL2-d

InternalFP

(HSDPA)

GTP-U

RLC

PDCP

UDP

ATM

AAL5

IP

GTP-U

UDP

ATM

AAL5

IP

GTP-U


16/165




Fig. 2.4 Frame layout of RNC with new/modified cards (examples)

Regarding the frame layout of a certain model unit two scenarios are supported

(see Fig. 2.5): Update of existing equipment

New delivery of equipment

cRNC/eRNC eRNC

E-CCPM

FAN

FAN

D-CCPM

Fuse

FAN

C-DHTM C-DHTM

FAN

Fuse

FAN

FAN

GTPM

Fuse

B-SIGM C-M2CM

B-MHM C-CMPM

D-CMPM

B-LSF C-TRKF A-PRF

D-CMPM A-PRM (Extended)

A-PRM (Extended)

FAN

B-SIGM C-M2CM

FAN

PDM

B-MHM C-DHTM

C-GTPM

H-TRKF

A-DTIM

E-CCPM

FAN

FAN

D-CCPM

PDM

D-LSF

WLSC CMUX/CMUXE HSPRLCHSDST

B-LSM C-LSM

A-PRM (Basic)

B-PRM

Modified Firmware New Hardware


17/165




Fig. 2.5 Frame layout of RNC (example) with new HW for update and new delivery

FAN

SIGM M2CM

FAN

PDM

B-MHM C-DHTM

C-GTPM B-PRM

H-TRKF

A-DTIM

E-CCPM

FAN

FAN

C-LSM

D-CCPM

PDM

D-LSF

WCMP

FAN

A-HUBM

FAN

PDM

B-MHM C-DHTM

H-TRKF

New delivery of equipment: 2 x HSDST + 4 x HSPRLC

FAN

SIGM M2CM

FAN

PDM

B-MHM C-DHTM

C-GTPM B-PRM

H-TRKF

A-DTIM

E-CCPM

FAN

FAN

C-LSM

D-CCPM

PDM

D-LSF

WCMP

FAN

A-HUBM

FAN

PDM

B-MHM C-DHTM

B-PRM

H-TRKF

Update of existing equipment: 2 x HSDST + 2 x HSPRLC

C-PRM

HSPRLCHSDST


18/165




In addition to the new hardware modified FW is necessary:

Modified WLSC FW for controlling HSDST cards (see Fig. 2.6)

Modified CMUX/CMUXE FW for controlling HSPRLC cards (see Fig. 2.7)

Fig. 2.6 C-LSM face layout of eRNC (example) with new HW and FW-update

025 035 045 055 065 075 085 095 115 125 135 145 155 165 175 185 195 205 215 225 235 255105 245

HUBIU#0

TINF#00

TINF#01

TINF#02

blank#03

TINF#04

TINF#05

TINF#06

TINF#07

TINF#08

TINF#10

TINF#11

TINF#12

TINF#13

blank#14

blank#15

blank#16

blank#17

HSDST#18

blank#20

blank#21

WCMP#22

WCMP#23

blank#24

blank#25

blank#26

blank#27

WCMP#28

WCMP#29

WCMP#30

WCMP#31

HUBIU#1

CLKD#1

CLKD#0

WLSC#1

LSW#

0

LSW#

1

HSDST#19

TINF#09

CLKD#0

WLSC#0

WLSC HSDST


19/165




Fig. 2.7 A-PRM/B-PRM/C-PRM face layout (examples) with new HW and FW-update

01 02 07 08 11 12 13 14 16 18 19 20 21 22 2409 23 25171503 04 05 06 26 27 28 29 3130 32

HUBIU#0

HUBIU#1

C1HWM#0

C1HWM#1

HSPRLC0

HSPRLC1

Blank

Blank

Blank

Blank

Blank

Blank

CMUXE#0

ReinforcingPlate

Blank

Blank

10 33

Blank

Blank

CMUXE#1

01 02 07 08 11 12 13 14 1609 1503 04 05 06

CMUX#0

HSPRLC1

10

HUBIU0

CMUX#1

C1HWM00

C1HWM01

HUBIU1

HSPRLC0

01 02 07 08 11 12 13 14 1609 1503 04 05 06

CMUX#0

10

CMUX#1

C1HWM00

C1HWM01

A-PRM (Extended)

B-PRM C-PRM

Blank

Blank

Blank

Blank

Blank

Blank

Blank

Blank

Blank

Blank

Blank

HSPRLC1

HSPRLC0

Blank

Blank

Blank

Blank

Blank

Blank

Blank

Blank

Blank

CMUX/CMUXE HSPRLC


20/165




2.1.3.1 New HSDST Card

Specification

RNC SW compatibility

The HSDST card is not backward-compatible, RNC SW release UMR5.0is mandatory.

Mounting and limitations

HSDST cards are mounted in the B/C-LSM module (see Fig. 2.6).

The following limitations must be considered:

The four leftmost slots in the lower row in B/C-LSM are reserved for TINF cards.

The HSDST cannot be mounted in these slots.

Dual mode operation is not supported for UMR5.0.

Item Value Remarks

Throughput 160 Mbit/s/card RLC Layer (Total of UL and DL)

Peak rate 14 Mbit/s/ch RLC Layer

Maximum number ofchannels

4000 ch/card

Redundancy Single(0/1) The RNC is always equipped with 2HSDST cards supporting a redundantload-sharing configuration. If a failureoccurs and the required capacity isavailable, the entire traffic load will bedistributed over the other card withoutinterruption of system operation.

Size 294x324 mm (HxW),1 slot

Target Powerconsumption

30 W

Tab. 2.1 HSDST card specification


21/165




2.1.3.2 New HSPRLC Card

Specification

RNC SW compatibility

The HSPRLC card is not backward compatible. RNC SW release UMR5.0is mandatory.

Mounting and limitations

HSPRLC cards are mounted in the A-PRM, B-PRM, and C-PRM module (see Fig. 2.7).

The following limitations must be considered:

HSPRLC and PRLC can not be colocated in the PRM module.

HSPRLC cards can be mounted in the locations shown in Fig. 2.7, using the PRLC

slots. It is, however, not advisable to fully populate a PRM with HSPRLC cards, as

their combined throughput will exceed the capacity of the CMUX/CMUXE (approxi-

mately 120 Mbit/s in RLC Layer).

2.1.3.3 Modified WLSC Firmware

WLSC cards are mounted in the C-LSM (eRNC) module (see Fig. 2.6). The modified

WLSC FW for controlling HSDST cards can be downloaded from either LMT-RNC or RC

using HMI commands. As regards B-LSM modules (cRNC), BLSC cards must be re-

placed by WLSC cards, resulting in a cRNC/eRNC mixed configuration.

2.1.3.4 Modified CMUX/CMUXE Firmware

The CMUX/CMUXE cards are mounted in A-PRM, B-PRM, and C-PRM modules

(see Fig. 2.7). The modified CMUX/CMUXE FW for controlling HSPRLC and PRLC

cards can be downloaded from either LMT-RNC or RC using HMI commands.

Item Value Remark

Throughput 20 Mbit/s/card RLC Layer (Total of UL and DL)

Peak rate 14 Mbit/s/ch RLC Layer

Maximum number ofchannels

2016 ch/card

Redundancy Single

Size 294x324 mm (HxW),2 slots

Target power con-sumption

50 W

Tab. 2.2 HSPRLC card specification


22/165




2.1.4 HSDST Functionality

The HSDST card only deals with HSDPA traffic. Unlike with the DHT card, Diversity

Handover functionality is not provided as it is not specified in HSDPA. The HSDST card

provides the functions listed below: U-Plane protocol handling with regard to:

MAC-d

HS-DSCH Frame Protocol

Internal FP (HSDPA)

Traffic monitoring:

Monitoring the number of transmitting MAC-d PDUs

2.1.4.1 MAC-d

The MAC-d protocol provides the following functions:

Data transfer

Mapping between logical channels and transport channels

The MAC-d PDU is generated from the RLC-PDU carried by the Internal FP (HSDPA)

protocol from the HSPRLC card. When MAC-d multiplexing is performed, the C/T field

is then added. However, MAC-d multiplexing (C/T multiplexing) is not supported.

2.1.4.2 HS-DSCH Frame Protocol

The HS-DSCH frame protocol (FP) has the following functions:

Data transfer

Flow control

Flow control is performed when the HS-DSCH DATA FRAME message is transmitted.

Upon receipt of the CAPACITY ALLOCATION message (sent from the Node B to the

RNC) and upon transmission of the CAPACITY REQUEST message (sent from the

RNC to the Node B) the transmission rate is adjusted. The maximum transmission rate

is determined by the CAPACITY given by the CAPACITY ALLOCATION message.

See 6 "Transport Network Layer (TNL) Modifications"for details about the HS-DSCH FP

and the flow control mechanism.

2.1.4.3 HS-DSCH DATA FRAME

The HS-DSCH DATA FRAME message is used to transmit MAC-d PDUs from the RNC

to the Node B.

The transmitting interval of the HS-DSCH DATA FRAME message is defined by the fol-

lowing IEs in CAPACITY provided by the Node B.

Maximum MAC-d PDU length

HS-DSCH Credits

HS-DSCH Interval

The minimum transmitting interval is about 2 ms. Tab. 2.3shows the HS-DSCH DATA

FRAME Header IE allowed by the HSDST.


23/165




2.1.4.4 HS-DSCH CONTROL FRAME

Handling of CAPACITY ALLOCATION message

The transmitting rate of HS-DSCH DATA FRAME is determined from the value of Max-

imum MAC-d PDU Length, HS-DSCH Credits, and HS-DSCH Interval. These IEs are

contained in the CAPACITY ALLOCATION message.

Tab. 2.4shows the CAPACITY ALLOCATION message which the RNC can receive.

IE Fieldlength[bit]

Value Comment

Header CRC 7 0..127 Refer to 3GPP TS 25.435.

Frame Type 1 0 0 = data frame

CmCH-PI 4 0..15 Priority of HS-DSCH DATA FRAME.

MAC-d PDULength

13 336, 656[bits]

RLC PDU size is 336 bits or 656 bits.If multiplexing MAC-d is used, theMAC-d header which is C/T field (4bits)is added.

NumOfPDU 8 1..83 83 is the maximum number of MAC-dPDUs using 336bits RLC PDU size.

When using 656bits, the maximumnumber is 43.

User Buffer Size 16 Dont care Is to be ignored by Node B.

Spare Bit 4 0 Always set to 0.

Padding 4 0 This IE is optional and only presentwhen MAC-d multiplexing is not used.

Payload CRC 16 0..65535 Refer to 3GPP TS 25.435.

Tab. 2.3 HS-DSCH DATA FRAME Header IE

IE Field length[bit]

Value Comment

Spare Bit 4 Don't care

CmCH-PI 4 0..15

Maximum MAC-dPDU Length

13 0..5000[bits]

HS-DSCH Credits 11 0..2047 0 = stop transmission, 2047 = un-limited. The number of MAC-d PDUduring one HS-DSCH Interval.

HS-DSCH Interval 8 0..255[10ms]

Tab. 2.4 CAPACITY ALLOCATION message


24/165




Handling of the CAPACITY REQUEST message

The CAPACITY REQUEST message is sent to the Node B by the RNC when CAPAC-

ITY needs to be modified. This message is sent for each radio access bearer (RAB).

Tab. 2.5shows the CAPACITY REQUEST message set up by the HSDST card.

2.1.4.5 Handling of the Initial Capacity Allocation IE

The following two methods are available for assigning CAPACITY from the Node B to

the RNC.

Using the HS-DSCH Initial Capacity Allocation IE contained in RL Setup Response

and RL Reconfiguration Ready of NBAP as option.

Using the CAPACITY ALLOCATION message in HS-DSCH FP

In the RNC, CAPACITY provided by the Initial Capacity Allocation IE is not used for the

transmission of the HS-DSCH DATA FRAME message. Instead, the RNC uses only CA-

PACITY provided by the CAPACITY ALLOCATION message.

2.1.4.6 Internal FP (HSDPA)

The Internal FP (HSDPA) is the particular frame protocol inside the RNC for HSDPA

which transmits RLC PDUs between the HSDST and the HSPRLC. In this FP, flow con-

trol is performed between the HSDST and the HSPRLC, and this FP complies with the

HS-DSCH FP flow control.

HS-DSCH Repeti-tion Period

8 Don't care 0 = unlimited repetition period.RNC always sets it to 0 in the firstrelease.

IE Field length[bit]

Value Comment

Tab. 2.4 CAPACITY ALLOCATION message

IE Field length

[bit]

Value Comment

Spare Bit 4 Don't care

CmCH-PI 4 0..15

User Buffer Size 16 0..65535[octets]

The amount of data pending for therespective MAC-d flow for theCmCH-PI level.

Tab. 2.5 CAPACITY REQUEST message


25/165




2.1.5 HSPRLC Functionality

The new HSPRLC card has the same functionality as a PRLC except that it provides a

higher throughput and supports the internal FP for handling HSDPA traffic. This means

that the HSPRLC is basically able to support both Rel 99 traffic and HSDPA trafficwhereas the PRLC cannot support HSDPA traffic.

The HSPRLC has the following functions:

U-Plane protocol handling:

At the Iu interface: IP, UDP, GTP-U

At the Iub interface: PDCP, RLC, Internal FP, Internal FP (HSDPA)

Traffic Monitoring

The information is used for Charging etc.

QoS control

Performs marking of the DSCP (differentiated services code point) to the TOS

(type of service) field of the IP header of the data traffic in UL

2.1.5.1 IP/UDP/GTP-U

Refer to the Iu interface specification 3GPP TS25.414 for the function of the

IP/UDP/GTP-U in conjunction with the Iu interface.

2.1.5.2 Packet Data Convergence Protocol

The HSPRLCs PDCP has the following functions:

Data transfer

Header Compression

RFC-2507 IP Header Compression is supported

2.1.5.3 Radio Link Control

The HSPRLCs RLC has the following functions:

Segmentation/Reassembly

Concatenation

Pe-adding

Data transfer

Error correction

In-sequence delivery of upper-layer PDUs

Duplicate detection

Flow control Protocol error detection / restoration

Ciphering

Acknowledged Mode / Unacknowledged Mode

In addition to the same function as PRLC of Rel 99, the following new functions are sup-

ported by HSDPA:

656 bit RLC-PDU size

If the RLC-PDU size is 336 bit, the peak rate of HSDPA (about 14 Mbit/s) cannot be

supported because the number of MAC-d PDUs that can be included in a MAC-hs

PDU is limited. Therefore, the RNC supports an RLC-PDU size of 656 bit.


26/165




2.1.5.4 Internal FP and Internal FP (HSDPA)

The HSPRLC deals with the Internal FP which is a protocol for transmitting data for ded-

icated PS traffic between HSPRLC and DHT or MHC in contrast to the Internal FP (HSD-

PA). The Internal FP as used in the HSPRLC provides the same functionality as used inthe PRLC card.

2.2 Functional Split

HSDST

Terminates HS-DSCH FP, MAC-d, and Internal FP (HSDPA).

Performs traffic monitoring and flow control between RNC and Node B.

HSPRLC

Terminates IP, UDP, GTP-U on the Iu side and PDCP, RLC, Internal FP, Internal

FP (HSDPA) on the Iub side. Performs traffic monitoring and QoS control.

2.3 Man-Machine Interface

Not applicable (see chapter 5.3).

2.4 Operating the Feature

Not yet applicable.


27/165




3 Modifications in the Node B Hardware and

Software Architecture

The HSDPA feature is only provided for Node B Platform 2. Thus, in UMR5.0, NB-420,NB-440, NB-441, NB-580, NB-860, NB-880, NB-881, NB-341, RS-880, and RS-381 are

capable of processing HSDPA traffic. In the following, the NB-440 and NB-441 are re-

ferred to as NB-44x. The NB-880 and NB-881 are referred to as NB-88x.

UMR5.0 supports the Node B-type-specific cell configurations for HSDPA as listed in

Tab. 3.1.

Node Btype(s)

Variant Cellconfiguration

HSDPAconfiguration

Power/cell [W]

Number of RF modules

TRX LPA CAT1 RRH2

NB-4203 TRX-LPA 1/0/0 1/0/0 20 1 1

1/1/0 1/1/0 20 2 2

1/1/1 1/1/1 20 3 3

NB-44x3 TRX-LPA 1/0/0 1/0/0 20 1 1

1/1/0 1/1/0 20 2 2

1/1/1 1/1/1 20 3 3

2/0/04 1/0/0 20 2 2

2/2/04 1/1/0 20 4 4

2/2/24 1/1/1 20 6 6

NB-860 DRIC-CAT20 1/0/0 1/0/0 20 1

1/1/0 1/1/0 20 2

1/1/1 1/1/1 20 3

DRIC-CAT40 1/0/0 1/0/0 40 1

1/1/0 1/1/0 40 2

1/1/1 1/1/1 40 3

2/0/04 1/0/0 20 1

2/2/04 1/1/0 20 2

2/2/24

1/1/1 20 3

DRIC-RRH 1/0/0 1/0/0 12.5 1

1/1/0 1/1/0 12.5 2

1/1/1 1/1/1 12.5 3

2/0/04 1/0/0 6.25 1

2/2/04 1/1/0 6.25 2

2/2/24 1/1/1 6.25 3

Tab. 3.1 Possible HSDPA cell configurations in UMR5.0


28/165




NB-88x DRIC-CAT20 1/0/0 1/0/0 20 11/1/0 1/1/0 20 2

1/1/1 1/1/1 20 3

2/0/04 1/0/0 20 2

2/2/04 1/1/0 20 4

2/2/24 1/1/1 20 6

DRIC-CAT40 1/0/0 1/0/0 40 1

1/1/0 1/1/0 40 2

1/1/1 1/1/1 40 3

2/0/04 1/0/0 20 1

2/2/04 1/1/0 20 2

2/2/24 1/1/1 20 3

2/0/04 1/0/0 40 2

2/2/04 1/1/0 40 4

2/2/24 1/1/1 40 6

DRIC-RRH 1/0/0 1/0/0 12.5 1

1/1/0 1/1/0 12.5 2

1/1/1 1/1/1 12.5 3

2/0/04 1/0/0 6.25 1

2/2/04 1/1/0 6.25 2

2/2/24 1/1/1 6.25 3

1/1/1/1/0/0 1/1/1/1/0/0 12.5 4

DRIC-CAT-RRH 1/0/0, 1/0/0 1/0/0, 1/0/0 20, 12.5 1 1

1/1/0, 1/1/0 1/1/0, 1/1/0 20, 12.5 2 2

1/1/1, 1/1/1 1/1/1, 1/1/1 20, 12.5 3 3

1/0/0, 1/0/0 1/0/0, 1/0/0 40, 12.5 1 1

1/1/0, 1/1/0 1/1/0, 1/1/0 40, 12.5 2 2

1/1/1, 1/1/1 1/1/1, 1/1/1 40, 12.5 3 3

2/0/04, 2/0/04 2/0/0, 2/0/0 20, 6.25 15/26 1

NB-341 with Booster 1/0/0 1/0/0 10

without Booster 1/0/0 1/0/0 0.5

Node Btype(s)


HSDPAconfiguration

Power/cell [W]


TRX LPA CAT1 RRH2



29/165




RS-880 DRIC-RRH 1/0/0 1/0/0 12.5 11/1/0 1/1/0 12.5 2

1/1/1 1/1/1 12.5 3

2/0/04 1/0/0 6.25 1

2/2/04 1/1/0 6.25 2

2/2/24 1/1/1 6.25 3

1/1/1/1/0/0 1/1/1/1/0/0 12.5 4

RS-381 DRIC-RRH 1/0/0 1/0/0 12.5 1

1/1/0 1/1/0 12.5 2

1/1/1 1/1/1 12.5 3

2/0/04 1/0/0 6.25 1

Node Btype(s)


HSDPAconfiguration

Power/cell [W]


TRX LPA CAT1 RRH2



30/165




Notes:1Available CAT modules are:

CAT20, providing 20 W output power per cell

CAT40, providing 40 W output power per cell

ngCAT, providing either 20 W or 40 W output power per cell

CAT40, providing 40 W output power per cell, for FDD UMTS1900 MHz

CAT40, providing 40 W output power per cell, for FDD UMTS850 MHz

Each of these CATs can be used in combination with DRIC12-12 or DRC24-24OE.

2Remote Radio Heads (RRHs) can only be used with DRIC24-24OE.

3If the NB-420 and NB-44x are upgraded to DRIC-CAT configuration, the same config-

urations can be applied as for the NB-860 and NB-88x, respectively.

NB-580 DRIC-CAT 0/0/0 : 1/0/07

0/0/0 : 1/0/07

0 : 407

0 : 18

0/0/0 : 1/1/07 0/0/0 : 1/1/07 0 : 407 0 : 18

0/0/0 : 1/1/17 0/0/0 : 1/1/17 0 : 407 0 : 18

0/0/0 : 2/0/07 0/0/0 : 2/0/07 0 : 207 0 : 18

0/0/0 : 2/2/07 0/0/0 : 2/2/07 0 : 207 0 : 28

0/0/0 : 2/2/27 0/0/0 : 2/2/27 0 : 207 0 : 38

0/0/0 : 2/0/07 0/0/0 : 2/0/07 0 : 407 0 : 28

0/0/0 : 2/2/07 0/0/0 : 2/2/07 0 : 407 0 : 48

0/0/0 : 2/2/27 0/0/0 : 2/2/27 0 : 407 0 : 68

1/0/0 : 0/0/07 1/0/0 : 0/0/07 40 : 07 1 : 08

1/0/0 : 1/0/07 1/0/0 : 1/0/07 40 : 407 1 : 18

1/1/0 : 0/0/07 1/1/0 : 0/0/07 40 : 07 2 : 08

1/1/0 : 1/1/07 1/1/0 : 1/1/07 40 : 407 2 : 28

1/1/1 : 0/0/07 1/1/1 : 0/0/07 40 : 07 3 : 08

1/1/1 : 1/1/17 1/1/1 : 1/1/17 40 : 407 3 : 38

2/0/0 : 0/0/07 2/0/0 : 0/0/07 20 : 07 1 : 08

2/0/0 : 2/0/07 2/0/0 : 2/0/07 20 : 207 1 : 18

2/2/0 : 0/0/07 2/2/0 : 0/0/07 20 : 07 2 : 08

2/2/2 : 0/0/07 2/2/2 : 0/0/07 20 : 07 3 : 08

2/0/0 : 0/0/07 2/0/0 : 0/0/07 40 : 07 2 : 08

2/0/0 : 2/0/07 2/0/0 : 2/0/07 40 : 407 2 : 28

2/2/0 : 0/0/07 2/2/0 : 0/0/07 40 : 07 4 : 08

2/2/2 : 0/0/07 2/2/2 : 0/0/07 40 : 407 6 : 08

Node Btype(s)


HSDPAconfiguration

Power/cell [W]


TRX LPA CAT1 RRH2



31/165




4Only one cell per sector supports HSDPA because UMR5.0 supports HSDPA only on

a single carrier frequency. Chosing the HSDPA cell therefore depends on the choice

in the Node Bs other sectors.

5

Applies for CAT40.6Applies for CAT20.

7The value in front of the colon (:) applies for cells in the FDD UMTS1900 MHz band

whereas the value behind the colon applies for cells in the FDD UMTS850 MHz band.

8The value in front of the colon (:) applies for CAT40 for FDD UMTS1900 MHz where-

as the value behind the colon applies for CAT40 for FDD UMTS850 MHz.

The cells which provide HSDPA service are distributed in a round-robin manner on the

available HSDPA-capable CHCs, thus resulting in an even distribution of the cells on the

appropriate CHCs. Tab. 3.2provides an example of the dependencies between the

Cell configuration of HSDPA cells

Number of available HSDPA-capable CHCs

Cell mode operation of each HSDPA-capable CHC in the Node B, resulting from the

round-robin distribution, where

single

Indicates that the CHC operates in HSDPA single-cell mode, i.e. one HSDPA-ca-

pable CHC in HSDPA mode serves exactly one HSDPA cell

multi

Indicates that the CHC operates in HSDPA multi-cell mode, i.e. one HSDPA-ca-

pable CHC in HSDPA mode serves two or three HSDPA cells

off

Indicates that the CHC does not operate in HSDPA mode (Rel 99 traffic only)

3.1 Functional Description

With UMR5.0 supporting HSDPA in the Node B, changes have been made to the

Node Bs hardware (HW) and software (SW) architecture. The following functional enti-ties have been extended or newly created in the Node B to support HSDPA:

Flow control

The flow control mechanism dynamically assigns capacity to the HS-DSCH on the

Iub interface. The relevant capacity is allocated in accordance with the available

buffer space for priority queues and the current air interface capacity, for example.

HS-DSCH frame protocol (FP)

The HS-DSCH FP is responsible for

Extracting HS-DSCH capacity requests and forwarding them to the flow control

unit

Signaling flow control credits to the SRNC (serving RNC)

Controlling incoming user traffic. In other words, the Node B can potentially dis-

card incoming user traffic if the RNC exceeds the assigned credit limits.

Cell configuration 1 HSDPA-capable CHCinstalled

2 HSDPA-capable CHCsinstalled

3 HSDPA-capable CHCsinstalled

1/0/0 single single/off single/off/off

1/1/1 multi multi/single single/single/single

Tab. 3.2 Dependencies between the number of HSDPA-capable CHCs and the cell configuration applied


32/165




Extracting the incoming user data and putting the data into the priority queues

Scheduler

In UMR5.0, the scheduler for HSDPA data traffic is implemented in the Node B rath-

er than in the RNC where the scheduler for Rel 99 traffic is situated. This implemen-

tation allows for lower latency.

In general, this functional entity of the Node B is responsible for

Selecting the UEs to be served in a specific time transmission interval (TTI)

Assigning the HS-PDSCH resources to UEs

Selecting the appropriate priority queues which are to be served

Managing the HSDPA air interface resources

Selecting HARQ (hybrid automatic repeat request) processes, redundancy ver-

sions, modulation schemes, transport block sizes, and the HSDPA transmit signal

power

Priority queues

The Node Bs priority queues are buffers for the HSDPA user traffic data. By means

of the priority queues, the total amount of pending user data in the priority queues isvisible to the flow control unit and the scheduler.

HS-SCCH symbol level processing unit

This functional entity performs signal processing for the HS-SCCH.

HS-PDSCH symbol level processing unit

This functional entity performs signal processing for the HS-PDSCHs.

HARQ control

On the one hand, the HARQ control entity processes the connected UEs HARQ sta-

tus indications. On the other hand, this functional unit manages the states of these

UEs HARQ processes.

Transport block assembly

The transport block assembly unit prepares each transport block for further physicallayer processing. Preparing the transport blocks is done upon request of the sched-

uler. Among other things, this preparation must take into account whether the sched-

uler demands either initial transmission or retransmission.

Furthermore, the transport block assembly is responsible for managing both the pri-

ority queues and the retransmission buffer. This functionality, however, is implemen-

tation-dependent.

Another functionality the transport block assembly provides is cleaning up the re-

transmission buffer. The buffer is cleaned up if the protocol data units (PDUs) are

either successfully transmitted or dropped due to reaching the relevant time-outs.

Channel quality estimation (CQE)

The CQE combines channel quality information (CQI) and downlink (DL) transmit

power commands.

These functional entities impact on the Node Bs core controller (CC), channel coding

card (CHC), and transceiver (TRX) or DUAMCO (duplexer amplifier multicoupler), or

digital radio interface card (DRIC). The majority of the above-mentioned functional units,

however, is located in the CHC. Therefore, a new HSDPA-capable CHC must be in-

stalled in the Node B if HSDPA is to be supported. Thus, one of the following two pos-

sible alternatives must be chosen for HSDPA support:

Firmware (FW) upgrade of the CHC96 (channel coding card-96)

Installation of the newly developed hs-CHC (high speed channel coding card)


33/165




General configuration rules

With respect to HSDPA as introduced in UMR5.0, the following general rules apply to

the configuration of the HSDPA-capable Node B types:

In UMR5.0, HSDPA operation is only possible on one carrier frequency per Node B. This product release permits only symmetrical HSDPA configurations in all radio

cells on the same carrier frequency. In other words, the configured number of HS-

PDSCH channelization codes and the number of HS-SCCH channelization codes

must be equal for all radio cells on a single carrier frequency.

One single HSDPA-capable CHC performs complete HSDPA signal processing for

one single radio cell. Signal processing cannot be split between several HSDPA-ca-

pable CHCs.

However, multiple radio cells can be processed on one HSDPA-capable CHC.

With this release, complete HSDPA signal processing for all radio links of a Node B

must be performed by one single type of CHC. Thus, simultaneous operation of

HSDPA on both a CHC96 and an hs-CHC is not supported.

If at least one hs-CHC is mounted in a Node B, the HSDPA processing will only be

performed on the hs-CHC(s).

Those CHCs performing HSDPA support only the normal or the large cell mode.

3.1.1 Modifications of the Node Bs Hardware

HSDPA requires a new type of CHC capable of handling both 3GPP Rel 99 traffic on

DCH and 3GPP Rel 5 HSDPA traffic on HS-DSCH. This new CHC may either be an ex-

isting CHC96 whose FW is updated or a new hs-CHC.

Both types of HSDPA-capable CHCs are able to handle both HSDPA and non-HSDPA

dedicated and common channels. In general, an HSDPA-capable CHC is able to pro-

vide HSDPA service for up to three cells.

If both types of HSDPA-capable CHCs are installed in the same Node B, HSDPA oper-

ation will only be possible on one type, i.e. either on the hs-CHC or on the CHC96. Ad-

ditionally, HSDPA users of a particular cell for which HSDPA is enabled must not be

distributed on different HSDPA-capable CHCs. The HSDPA-capable CHCs are further-

more currently operated in a non-redundant configuration. In other words, in the event

of a failure of the HSDPA-capable CHC, each SRNC either drops the HSDPA-related

call connections that are affected by the faulty CHC or switches them to DCHs by means

of channel-type switching (CTS). The Node B will then try to reconfigure the defective

CHC for HSDPA service. In this case, however, the DL channel elements (CE) resourc-

es on TRX/DRIC stay allocated without any change.

The following general rules must therefore be applied for a Node B which is to offer

HSDPA service:

The NB-44xs and NB-88xs B-shelf provides 10 slots allowing the installation of up

to 10 CHCs. At least 1 CHC must be installed. The recommendation, however, re-

quests the installation of at least 2 CHCs.

Any mixed operation of the CHC48, the CHC96, and the hs-CHC is supported for

the Node Bs non-HSDPA mode.

When providing HSDPA functionality to a specific radio cell, only one type of HSD-

PA-capable CHC, i.e. either the CHC96 or the hs-CHC, is permitted. Mixed opera-

tion of both types of CHCs is not allowed in UMR5.0.

One single HSDPA-capable CHC is able to handle up to three HSDPA cells.

For each HSDPA cell, a maximum of 1 HSDPA-capable CHC is permitted. The total required number of CHCs depends on the traffic estimation.


34/165




In UMR5.0, the HSDPA-capable CHCs support UEs of the classes 1 to 6, 11, and 12.

Additionally, HSDPA calls for UEs of categories 7, 8, 9, and 10 are set up on the HS-

DSCH with a performance equal to or better than that of UE category 6. For details

about UE classes, please refer to "UE Support of HSDPA" on page 46.

In this context, Tab. 3.3lists the maximum number of HSDPA users possible with the

HSDPA-capable CHCs when a specific uplink radio access bearer is applied.

3.1.1.1 CHC96

The existing CHC96 has already been HW-prepared for HSDPA in product releases

prior to UMR5.0. Its SW, however, is updated in order to handle HSDPA traffic in an ap-

propriate way.

The CC OAM SW configures the CHC96 to operate in non-HSDPA mode or in HSDPA

mode. In non-HSDPA mode, no HSDPA-specific channels and functions are supported.

When operating in this mode, the CHC96s maximum performance is equal to

96 channel elements (CEs) and 144 adaptive multi-rate (AMR) equivalents (AMREQs).

These characteristics are the same as in the product release prior to UMR5.0.

When working in HSDPA mode, the CHC96 supports both normal channels (3GPP

Rel 99) and HSDPA-specific channels and functions simultaneously. Compared to the

non-HSDPA mode, no restrictions apply with regard to the maximum number of channel

elements and AMR equivalents.

The applicable baseband (BB) resources are communicated from the CHC to the CC

using the defined BB resource management procedures in each mode of operation.

3.1.1.2 hs-CHC

The newly developed hs-CHC offers the same functionality as a Rel 99-compliant CHC.

Furthermore, functionality for the support of HSDPA is provided.

Unlike the CHC96, the hs-CHC operates in only one mode supporting the processing of

both DCH bearers (Rel 99) and HSDPA. In other words, the hs-CHC simultaneously

supports HSDPA-specific channels and functions as well as normal channels. The

hs-CHCs maximum performance is equal to 96 CEs and an AMREQof 144.

UL RAB rate AMREQ Maximum number of possible HSDPA UEs

8 kbit/s 1 96

32 kbit/s 2 72

64 kbit/s 4 36

128 kbit/s 8 18

384 kbit/s 16 9

Tab. 3.3 Maximum number of HSDPA users depending on the UL RAB rate


35/165




3.1.2 Modifications of Radio Frequency (RF) Issues

Until now, the only modulation scheme used in UTRAN has been quadrature phase shift

keying (QPSK). With UMR5.0, 16-quadrature amplidute modulation (16QAM) is intro-

duced as a new modulation scheme allowing for a higher data rate. The realization of16QAM does not require any replacement or modification of the TRX or DRIC card.

Compared to QPSK, 16QAM is more sensitive to various kinds of signal distortion, in-

cluding distortions arising from non-linearities in the power amplifier (PA). Therefore, in

accordance with 3GPP standardization, the acceptable error vector magnitude for

16QAM operation is reduced to 12.5%, whereas in QPSK this value is set to 17.5%.

Compliance to the 3GPP standards is achieved with the existing RF components.

3.1.3 Modifications of Call Processing

Compared to the existing CHCs (CHC48 and CHC96 without support of HSDPA) mode

of operation, the resources are used in a different way inside the Node B. The followingresources must therefore be distinguished with respect to UMR5.0 and HSDPA:

Resources for HSDPA downlink processing

Resources for DCH/RACH (random access channel) uplink processing

Resources for DCH/FACH (forward access channel) downlink processing

By introducing HSDPA, some NBAP (Node B application part) procedures have been

added and others have been extended. These changes, however, do not affect the func-

tionality provided in product releases prior to UMR5.0. The HSDPA feature affects the

following types of NBAP procedures:

Procedures related to logical OAM

Physical Shared Channel Reconfiguration procedure

Resource Status Indication procedure and Audit Response procedure Procedures concerning Common measurements

Procedures related to UEs

RL (radio link) Setup procedure and Synchronized RL Reconfiguration procedure

RL Parameter Update procedure

RL Deletion procedure

Physical Shared Channel Reconfiguration procedure

NBAP: Physical Shared Channel Reconfiguration is a new procedure which is invoked

by the controlling RNC (CRNC) in order to configure/reconfigure/delete the resources

provided for HSDPA in a Node B. Optional parameters concerning both the scrambling

code (default: primary scrambling code) and channelization codes are thus provided for

the HS-PDSCH and the HS-SCCH.

The Node B starts HSDPA operation upon reception of the NBAP: PHYSICAL SHARED

CHANNEL RECONFIGURATION REQUEST message with consistent IEs. Additional-

ly, an appropriate number of HSDPA licenses (see chapter 5.1.2.4for details) must be

available.

As regards the termination or temporary suspension of HSDPA operation, the Node B

distinguishes between them. Terminating HSDPA operation, on the one hand, is indicat-

ed by setting the number of channelization codes for both HS-PDSCH and HS-SCCH to

zero. The temporary suspension of HSDPA operation, on the other hand, is indicated

whenever the number of channeliazation codes for HS-PDSCH plus the number of

channelization codes for HS-SCCH is greater than zero.


36/165




Resource Status Indication procedure and Audit Response procedure

These procedures functionalities are extended for HSDPA. Trigger conditions are add-

ed to handle the same events in the context of HSDPA as defined for DCH in the last

product release prior to UMR5.0. The procedures implementation is thus extended inorder to handle the following information elements (IEs):

The HSDPA Capability IE reflects the result from checking the preconditions for

HSDPA operation.

The Resource Operational State IE and the Availability Status IE are set accord-

ing to the current status of HSDPA operation in the relevant cell.

As a precondition, the HSDPA-capable CHC must be HW-prepared to perform audit

procedures on HSDPA resources.

Common measurements

With regard to common measurements, an HSDPA-capable Node B supports all meas-

urements already used in product releases prior to UMR5.0 plus the measurementsused for HSDPA. Thus, the NBAP: Common Measurement Initiation, Common Meas-

urement Reporting, Common Measurement Termination, and Common Measurement

Failure procedures are extended to decode additional IEs.

The transmitted carrier power is measured in the same way as for pre-HSDPA product

releases. The transfer of measurement values from the TRX/DRIC cards to the CC, in

particular, remains unchanged.

The Node B periodically measures the transmitted carrier power of all codes which are

not used for the HS-PDSCH. This measurement is performed per cell.

RL (radio link) Setup procedure and Synchronized RL Reconfiguration procedure

All existing functionality of these two existing NBAP procedures is also supported byUMR5.0. The implementation of these procedures is extended so that the Node B can

decode the following IEs:

Parameters for Iub transport configuration of both MAC-d flows and scheduling pa-

rameters per priority queue

Radio network temporary identify (RNTI) of HS-DSCH and RL ID of HS-PDSCH

HSDPA-realated capabilities of UEs

Parameters for channel quality information (CQI) feedback and ACK/NACK

HS-SCCH power offset

Measurement power offset for CQI measurement


37/165




RL Parameter Update procedure

The NBAP: RL Parameter Update procedure is new with UMR5.0. The Node B uses this

procedure in order to inform the RNC about the necessity to reconfigure radio parame-

ters, i.e. parameters for CQI and ACK/NACK reporting as well as the number of chan-nelization codes for both HS-PDSCH and HS-SCCH.

RL Deletion procedure

No IEs of the NBAP: RL Deletion procedure are modified for supporting HSDPA. Addi-

tional functionality, however, is provided for triggering the release of the HSDPA re-

sources occupied for the relevant UE.

3.1.4 Modifications of the Transport on the Iub Interface and the Priority

Queue Management

This section deals with the following:

Interworking Between RNC and Node B

UTOPIA Connection Handling on the CC-BB Interface

3.1.4.1 Interworking Between RNC and Node B

HSDPA affects the interworking between RNC and Node B with respect to the control

plane, the user plane, and the transport network layer (TNL).

The feature impacts on the Iub interface control planes NBAP procedures, described in

"Modifications of Call Processing" on page 35.

The user plane of the Iub interface is responsible for transferring MAC-d protocol data

units (PDUs) from the SRNC to the Node B by means of the HS-DSCH frame protocol.Further details about both the Iub interface user plane and the TNL are described in

"Transport Network Layer (TNL) Modifications" on page 147.

3.1.4.2 UTOPIA Connection Handling on the CC-BB Interface

In the Node B, UTOPIAs (universal test and operations physical interface for ATM) Iub

user plane provides AAL2 (ATM adaptation layer 2) connections from the RNC via the

CC to the CHCs carrying user traffic data. Both HSDPA and non-HSDPA traffic are

transferred in parallel. In comparison to previous releases, non-HSDPA traffic process-

ing remains unchanged. For HSDPA traffic, each MAC-d flow is mapped onto a single

AAL2 connection. Furthermore, both the addressing scheme and the conversion from

AAL2 to AAL2d in the CC are the same as for AAL2 connections carrying DCH traffic.

In the event of a failure occurring in the HSDPA-capable CHC, the CHC will send a mes-

sage over the supervision bus to the CC if possible. The CHC will then perform an au-

tonomous reset because no redundant HSDPA-capable CHC is available to take over

the functions necessary to maintain ongoing HSDPA calls.


38/165




3.1.5 The MAC-hs Concept

The MAC-hs is a new SW part in the Node B. It is needed to support the HS-DSCH.

The MAC-hs scheduler is responsible for supervising the HSDPA performance in a radio

cell, efficiently utilizing the Iub interface, and guaranteeing the QoS provided to the sub-scribers.

In UMR5.0, the MAC-hs supports both interactive and background services. Further-

more, the Node Bs HW is prepared to support streaming services in future releases.

Generally, the MAC-hs provides functionalities for the following:

Handling of Parameters

Flow Control

Transmission Control

HARQ

Channel Quality Estimation

Measurements and Performance Measurement (PM) Counters

3.1.5.1 Handling of Parameters

The MAC-hs handles HSDPA-related IEs received from the RNC or sent to the RNC via

NBAP signaling. Furthermore, the MAC-hs supervises the maximum number of HARQ

retransmissions which is a vendor-settable OAM parameter for each radio cell. Adjust-

ing this parameter may become necessary in difficult radio environments. In an indoor

environment, for example, a low value for this parameter is beneficial, whereas in an out-

door scenario a high value is favorable in order to serve UEs at the border of the relevant

macro cell.

Furthermore, the MAC-hs is responsible for OAM with regard to the HSDPA scheduler

type. The operator can select either a Maximum CIR (carrier- to interference-power ra-tio) or a Proportional Fair scheduler. For more details about the Proportional Fair

scheduler, refer to the FD012251 - Proportional Fair Scheduler for HSDPA. For informa-

tion about the scheduler-related parameter in the Node Bs software, refer to "Impacts

on the LMT-Node B" on page 143.

3.1.5.2 Flow Control

The Node Bs flow control protects the priority queues from an overflow situation and

supplies the Node B with user traffic data in such a way that the throughput at the Uu

interface is maximized under the given QoS constraints.

Further details about the flow control mechanism are described in the section "FlowControl" on page 147.

3.1.5.3 Transmission Control

The transmission control function manages the HSDPA Uu interface resources in terms

of transmission time, channelization codes, and transmit power. With regard to the

transmit power for HS-PDSCHs, on the other hand, all HS-PDSCHs of the same UE

have to be transmitted with the same power. When assigning the transmit power to the

HS-PDSCHs, the transmission control functional entity must make sure that it does not

exceed either the maximum HSDPA transmit power configured via NBAP signaling or

the transmit power available for HSDPA. Furthermore, if the scheduler decides to apply


39/165




the 16QAM modulation for at least one UE, it reduces the HS-PDSCH transmit power

by a certain amount.

The transmission control functional entity includes the scheduler functionality where, in

UMR5.0, either a Maximum CIR (carrier- to interference-power ratio) or a ProportionalFair scheduler is used.

The Maximum CIR scheduler, on the one hand, works according to the following princi-

ple: at each time transmission interval (TTI), it selects the UE(s) for transmission in de-

creasing order of their current CIR. In other words, the UE with the best CIR is served

first, UEs with lower CIRs are currently blocked and served later. Thus, the Maximum

CIR scheduler ensures high peak data rates as well as a maximum Node B cell through-

put. Each UE reports its current CIR contained in the channel quality information (CQI)

at every TTI via the HS-DPCCH. Refer to "Channel Quality Estimation" on page 40.

The Proportional Fair scheduler, on the other hand, provides a fairer distribution of trans-

mission bandwidth among the HSDPA users within a radio cell. Thus, the Proportional

Fair scheduler assures that all HSDPA users within this cell will benefit from the availa-bility of HSDPA. For more details about this scheduler, refer to the FD012251 - Propor-

tional Fair Scheduler for HSDPA.

In addition to the above features, the transmission control functional entity is able to set

the following parameters for each scheduled UE:

Channelization code for HS-SCCH

Channelization codes for HS-PDSCH

Transport block size

In the event of a retransmission, the transport block size must be equal to that of the

initial transmission.

Modulation scheme

When selecting the modulation scheme, the transmission control function must takeinto account restrictions arising from UE capabilities and those which are implied by

the optional feature handling.

3.1.5.4 HARQ

The hybrid automatic repeat request (HARQ) provides functionality for fast and efficient

retransmission techniques and error detection. Thus, the UE calculates the cyclic redun-

dancy check (CRC) of the incoming packet from the Node B. If this CRC is the same as

the one contained in the packet, an ACK (acknowledged) signal is sent to the Node B.

Otherwise, NACK (not ACK) is sent, thus requesting for a retransmission of the errone-

ous packet.

The HARQ functionality is based on an N-channel stop and wait automatic repeat re-

quest (ARQ). The HARQ supports both chase combining and incremental redundancy.

The number of retransmission attempts is limited to a maximum value given by the cor-

responding OAM parameter (see subsection Handling of Parameters, above).

Applying stop and wait ARQ, the transmitter persists on the transmission of the current

data block until the UE has successfully received this block. To avoid idle times,

N parallel processes (channels) are set up, thus allowing different processes transmit

in separate TTIs.

The basic idea of chase combining is as follows: upon reception of an erroneous packet,

a NACK signal is sent. The packet, however, is not deleted as is done by normal ARQ

but stored. If the retransmitted packet is erroneous, too, the previous and the currentpacket are combined, thus attempting to recover from the errors. Eventually, either the


40/165




packet is received without an error, or the UE recovers from the error by means of chase

combining, or the maximum number of retransmissions is exceeded. In the latter case,

error recovery is left to higher-protocol levels.

As regards the incremental redundancy, the transmitter adds previously not transmittedredundant information to the packet if the receiver detected an error in this packet in ad-

vance. Adding further redundant information increases the chances of error-free trans-

missions or retransmissions with enough errors removed to allow error correction by

means of chase combining with previous packets.

3.1.5.5 Channel Quality Estimation

The channel quality estimation (CQE) functional unit provides an estimate of the chan-

nel quality of a specific UE in the currently scheduled time transmission interval (TTI) for

the transmission control function. This estimate allows the transport block size and the

number of HS-PDSCH channelization codes for the relevant UE to be selected appro-

priately.

The HS-PDSCH radio channel quality is estimated for each UE using the HS-DSCH. At

least two pieces of input information form the basis for the channel quality estimation.

The information provided for this estimation is, on the one hand, the DL transmit power

for the associated DCH and, on the other hand, the channel quality information (CQI)

periodically reported by the UE on the HS-DPCCH. The RNC determines the configura-

tion parameters for CQI reporting and provides them to both UE and Node B.

3.1.5.6 Measurements and Performance Measurement (PM) Counters

In addition to the above features, the MAC-hs provides functionality for updating the var-

iables for PM counters. The chapter "HSDPA Performance Measurement Counters" onpage 157provides a description of the new and modified PM counters for the support of

HSDPA.

3.1.6 Modifications of Signal Processing

With the introduction of HSDPA, signal processing in the base band, which is in general

performed by the CHC, and both DL and UL signal processing are adapted for a proper

operation of the feature.

3.1.6.1 Downlink Signal Processing

DL spreading and modulation is performed on the TRX or DRIC card which provide the

necessary functionality for DL signal processing. The CHC, on the other hand, performs

symbol rate processing and slot formatting for the DL channels. For HSDPA, the inter-

face from the CHC to the TRX or DRIC card remains unchanged.

DL physical channel types that are part of the pre-HSDPA function of the CHC are also

supported by the HSDPA-capable CHC. Additionally, the HSDPA-capable CHC sup-

ports physical channels required to provide HSDPA to the subscribers: HS-PDSCH and

HS-SCCH. The slot formats supported for HS-PDSCH and HS-SCCH are in accordance

with 3GPP. This slot format characteristically only carries data, but not power control

commands or pilot sequences or anything else.

The DL transport channels are extended by the HS-DSCH whose corresponding phys-ical channel

Documents

SF012249 Architecture Support of HSDPA