Hsdpa Technical Description

UTRAN
Technical Description
Radio Subsystem
HSDPA - UMR5.0
DRAFT
f Important Notice on Product Safety
DANGER - 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
Geräte müssen die zutreffenden Sicherheitsbestimmungen erfüllen.
In diesen Anlagen stehen die Netzversorgungsleitungen unter gefährlicher Spannung. Einige Komponenten
können auch eine hohe Betriebstemperatur aufweisen.
Nichtbeachtung der Installations- und Sicherheitshinweise kann zu schweren Körperverletzungen oder
Sachschäden führen.
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 table
A30808-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 München, 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 written contract.
2
Reason for Update
Summary:
First issue for new release.
Details:
Chapter/Section Reason for Update
All First issue for new release.
Issue History
Issue Date of issue Reason for Update
Number
1 04/2005 First issue for new release.
3
4
This document consists of 163 pages. All pages are issue 1.
Contents
1 Short Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.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 B’s Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.1.1 CHC96 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.1.2 hs-CHC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.2 Modifications of Radio Frequency (RF) Issues . . . . . . . . . . . . . . . . . . . . . . 33
3.1.3 Modifications of Call Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.4 Modifications of the Transport on the Iub Interface and the Priority Queue
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.4.1 Interworking Between RNC and Node B. . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.4.2 UTOPIA Connection Handling on the CC-BB Interface . . . . . . . . . . . . . . . 36
3.1.5 The MAC-hs Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.1.5.1 Handling of Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.1.5.2 Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5
3.1.5.3 Transmission Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.1.5.4 HARQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.1.5.5 Channel Quality Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.1.5.6 Measurements and Performance Measurement (PM) Counters . . . . . . . . . 38
3.1.6 Modifications of Signal Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1.6.1 Downlink Signal Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1.6.2 Uplink Signal Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.1.7 Modifications of Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2 Functional Split. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.1 Core Controller (CC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.2 Channel Coding Card (CHC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.3 Repeater (REP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.4 Transceiver (TRX) or Digital Radio Interface Card (DRIC) . . . . . . . . . . . . . 41
3.3 Man-Machine Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3.1 Front Panel Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3.2 Front Panel Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3.3 Manual Intervention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.4 Operating the Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4 HSDPA Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.1 HSDPA RAB Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.1.1 UE Support of HSDPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1.1.2 RAB Eligibility for HSDPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.1.3 Radio Bearer Combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.1.4 RAB Multiplexing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.1.1.5 Impacts on the Radio Bearer Translation. . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.1.6 RRC Connection State Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.1.1.7 Traffic Monitoring and Channel-Type Switching . . . . . . . . . . . . . . . . . . . . . 53
4.1.1.8 Power Control and Measurement Feedback Parameters . . . . . . . . . . . . . . 53
4.1.1.9 RAB Setup Procedure from DCH to HS-DSCH . . . . . . . . . . . . . . . . . . . . . . 54
4.1.1.10 RAB Setup Procedure from FACH to HS-DSCH . . . . . . . . . . . . . . . . . . . . . 58
4.1.1.11 Channel-Type Switching from FACH to HS-DSCH . . . . . . . . . . . . . . . . . . . 61
4.1.1.12 Channel-Type Switching from HS-DSCH to FACH . . . . . . . . . . . . . . . . . . . 62
4.1.1.13 RAB Setup Procedure from HS-DSCH to DCH . . . . . . . . . . . . . . . . . . . . . . 64
4.1.1.14 RAB Release Procedure from HS-DSCH to DCH . . . . . . . . . . . . . . . . . . . . 66
4.1.1.15 RAB Release Procedure from Multicall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.1.1.16 RRC Connection Reestablishment Procedure. . . . . . . . . . . . . . . . . . . . . . . 69
4.1.1.17 Radio Bearer Reconfiguration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.1.1.18 SRNS Relocation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.1.1.19 RAB Setup Procedure from CCH to DCH and DCH to DCH . . . . . . . . . . . . 70
4.1.1.20 Pre-emption and Interaction with Admission Control . . . . . . . . . . . . . . . . . . 71
4.1.1.21 Allocation of H-RNTI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.1.2 HSDPA Mobility Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.1.2.1 Scenarios for Mobility Handling of HS-DSCH . . . . . . . . . . . . . . . . . . . . . . . 73
4.1.2.2 MAC-hs Reset and Loss of Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.1.2.3 Measurement Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.1.2.4 HS-DSCH Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6
4.1.2.5 Inward Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.1.2.6 Change of the Serving HS-DSCH Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.1.2.7 Outward Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.1.2.8 DRNC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.1.2.9 Error Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.1.2.10 UE Differentiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.1.3 HSDPA Admission Control and Congestion Control. . . . . . . . . . . . . . . . . . 99
4.1.3.1 Radio Resource Management (RRM) Issues . . . . . . . . . . . . . . . . . . . . . . . 99
4.1.3.2 Load, Power, and Code Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.1.3.3 Admission Control in the CRNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.1.3.4 Restriction Control in the CRNC for HSDPA. . . . . . . . . . . . . . . . . . . . . . . 104
4.1.3.5 Admission Control in the Node B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.1.3.6 Congestion Control Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.1.3.7 Integration of the Admission Control Algorithm for HSDPA . . . . . . . . . . . 108
4.1.4 HSDPA Code and Power Allocation and Redimensioning . . . . . . . . . . . . 108
4.1.4.1 State Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.1.4.2 Common Measurements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.1.4.3 Code and Power Allocation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.1.4.4 Modification and Deletion of HSDPA Resources . . . . . . . . . . . . . . . . . . . 118
4.2 Functional Split . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.2.1 HSDPA RAB Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.2.2 HSDPA Mobility Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.2.3 HSDPA Admission Control and Congestion Control. . . . . . . . . . . . . . . . . 119
4.3 Man-Machine Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
4.3.1 HSDPA RAB Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
4.3.2 HSDPA Mobility Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
4.3.3 HSDPA Admission Control and Congestion Control. . . . . . . . . . . . . . . . . 122
4.4 Operating the Feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5 Modifications within UTRAN Operation and Maintenance . . . . . . . . . . . . 124

5.1 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.1.1 RNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.1.1.1 Equipment Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.1.1.2 Transport Network Layer Management . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.1.1.3 Radio Network Layer Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.1.1.4 Optional Feature Handling Within the RNC . . . . . . . . . . . . . . . . . . . . . . . 129
5.1.2 Node B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
5.1.2.1 Equipment Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
5.1.2.2 Transport Network Layer Management . . . . . . . . . . . . . . . . . . . . . . . . . . 132
5.1.2.3 Radio Network Layer Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
5.1.2.4 Optional Feature Handling Within the Node B . . . . . . . . . . . . . . . . . . . . . 132
5.2 Functional Split . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
5.3.1 Impacts on the RC GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
5.3.2 Impacts on the LMT-RNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.3.2.1 New CLI Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
7
5.3.2.2 Modified CLI Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
5.3.2.3 New Output Messages at the LMT-RNC . . . . . . . . . . . . . . . . . . . . . . . . . . 140
5.3.2.4 Modified Output Messages at the LMT-RNC . . . . . . . . . . . . . . . . . . . . . . . 140
5.3.3 Impacts on the LMT-Node B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
5.3.4 OAM Tool Set (OTS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
5.3.4.1 Extensions for South-Bound Import Operations and OTS Core . . . . . . . . 142
5.3.4.2 Extensions for South-Bound Export Operations . . . . . . . . . . . . . . . . . . . . 143
5.3.4.3 Consistency Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
5.3.4.4 Extensions for North-Bound Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
5.4 Operating the Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
6 Transport Network Layer (TNL) Modifications . . . . . . . . . . . . . . . . . . . . . . 145

6.1.1 Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
6.1.1.1 Priority Queue Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
6.1.2 QoS Mechanism. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
6.2 Functional Split. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
7 Air Interface (Uu) Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

7.1.1 Changes on the Uu Interface Layer 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
7.1.3.1 Impacts on the Radio Resource Control (RRC) Protocol. . . . . . . . . . . . . . 150
7.1.3.2 Identification of a UE’s 3GPP Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
7.1.3.3 Impacts of 3GPP Rel 5 on Previously Supported Features . . . . . . . . . . . . 153
7.1.3.4 RRC Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
8 HSDPA Performance Measurement Counters. . . . . . . . . . . . . . . . . . . . . . 155

9 Operating HSDPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
10 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
8
1 Short Description
This 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.
The following UE mobility scenarios are supported within UMR5.0:
• HS-DSCH establishment (when the UE is in Cell_DCH or Cell_FACH state)
– Intrafrequency, intra-SRNC, intra-Node B handover
9
– Interfrequency, intra-SRNC, intra-Node B handover (at channel-type-switching
from FACH to HS-DSCH)
• Inward mobility (DCH -> HS-DSCH)
– Intrafrequency, intra-RNC, inter-Node B handover
• Serving-HS-DSCH-cell change
– Intrafrequency, intra-RNC, intra-Node B handover
• Outward mobility (HS-DSCH -> DCH)
– Intrafrequency, intra-SRNC, inter-Node B handover
– Intrafrequency, inter-RNC handover
– Intrafrequency, inter-RNC (SRNC relocation)
– Interfrequency, intra-SRNC, inter-Node B handover
Modifications in the RNC HW/SW Architecture

By supporting HSDPA, the RNC must take care of flow control of the PS data stream.
This function is performed in the HS-DSCH Frame Protocol. The higher data rates of PS
data traffic (compared to Rel 99 data rates) also require enhanced RNC data cards to
cope with the throughput of high peak data rates. This has resulted in a new design of
two additional RNC components:
• HSPRLC
To terminate IP/UDP/GTP-U on the Iu side and RLC/PDCP on the Iub side. To per-
form traffic monitoring, charging and ciphering.
• HSDST
To terminate the HS-DSCH Frame Protocol and to perform flow control between
RNC and Node B.
Modifications in the Node B HW/SW Architecture

Until now, all UTRAN Transport Channels have been terminated in the RNC. The HS-
DSCH, however, is terminated by the MAC-hs layer in the Node B. This leads to a higher
processing load within the Node B (flow control and scheduling mechanism
RNC/Node B, handling of uplink feedback information). Higher traffic buffering also re-
quires increased memory. Increased internal traffic and higher symbol-level processing
(due to a higher data rate) must be considered. 16QAM is applied as new additional
modulation scheme which does not require any new modulator etc. but is generated by
the already installed hardware. Power amplifiers must support a higher linearity for
16QAM.
The main HSDPA functionalities are concentrated on the Node B Channel Card (CHC).
Therefore, the new HSDPA support requires a SW change of the currently used CHC.
For non-HSDPA usage the previous CHC version can be reused.
The current Core Controller (CC) is able to handle the higher Iub traffic, increased
number of AAL2 connections, and higher demands for Call Processing resources. There
is no HSDPA-specific functionality located on the CC.
Modifications within UTRAN OAM

The following HSDPA-specific items cause modifications of the UTRAN OAM area:
• New cards supporting HSDPA.
RNC: HSDST and HSPRLC
Node 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.
10
• 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) modifications

With 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
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.
11
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 B’s 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 be
specially 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.
12
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.
PDCP PDCP GTP-U

RLC RLC UDP
MAC-d MAC-d
HS-DSCH HS-DSCH IP
FP FP
MAC-hs MAC-hs AAL2 AAL2 AAL5
ATM ATM ATM
Phy. Phy. Phy. Phy. Phy.
UE Node B RNC
Uu Iub Iu
Fig. 2.1 Protocol stack of HSDPA for UTRAN
13
2.1.2 HSDPA Traffic Within the RNC
Fig. 2.2 summarizes the HSDPA traffic routed through different cards within the RNC.
Iu
CLP GMUX
DCCH DTCH(PS)
M2C PRLC HSPRLC

DCCH on
FACH/RACH
MHC DHT HSDST
DTCH on DCCH on DTCH
FACH/RACH DCH on DCH
CMP/
WCMP
DTCH (DL)
To/From Iub Interface on HS-DSCH
DTCH (UL)
Iub Interface on A-DCH
DTI/ TINF
MDTI for Iub
RNC
E1-IMA
Iub
E1 E1 E1
STM-1/OC-3
E1-IMA
DTCH (DL) on HS-DSCH

DTCH (UL) on A-DCH
DTCH on FACH/RACH (HS-DSCH to FACH)
DCCH on DCH
DCCH on FACH/RACH
DTCH on DCH (HS-DSCH to DCH)
Fig. 2.2 Cards and traffic routes for HSDPA
14
NOTE
i If 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/s
is required, STM-1/OC-3 should be used for Iub physical lines. See chapter 6 "Transport
Network Layer (TNL) Modifications" for details.
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.
CMP/WCMP HSDST HSPRLC GMUX
PDCP GTP-U GTP-U GTP-U

RLC UDP UDP UDP
MAC-d Internal Internal
FP FP IP IP IP
HS-DSCH
FP (HSDPA) (HSDPA)
AAL2 AAL2-d AAL2-d AAL2-d AAL2-d AAL5 AAL5 AAL5
ATM ATM ATM ATM ATM ATM ATM ATM
RNC
Iub Iu
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
15
Fuse Fuse Fuse PDM PDM
FAN FAN FAN FAN FAN
B-SIGM C-M2CM GTPM B-MHM C-DHTM
B-LSM C-LSM
C-DHTM C-DHTM A-PRM (Basic) B-SIGM C-M2CM
FAN FAN FAN FAN FAN
E-CCPM B-MHM C-CMPM A-PRM (Extended) E-CCPM C-GTPM B-PRM
D-CCPM D-CMPM D-CMPM A-PRM (Extended) D-CCPM A-DTIM
B-LSF C-TRKF A-PRF D-LSF H-TRKF
cRNC/eRNC eRNC
WLSC CMUC/CMUXE HSDST HSPRLC
Modified Firmware New Hardware
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
16
PDM PDM PDM
FAN FAN FAN
WCMP B-MHM C-DHTM B-MHM C-DHTM
C-LSM
SIGM M2CM A-HUBM
FAN FAN FAN
E-CCPM C-GTPM B-PRM B-PRM C-PRM
D-CCPM A-DTIM
D-LSF H-TRKF H-TRKF

Update of existing equipment: 2 x HSDST + 2 x HSPRLC
PDM PDM PDM
FAN FAN FAN
WCMP B-MHM C-DHTM B-MHM C-DHTM
C-LSM
SIGM M2CM A-HUBM
FAN FAN FAN
E-CCPM C-GTPM B-PRM
D-CCPM A-DTIM
D-LSF H-TRKF H-TRKF

New delivery of equipment: 2 x HSDST + 4 x HSPRLC
HSDST HSPRLC
Fig. 2.5 Frame layout of RNC (example) with new HW for update and new delivery
17
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)
025 035 045 055 065 075 085 095 105 115 125 135 145 155 165 175 185 195 205 215 225 235 245 255
HSDST #18
HSDST #19
WCMP #22
WCMP #23
WCMP #28
WCMP #29
WCMP #30
WCMP #31
blank #16
blank #17
blank #20
blank #21
blank #24
blank #25
blank #26
blank #27
HUBIU #1
CLKD #1
WLSC #1
WLSC #0
LSW #0
LSW #1
blank #03
blank #14
blank #15
HUBIU #0
#0
TINF #00
TINF #01
TINF #02
TINF #04
TINF #05
TINF #06
TINF #07
CLKD #0
TINF #08
TINF #09
TINF #10
TINF #11
TINF #12
TINF #13
CLKD
WLSC HSDST
Fig. 2.6 C-LSM face layout of eRNC (example) with new HW and FW-update
18
19
Fig. 2.7
Blank
CMUX #0
HUBIU #0
HUBIU #1
CMUX #1
C1HWM #0
C1HWM 00
C1HWM #1
C1HWM 01
HUBIU 0 HSPRLC 0
HUBIU 1
HSPRLC 1
B-PRM
HSPRLC 0
Blank
HSPRLC 1
Blank
Blank Blank
Blank Blank
Blank Blank
Blank Blank
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16
CMUC/CMUXE
CMUXE #0
Reinforcing Plate
CMUX #0
A-PRM (Extended)
CMUXE #1
HSPRLC
CMUX #1 Blank
Blank
C1HWM 00
Blank
C1HWM 01
Blank
HSPRLC 0 Blank
Blank
C-PRM
HSPRLC 1
Blank
A-PRM/B-PRM/C-PRM face layout (examples) with new HW and FW-update

Blank Blank
Blank Blank
Blank Blank
Blank Blank
Blank Blank
Blank Blank
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
2.1.3.1 New HSDST Card
Specification
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 of 4000 ch/card
channels
Redundancy Single(0/1) The RNC is always equipped with 2
HSDST cards supporting a redundant
load-sharing configuration. If a failure
occurs and the required capacity is
available, the entire traffic load will be
distributed over the other card without
interruption of system operation.
Size 294x324 mm (HxW),
1 slot
Target Power 30 W
consumption
Tab. 2.1 HSDST card specification
RNC SW compatibility
The HSDST card is not backward-compatible, RNC SW release UMR5.0 is 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.
20
2.1.3.2 New HSPRLC Card
Specification
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 of 2016 ch/card
channels
Redundancy Single
Size 294x324 mm (HxW),
2 slots
Target power con- 50 W
sumption
Tab. 2.2 HSPRLC card specification
RNC SW compatibility
The HSPRLC card is not backward compatible. RNC SW release UMR5.0 is 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 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.
21
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.3 shows the HS-DSCH DATA
FRAME Header IE allowed by the HSDST.
22
IE Field Value Comment
length
[bit]
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 PDU 13 336, 656 RLC PDU size is 336 bits or 656 bits.
Length [bits] If multiplexing MAC-d is used, the
MAC-d header which is C/T field (4bits)
is added.
NumOfPDU 8 1..83 83 is the maximum number of MAC-d
PDUs using 336bits RLC PDU size.
When using 656bits, the maximum
number is 43.
User Buffer Size 16 Don’t 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 present
when 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
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 Maxi-
mum MAC-d PDU Length, HS-DSCH Credits, and HS-DSCH Interval. These IEs are
contained in the CAPACITY ALLOCATION message.
Tab. 2.4 shows the CAPACITY ALLOCATION message which the RNC can receive.
IE Field length Value Comment

[bit]
Spare Bit 4 Don't care

CmCH-PI 4 0..15
Maximum MAC-d 13 0..5000
PDU Length [bits]
HS-DSCH Credits 11 0..2047 0 = stop transmission, 2047 = un-
limited. The number of MAC-d PDU
during one HS-DSCH Interval.
HS-DSCH Interval 8 0..255
[10ms]
Tab. 2.4 CAPACITY ALLOCATION message
23
[bit]
HS-DSCH Repeti- 8 Don't care 0 = unlimited repetition period.

tion Period RNC always sets it to 0 in the first
release.
Tab. 2.4 CAPACITY ALLOCATION message
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.5 shows the CAPACITY REQUEST message set up by the HSDST card.

[bit]
Spare Bit 4 Don't care

CmCH-PI 4 0..15
User Buffer Size 16 0..65535 The amount of data pending for the
[octets] respective MAC-d flow for the
CmCH-PI level.
Tab. 2.5 CAPACITY REQUEST message
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.
24
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 traffic
whereas 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 HSPRLC’s PDCP has the following functions:
• Data transfer
• Header Compression
RFC-2507 IP Header Compression is supported
2.1.5.3 Radio Link Control

The HSPRLC’s 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.
25
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 in
the 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.
26
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 B Variant Cell HSDPA Power/ Number of RF modules

type(s) configuration configuration cell [W]
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
4
2/0/0 1/0/0 20 2 2
2/2/04 1/1/0 20 4 4
4
2/2/2 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
27
TRX LPA CAT1 RRH2
NB-88x 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
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
28
TRX LPA CAT1 RRH2
RS-880 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
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
Notes:
1 Available 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
Each of these CATs can be used in combination with DRIC12-12 or DRC24-24OE.
2 Remote Radio Heads (RRHs) can only be used with DRIC24-24OE.
3 If 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.
4
Only 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 B’s other sectors.
5 Applies for CAT40.
6 Applies for CAT20.
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.2 provides 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
29
– off
Indicates that the CHC does not operate in HSDPA mode (Rel 99 traffic only)
Cell configuration 1 HSDPA-capable CHC 2 HSDPA-capable CHCs 3 HSDPA-capable CHCs

installed installed installed
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

With UMR5.0 supporting HSDPA in the Node B, changes have been made to the
Node B’s 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 buff-
er 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.
– 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
– Assigning the HS-PDSCH resources to UEs
– Selecting the appropriate priority queues which are to be served
– 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 B’s 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 is
visible 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.
30
• Transport block assembly
The transport block assembly unit prepares each transport block for further physical
layer 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 B’s 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)
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.
31
3.1.1 Modifications of the Node B’s 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-44x’s and NB-88x’s 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 B’s 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 operation
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.
In UMR5.0, the HSDPA-capable CHCs support UEs of the classes 1 to 6, 11, and 12.
Additionally, these CHCs are hardware-prepared to support all classes of UEs. For de-
tails about UE classes, please refer to "UE Support of HSDPA" on page 44.
In this context, Tab. 3.3 lists the maximum number of HSDPA users possible with the
HSDPA-capable CHCs when a specific uplink radio access bearer is applied.
UL RAB rate AMREQ Maximum number of HSDPA UEs possible with
CHC96 hs-CHC
8 kbit/s 1 96 96
32 kbit/s 2 48 72
64 kbit/s 4 24 36
128 kbit/s 8 12 18
384 kbit/s 16 6 9
Tab. 3.3 Maximum number of HSDPA users depending on the CHC type and
UL RAB rate
32
3.1.1.1 CHC96
The existing CHC96 has already been HW-prepared for HSDPA in releases prior to
UMR5.0. Its SW, however, is updated in order to handle HSDPA traffic in an appropriate
way.
The CHC96 is capable of working in two modes, HSDPA mode and non-HSDPA mode,
where both modes are included in one SW load image. The CC OAM SW then config-
ures the CHC96 to operate in the relevant mode. Changing the mode of operation re-
quires a partial reset of the CHC96, i.e. only selected DSPs (digital signal processors)
are reset. Since this partial reset is performed internally by the CHC96, the CC does not
have to act directly. It is therefore recommended to change the mode of operation only
when no calls are ongoing and no cells are set up on that CHC96. Otherwise, ongoing
calls will be lost.
In non-HSDPA mode, no HSDPA-specific channels and functions are supported. When
operating in this mode, the CHC96’s 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 and HSD-
PA-specific channels and functions simultaneously. As far as normal channels are con-
cerned, the number of AMREQs, however, is reduced compared to non-HSDPA mode.
Thus, with regard to normal channels the CHC96’s performance is equal to 96 CEs and
an AMREQ of 96.
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 and HSDPA. In other words, the hs-CHC simultaneously supports
HSDPA-specific channels and functions as well as normal channels. With regard to nor-
mal channels the hs-CHC’s performance is equal to 96 CEs and an AMREQ of 144.
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 of
16QAM 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 by re-
ducing the transmit signal power by approximately 0.7 dB. The MAC-hs scheduler con-
trols the transmit power reduction. When the scheduler decides to use 16QAM, it
substracts the necessary transmit power reduction value from the total HSDPA signal
power. The reduction of the transmit power is only applied if 16QAM is used on at least
one HS-PDSCH. The quality of DCHs does not suffer from using 16QAM.
33
3.1.3 Modifications of Call Processing
Compared to the existing CHC’s (CHC48 and CHC96 without support of HSDPA) mode
of operation, the resources are used in a different way inside the Node B. The following
resources 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.4 for 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.
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 in
order 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.
34
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 measurements
used 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 by
UMR5.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
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 plane’s NBAP procedures, described in
"Modifications of Call Processing" on page 34.
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 145.
3.1.4.2 UTOPIA Connection Handling on the CC-BB Interface

In the Node B, UTOPIA’s (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.
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 B’s 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.
36
3.1.5.2 Flow Control
The Node B’s 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 "Flow
Control" on page 145.
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
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 “Proportional
Fair“ 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 38.
The Proportional Fair scheduler, on the other hand, provides a fairer distribution of
transmission bandwidth among the HSDPA users within a radio cell. Thus, the Propor-
tional Fair scheduler assures that all HSDPA users within this cell will benefit from the
availability of HSDPA. For more details about this scheduler, refer to the FD012251 -
Proportional 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 take
into account restrictions arising from UE capabilities and those which are implied by
the optional feature handling.
37
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 current
packet are combined, thus attempting to recover from the errors. Eventually, either the
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 transmitted
redundant 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" on
page 155 provides a description of the new and modified PM counters for the support of
HSDPA.
38
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 is the HS-PDSCH.
The scrambling code and the channelization codes for the spreader units are configured
when HSDPA is set up in a UTRAN cell. In other words, their configuration is a direct
consequence of an NBAP: Physical Shared Channel Reconfiguration procedure.
The following list provides information about the channel configuration and thus also
about the signal processing in DL direction:
• HS-SCCH
The HS-SCCH is the DL control channel for HSDPA. The information carried on this
channel enables UEs to receive the HS-PDSCH.
In HSDPA mode, the HSDPA-capable CHC processes up to 4 HS-SCCHs per cell,
up to 3 HSDPA cells being supported.
One spreader unit is provided per CHC. The spreading factor (SF) is 128.
• HS-DSCH / HS-PDSCH
The HS-PDSCH is the DL data channel carrying the user data.
The HS-DSCH’s spreading factor is 16.
The HSDPA-capable CHC supports both HS-PDSCH slot format “0” and slot
format “1”, indicating QPSK and 16QAM, respectively.
In HSDPA mode of operation, the HSDPA-capable CHC is able to process one up to
15 HS-PDSCHs per HSDPA cell. The maximum total number of HS-PDSCH chan-
nelization codes supported is 15. Depending on the number of HSDPA cells that are
set up, this maximum number of codes can be split between these, up to three, cells.
However, these codes must be distributed symmetrically among all HSDPA cells
which the Node B serves. In other words, all HSDPA cells which are subordinated to
the same Node B are assigned the same number of HS-PDSCH channelization
codes.
Furthermore, if the 16QAM modulation scheme is applied, the HSDPA-capable CHC
can process a total of up to 15 HS-PDSCH channelization codes for all HSDPA cells.
Otherwise, if only QPSK modulation is applied, the CHC is capable of processing
30 HSDPA channelization codes in total and up to 15 codes per cell. Tab. 3.4 illus-
trates this:
39
Cell mode 16QAM/QPSK modulation QPSK-only modulation
1-cell mode 15 15
2-cell mode 7 15
3-cell mode 5 10
Tab. 3.4 Maximum number of HS-PDSCHs on a single HSDPA-capable CHC
• DPCH
The DPCH (dedicated physical channel) is the corresponding physical channel to
the DCH.
In addition to the HSDPA processing specified above, DPCH processing is support-
ed simultaneously. The DPCH processing resources, however, are reduced com-
pared to the HSDPA-capable CHC’s non-HSDPA mode. When the HSDPA-capable
CHC works in HSDPA mode, the DPCH symbol rate processing capacity guarantees
simultaneous processing of up to 96 AMREQs or 144 AMREQs on the DL when the
CHC96 or the hs-CHC, respectively, is used.
3.1.6.2 Uplink Signal Processing

Uplink 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
supports a physical channel required to provide HSDPA: HS-DPCCH.
The following list provides information about the channel configuration and thus also
about the signal processing in the UL direction:
• DPCH
The chip rate processing capacity guarantees the simultaneous processing of up to
96 elementary UL DPCHs originating from up to 96 different UEs. Furthermore,
when operating in HSDPA mode, the CHC’s DPCH symbol rate processing capacity
guarantees the simultaneous processing of up to 96 AMREQs or 144 AMREQs on
the UL when the CHC96 or the hs-CHC, respectively, is used.
• HS-DPCCH
For each UL DPCH, the HSDPA-capable CHC is capable of simultaneously process-
ing one HS-DPCCH originating from the same UE. Therefore, the overall chip rate
processing capacity guarantees simultaneous processing of up to 96 elementary
operations, each including one DPCH and one HS-DPCCH originating from the
same UE.
The HS-DPCCH carries the CQI of the corresponding UE, for example.
3.1.7 Modifications of Power Control

The priorities of both CCHs and DCHs are higher than those of the HS-DSCH and of
HS-SCCHs for HSDPA service. For this reason, the MAC-hs scheduler provides only
that power for HSDPA service which remains after assigning the power to CCHs and
DCHs.
40
In UMR5.0, the packet scheduler for HSDPA traffic is implemented in the Node B rather
than in the RNC where the scheduler for Rel 99 traffic is situated. Furthermore, the HS-
DSCH terminated in Node B’s MAC-hs layer is the only UTRAN transport channel not
terminated in the RNC. Using the HS-DSCH enables several users to be time-multi-
plexed, thus making the resources available to other users during silent periods.
The modulator on the TRX or DRIC cards takes care of the new modulation scheme.
Additionally, the Node B’s power amplifiers provide a higher linearity for 16QAM.
The main functionalities of HSDPA are concentrated on the Node B’s CHC. One of the
following actions therefore becomes necessary:
• SW upgrade of the existing CHC96
• Installation of the new hs-CHC
3.2.1 Core Controller (CC)

In UMR5.0, the CC contains the logical functional entities for the following issues:
• TNL management
The increased throughput at the Iub interface and the enhanced QoS parameters of
the AAL2 connections require modifications concerning the TNL management. Fur-
thermore, the CC provides an interface for multiplexing and demultiplexing UTOPIA
(AAL5 and AAL2d) cells from and to UTOPIA.
• NBAP processing
The CC forwards the transmit power measurements from the TRX and DRIC cards
to the HSDPA scheduler.
Furthermore, the modified admission control algorithm is implemented in the core
controller. With this release, the CC therefore uses the non-HSDPA power instead
of the transmitted carrier power.
• Resource management
3.2.2 Channel Coding Card (CHC)

The HSDPA-capable CHC provides the MAC-hs functions as well as functionalities for
HSDPA power control, HSDPA signal processing, and HSDPA priority queue manage-
ment. The MAC-hs, to be more precise, contains the following functional entities:
• Scheduler
• HARQ
• Flow control
• Transmission control
3.2.3 Repeater (REP)

The REP remains unchanged in comparison with the product release prior to UMR5.0.
In other words, the REP module performs data transport between the CHCs and the
TRX or DRIC cards.
3.2.4 Transceiver (TRX) or Digital Radio Interface Card (DRIC)

These hardware cards accommodate the functionality for the new 16QAM modulation
scheme. As described in the chapter about "Modifications of Radio Frequency (RF) Is-
sues" on page 33, the currently installed HW can be reused for 16QAM.
41
The front panel of the new hs-CHC serves as a direct man-machine interface (MMI) for
the operator by offering the following:
• Front Panel Indicators
• Front Panel Connectors
• Manual Intervention
3.3.1 Front Panel Indicators

The look and feel of the hs-CHC is the same as that of the pre-HSDPA CHC. The hs-
CHC indicates its state to the user, thus indicating the status of the card in terms of
• Administrative state (AST)
• Operational state (OST)
• Alarm status (ALS)
• Availability status (AVS)
The hs-CHC visually indicates whether a module is providing HSDPA service. Further-
more, the hs-CHC physically and logically controls the functionality of HSDPA upon es-
tablishment and release of HSDPA processing resources.
In order to identify the hs-CHC, the card is provided with a new label.
3.3.2 Front Panel Connectors

The hs-CHC’s front panel connectors and the accessible functionality by way of these
front panel connectors match those of the pre-HSDPA CHC48.
3.3.3 Manual Intervention

A mechanism is provided for resetting and locking the hs-CHC by way of the front panel.

Not yet applicable.
42
4 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. The cell where the
HS-DSCH is currently established is called the serving HS-DSCH cell. The quality of the
serving HS-DSCH cell constantly varies due to the mobility of the UE. If the quality is
degraded or the serving HS-DSCH cell is deleted, the SRNC needs to move the serving
function to another cell where the quality is good. Furthermore, the UE may enter or
leave the area where HSDPA is supported. In this case, the SRNC performs channel-
type switching from DCH to HS-DSCH or from HS-DSCH to DCH.
The following UE mobility scenarios are supported within UMR5.0:
• HS-DSCH establishment (when the UE is in Cell_DCH or Cell_FACH state)
– Intrafrequency, intra-SRNC, intra-Node B handover
– Interfrequency, intra-SRNC, intra-Node B handover (at channel-type-switching
from FACH to HS-DSCH)
• Inward mobility (DCH -> HS-DSCH)
• Change of the serving HS-DSCH cell
– Intrafrequency, intra-RNC, intra-Node B handover
• Outward mobility (HS-DSCH -> DCH)
– Intrafrequency, intra-SRNC, inter-Node B handover
– Intrafrequency, inter-RNC handover
– Intrafrequency, inter-RNC (SRNC) relocation
– Interfrequency, intra-SRNC, inter-Node B handover
4.1.1 HSDPA RAB Handling

This section describes:
• The criteria for establishment and release of a RAB on HSDPA
The criteria for assigning HSDPA resources take into account:
– UE capabilities, in particular: whether or not the UE supports HSDPA
– RAB type, since not all RABs are suitable to be supported on HSDPA
– RAB combination
– Activity level of the RAB
• The procedures and information elements that enable bearer management in an
HSDPA system
43
4.1.1.1 UE Support of HSDPA
The SRNC uses the UE capabilities to determine whether or not the UE supports
HSDPA and if so, which HS-DSCH category it belongs to.
The SRNC determines the UE to be HSDPA capable if the following conditions are both
true:
• The “UE Radio Access Capability” IE indicates that the UE is release 5 and that it
supports HSDPA.
• The HSDPA feature is enabled.
Otherwise, the SRNC considers the UE as non-HSDPA capable.
The SRNC determines this information during RRC connection establishment, inter-
RAT handover to UTRAN, or SRNS relocation. It may be necessary to obtain the
information via UE capability enquiry. If the UE is considered capable of HSDPA, the UE
provides the HS-DSCH category to which it belongs.
3GPP TS 25.306 “UE Radio Access Capabilities” defines 12 HS-DSCH categories.
UMR5.0 supports UE categories 1-6, 11, and 12. Tab. 4.1 shows the information de-
fined for all HS-DSCH categories.
Parameter Usage
Maximum number of HS-DSCH codes To determine the number of HS-PDSCH

received channels that the UE can receive in any
TTI
Minimum inter-TTI interval To determine the number of TTIs between
consecutive HS-DSCH transmissions
Maximum number of bits of an HS-DSCH To determine the maximum amount of data
transport block received within an HS- to be transmitted to the UE per TTI. The
DSCH TTI amount of data is the size of MAC-hs PDU.
Total number of soft channel bits To determine the Process Memory Sizes of
all the HARQ processes.
Maximum number of AM RLC entities RNC uses 3 AM entities for SRB and also
1 per PS BE or PS Streaming RAB.
Minimum total RLC and MAC-hs buffer 3GPP TS 25.306 “UE Radio Access
size Capabilities” defines the minimum value,
but the actual value is signaled explicitly
and its usage is described in the section
"Impacts on the Radio Bearer Translation"
on page 47.
Tab. 4.1 Information defined for all HS-DSCH categories
44
4.1.1.2 RAB Eligibility for HSDPA
The decision whether a RAB is eligible to be assigned to the HS-DSCH is based on:
• The requesting CN domain (CS/PS)
• The traffic class (conversational/streaming/interactive/background)
PS interactive and PS background RABs are supported on the HSDPA channel. All PS
interactive/background RABs belonging to Release 5 UEs supporting HSDPA are
specified as eligible for HSDPA even if they cannot be assigned on an HS-DSCH due
to their location or the RAB combination.
CS RABs and PS conversational RABs are not eligible for HS-DSCH and can only be
supported on DCH. This is because these RABs have very strict delay requirements
which are difficult to meet with a shared resource such as HS-DSCH.
4.1.1.3 Radio Bearer Combinations

The Single PS BE RAB + DCCH radio bearer combination uses the HS-DSCH resource:
• The PS BE RAB is mapped onto the HS-DSCH in the downlink.
It uses a bidirectional DCH with zero rate on the downlink.
• The DCCH is mapped onto a bidirectional DCH.
A PS interactive/background RAB is used with PS (UL: 64 kbit/s, DL: 0 kbit/s) +
PS (UL: 384 kbit/s, DL: 0 kbit/s) in combination with HS-DSCH on the downlink.
Any other radio bearer combination is mapped onto DCH only or onto DCH/FACH for
the DCCH only radio bearer combination, see Tab. 4.2.
Radio bearer combination Transport channels Notes

supported
DCCH DCH/CCH
DCCH + CS Conversational DCH
DCCH + CS Streaming DCH
DCCH + PS BE HS-DSCH+DCH/DCH/CCH DCH only when
HS-DSCH is unavailable
DCCH + CS Conversational DCH
+ PS BE
DCCH + PS Conversational DCH
+ PS BE
DCCH + PS Streaming + DCH
PS BE
Tab. 4.2 Radio bearer combinations
45
4.1.1.4 RAB Multiplexing Options
A PS RAB that is a candidate for HSDPA may also be mapped onto DCH and FACH
during its existence. Traffic monitoring can trigger channel-type switching between
HS-DSCH and FACH while the RAB stays on HSDPA-enabled cells. DCH can be used
for these RABs if the RAB combination changes or the RAB moves out of the HSDPA-
enabled cells.
The “RB Mapping Info” IE is used to configure these options in the UE:
• Multiplexing option 1 (for PS RABs in Cell_FACH state):
– UL transport channel type = RACH
– DL transport channel type = FACH
• Multiplexing option 2 (for PS RABs in Cell_DCH state):
– UL transport channel type = DCH
– DL transport channel type = DCH
• Multiplexing option 3 (for HSDPA):
– UL transport channel type =DCH
– DL transport channel type = HS-DSCH
The radio bearer mapping configuration of multiplexing option 3 requires:
• The MAC-d flow in the DL is configured in the UE and the DCH may be configured
if HS-DSCH is intended for use in the DL.
• The DCH is configured in the UE in the DL and the MAC-d flow is not configured if
DCH is intended for use in the DL.
This behavior is achieved by deleting the MAC-d flow when the use of HS-DSCH is
stopped. If the UE is in Cell_DCH state and the MAC-d flow exists, the UE always uses
the multiplexing option with HS-DSCH in the DL. If the MAC-d flow does not exist while
the DCH does exist, the UE uses the multiplexing option with DCH in the DL. Further-
more, the multiplexing option DCH + HS-DSCH is defined in 25.331 but it is not support-
ed by early HSDPA UEs.
The multiplexing options are assigned upon RAB setup for all RABs that are HSDPA-
eligible if the UE supports HSDPA. The multiplexing options are not reconfigured when
the UE’s RAB combination changes or the UE moves in or out of HSDPA-enabled areas.
Furthermore, the “RB Mapping Info” IE is sent to HSDPA-capable UEs during SRNS
relocation of HSDPA-eligible RABs. This includes the HS-DSCH multiplexing option to
allow for any future channel-type switching to HS-DSCH in the target RNC.
If a single PS RAB is used, this PS RAB is mapped onto a single MAC-d flow. The
MAC-d flow is supported on a single transport bearer on the Iub/Iur interface and is then
fed into a single priority queue in MAC-hs. In the HS-DSCH information sent to the
Node B for this configuration there is one MAC-d flow list element and one priority queue
list element which references the only MAC-d flow list element for the UE context. The
priority queue is used to route the data to the appropriate queue and to prioritize the
data. The priority queue is assigned to a “Scheduling Priority Indicator” in the HS-DSCH
FP DATA FRAME as CmCH-PI. For details, please refer to Tab. 2.3 in "HS-DSCH
DATA FRAME" on page 22 and "Priority Queue Management" on page 146.
The “Scheduling Priority Indicator” is based on the “Traffic Class” and the “Traffic
Handling Priority” IEs. These IEs are received with the RAB parameters of the RAB
ASSIGNMENT REQUEST message, see Tab. 4.3.
46
Traffic class Traffic handling priority Scheduling priority indicator
Interactive 1 (highest) 15
... ...
15 (lowest) 1
Background N/A 0
Tab. 4.3 RAB parameters in the RAB ASSIGNMENT REQUEST message
4.1.1.5 Impacts on the Radio Bearer Translation

The radio bearer translation algorithm is used to generate configuration parameters
derived from the RAB parameters and the UE capabilities. The results provide
information on:
• The radio bearer (radio link control, RLC)
• The transport channel (for example DCH)
• Physical channel information
Fig. 4.1 shows the related algorithm, which is a table driven mechanism with various
substeps.
47
RAB M1
RAB
207, 209 AAL2/5
Establishment 212-219
RRC RB Type RLC/RB Info
Connection 208, 210
Establishment
RAB M5
RAB Release Combination + 291, 292 Combination
UE Capability Allowed/
Class Not Allowed
Max UE Supported
Rate for PS BE
RAB Type + Rate (PS BE) M2

BRA/CTS 227, 228
205, 206
DCH Type TFS
UE Physical Layer Category M6 New

optional
XXX step for
HS-DSCH Info HSDPA
DCH
Combination M3
220, 221
278, 279
TFCS Type TFSC
DCH
Combination + Rate M4
220, 221
202, 203
DPCH Type Physical CH Par
Fig. 4.1 Radio bearer translation steps
The following relation is valid upon PS BE establishment and channel-type switching

from FACH to DCH (+ HS-DSCH):
Rate in step M2 = Initial Rate ∈[RNC supported rate list] RAB Combination
where subsequently (due to bit rate adaptation):
Rate ∈ [minimum rate, …, maximum rate] ∈ [RNC supported rates]RAB combination
The radio bearer translation algorithm outputs an HS-DSCH configuration in addition to
the DCH configuration which exist in parallel, see Fig. 4.2. If the DTCH is mapped onto
the HS-DSCH in the DL because the UE has selected the multiplexing option with
HS-DSCH in the DL, the DL DCH still exists and is configured to 0 kbit/s.
48
DL UL
DCCH DTCH DCCH DTCH
DCH DCH HS-DSCH DCH DCH
DPCH DPCH
Fig. 4.2 HS-DSCH and DCH configuration
If HS-DSCH is required, the RAB combination allows HSDPA usage, and a suitable cell
is available, call processing (CP) provides the “HS-DSCH Required” indicator and the
“UE HS-DSCH Physical Layer Category” upon request for:
• PS BE RAB establishment
• Channel-type switching (FACH to DCH + HS-DSCH)
• Channel-type switching (DCH to DCH + HS-DSCH)
The SRNC retries the algorithm without the “HS-DSCH required” indicator if the
“UE HS-DSCH Physical Layer” category is not part of the radio bearer translation tables.
In this case, the UE connection will be established on DCH instead of HS-DSCH.
The radio bearer translation mechanism calculates the initial, maximum, and minimum
rates for UL and DL DCH during step M2 if HS-DSCH is requested by call processing.
The minimum rate is the rate supported by the RNC which is closest to the UL: 0 kbit/s,
DL: 0 kbit/s rate combination.
Initial rate and maximum rate are selected within step M2 in three steps:
• Step 1
The RNC creates a list of permitted rates from the list of RNC supported UL/DL PS
BE DCH rates in the service combination such that all rates are equal to or less than
the maximum rate supported by the UE. A table of permitted UL/DL DCH data rate
combinations exists for each RAB combination which uses HSDPA.
The maximum UE supported rate for the UL is calculated in the same way as for non-
HS-DSCH configurations. The maximum UE-supported rate for the DL, however, is
not taken into account since the maximum DCH rate that is used in the DL is set to
0 kbit/s. Therefore, the “DL Capability with Simultaneous HS-DSCH Configuration”
IE from the “UE Radio Access Capability” IE is ignored.
• Step 2
The RNC filters the list of permitted rates from step 1 such that all rates are equal to
or less than the maximum bit rate requested from the core network. If HSDPA is
used, this check is performed for the set of UL rates only. In other words, the UL DCH
rates from step 1 are compared with the “UL Maximum Bit Rate” value received in
the RAB parameters.
49
• Step 3
The RNC selects from the list of permitted rates the initial and maximum rates that
can be used during bit rate adaptation with the new service combination:
– Initial Rate:
64 kbit/s is the system data value of the initial UL rate if HS-DSCH is used on the
DL. The RNC therefore restricts the permitted rates such that all rates are equal
to or less than 64 kbit/s. The governing procedure fails if no rate is left in the list
of permitted rates. The RNC selects the rate which is closest to the maximum bit
rate requested by the core network if more than one permitted rate remains in the
list.
– Maximum rate:
If more than one permitted rate remains in the list after step 2, the RNC selects
the rate which is closest to the maximum bit rate requested by the core network.
The closest rate is defined as the UL/DL permitted rate with the smallest distance:
( x1 – xi ) + ( y1 – yi )
2 2
di =
where (x1, y1) is the coordinate for the maximum bit rate requested by the core network
and (yi, yi) is the coordinate of the permitted rates. The DL rate is set to 0 kbit/s if HSDPA
is used. Therefore, two data rate combinations cannot be equally close to the maximum
bit rate requested by the core network.
Bit rate adaptation uses the pool of rates that were output from step 2 of M2. Only the
UL DCH rate increases or decreases according to traffic activity if HSDPA is used. The
DL DCH rate is fixed at 0 kbit/s.
The new step M6 is introduced to obtain the HS-DSCH parameters. If the radio bearer
translation receives the “HS-DSCH Required” indicator and the “HS-DSCH UE”
category, a new table is used to obtain HS-DSCH information from the “UE HSDPA”
category.
The HS-DSCH-related information consists of the following:
• MAC-hs window size
• T1
• AAL2 parameters (MAC-d flow)
If DCH is used, the RLC Tx/Rx window sizes of AM RLC RABs are based on the radio
bearer type which is determined from the RAB parameters. The radio bearer type is
limited to 384 kbit/s in the DL (largest DCH rate). If the core network signals maximum
bit rates above 384 kbit/s, they are assumed to be equal to 384 kbit/s, which results in
window sizes tuned for 384 kbit/s.
If HSDPA is used, the RLC window sizes are selected according to the available
memory in the UE rather than on the basis of a DL rate parameter supplied by the core
network. The DL rate signaled by the RAB parameters and supported on the air inter-
face may be much larger than 384 kbit/s. The maximum rate is limited by the UE capa-
bility class. The maximum rate also depends on the RLC window sizes, which in turn
depend on the UE’s available memory.
50
This method of selecting the window size for an AM RLC RAB is applied if all of the
following conditions are valid:
1. The UE is HSDPA-capable
2. The UE has RAB combinations with only one AM RLC RAB
– PS BE
– PS BE + CS (any)
– PS BE + PS Conversational
The window size is derived from the radio bearer type for all non-HSDPA-capable UEs
and for HSDPA-capable UEs using a RAB combination involving more than one AM
RLC RAB, for example PS BE + PS Streaming.
Tab. 4.4 shows the new system data table for the selection of the RLC window size for
HSDPA-capable UEs with one AM RLC RAB.
UE memory [kbytes] RLC window size
50 DL: 1024; UL: 128

100 DL: 1536; UL: 512
150 DL: 3072; UL: 512
>150 DL: 4095; UL: 512
Tab. 4.4 RLC window sizes for HSDPA-capable UEs with one AM RLC RAB
The UE memory is taken from the “Total RLC AM buffer size” IE sent in the “UE Radio
Access Capabilities” in the RRC CONNECTION SETUP COMPLETE message.
Furthermore, the RNC takes into account the “Maximum RLC AM Window Size” IE also
sent in the “UE Radio Access Capabilities”. The RNC assigns the memory size as the
minimum Min (Maximum RLC AM Window Size, RLC Window Size from table).
The UL window also increases with increasing memory with the proposed window sizes
in Tab. 4.4. This is to allow a 384 kbit/s bearer on the UL. If UL bit rate adaptation oc-
curs, the UL window size remains the same. However, a large UL window that is perma-
nently specified reduces the memory available for the DL. If the UE only supplies a small
memory, the DL is prioritized and as a result the UL: 384 kbit/s bearer may not be useful.
51
4.1.1.6 RRC Connection State Model
Fig. 4.3 shows the RRC connection state model for HSDPA. PS streaming/conversa-
tional + PS BE combinations are not shown. These RAB combinations are supported on
DCH. Channel-type switching from HS-DSCH to DCH occurs if a PS streaming/conver-
sational RAB is added to an existing PS BE RAB and this PS BE RAB is currently on
HS-DSCH. RAB establishment resulting in a single PS BE RAB leads to HS-DSCH
assignment.
If the PS streaming/conversational RAB of a PS streaming/conversational + PS BE RAB
combination is released, a switch to Cell_FACH state is performed. If the CS (AMR/UDI)
RAB of a CS (AMR/UDI) + PS BE RAB combination is released, a switch from
DCH_ACTIVE state to Cell_DCH or Cell_FACH state takes place, that is, a switch to
HS-DSCH never occurs. If one PS BE RAB of a PS BE + PS BE RAB combination is
released, the connection remains in Cell_DCH/Cell_FACH state or moves from
Cell_DCH to Cell_FACH state, that is, the UE is not switched to use HS-DSCH.
DCH ACTIVE
Cell_DCH
CS RAB setup
or release
Leaving HSDPA
Cell_DCH + coverage;
HS-DSCH 2nd PS BE RAB
setup
CS RAB setup
CTS triggers CTS triggers

HSDPA cell HSDPA cell
available unavailable
Cell_FACH CS RAB setup

or release
DCH INACTIVE
Cell_PCH CS RAB setup or release
Fig. 4.3 UE state model for HSDPA
52
4.1.1.7 Traffic Monitoring and Channel-Type Switching
Traffic monitoring of a PS RAB covers:
• In the RNC:
– Traffic volume measurements
– Buffer utilization
– Inactivity/activity detection
• In the UE:
– Traffic volume measurements
If the UL direction of a PS RAB remains on DCH whereas the DL is assigned to
HS-DSCH, no bit rate adaptation trigger is needed in the DL since bit rate adaptation is
not performed on HS-DSCH. Therefore, buffer utilization and buffer volume measure-
ments are not configured. In the UL, bit rate adaptation is possible and UE measure-
ments 4A and 4B are used. Measurement events 4A and 4B are only configured if there
is an available rate for the UL which is higher or lower than the current UL rate.
Channel-type switching from HS-DSCH to FACH is triggered if inactivity is detected in
both UL and DL. This is the same trigger as for channel-type switching from Cell_DCH
to Cell_FACH state. The hysteresis time for switching from HS-DSCH to FACH due to
inactivity detection can be specified by the operator. Channel-type switching from FACH
to HS-DSCH is caused by PS RAB buffer overflow in UL or DL. This is the same trigger
as for channel-type switching from FACH to DCH. The existing trigger for channel-type
switching from FACH to DCH due to initial direct transfer is unaffected by the introduc-
tion of HSDPA.
Bit rate adaptation is not applicable while the DL uses HS-DSCH. The UL, however,
resides on DCH and bit rate adaptation is possible. On reception of events 4A and 4B,
bit rate adaptation to a higher or lower rate is triggered. Node B dedicated measure-
ments for the DL transmitted code power (Radio Link Quality measurements) are not
used while HS-DSCH is on the DL. These measurements are only applicable for
controlling the DL power if the PS BE RAB uses DCH.
4.1.1.8 Power Control and Measurement Feedback Parameters

Tab. 4.5 shows parameters provided by the SRNC. These parameters are read from
OAM data. One set of parameters per UE HS-DSCH physical layer category is
supported.
NBAP/RNSAP name RRC name Range Purpose

CQI Feedback Cycle k CQI Feedback cycle, k Integer (0, 2, 4, 8, 10, Period of repetition of a CQI
20, 40, 80, 160) measurement report
CQI Repetition Factor CQI repetition factor Integer (1..4) Number of repetitions of a
CQI report. Not necessary
when CQI Feedback Cycle
k = 0.
ACK-NACK Repetition Ack-Nack repetition factor Integer (1..4) Number of repetitions of
Factor ACK/NACK reports
Tab. 4.5 Power control and measurement feedback parameters (SRNC)
53
CQI Power Offset ∆CQI Integer (0..8) Power offset used in the UL
between the HS-DPCCH
slots carrying CQI informa-
tion and the associated
DPCCH
ACK Power Offset ∆ACK Integer (0..8) Power offset used in the UL
slot carrying HARQ ACK in-
formation and the associat-
ed DPCCH
NACK Power Offset ∆NACK Integer (0..8) Power offset used in the UL
slot carrying HARQ NACK
information and the associ-
ated DPCCH
HS-SCCH Power Offset N/A -32 .. + 31.75 dB Power offset of HS-SCCH
relative to the pilot bits on
the DL DPCCH
Tab. 4.5 Power control and measurement feedback parameters (SRNC)
Tab. 4.6 shows the parameter provided by the CRNC. This parameter is cell-specific
and taken from the cell object.
Measurement Power Offset POhsdsch -6..13 dB Default Power offset between HS-
PDSCH and P-CPICH/S-CPICH.
Tab. 4.6 Power control and measurement feedback parameters (CRNC)
4.1.1.9 RAB Setup Procedure from DCH to HS-DSCH

RAB setup from DCH to HS-DSCH is triggered upon reception of a RAB ASSIGNMENT
REQUEST message for a PS interactive or background RAB with the following
preconditions:
1. The radio bearer combination currently contains only DCCH.
2. The UE supports HSDPA.
3. The UE is in Cell_DCH state.
4. The UE is not in compressed mode at the time when the RAB assignment request
is received.
The procedures to establish the RAB on DCH are initiated if the condition 1, 2, or 4 is
not true. If condition 3 is not true, see "RAB Setup Procedure from FACH to HS-DSCH"
on page 58.
The first step is the selection of an HS-DSCH RL ID that is the RL ID of the cell where
the HSDPA resources will be established. The cell selection is described in "HSDPA
Mobility Handling" on page 73. Afterward, the radio bearer translation algorithm is
called, see "Impacts on the Radio Bearer Translation" on page 47. This produces the
54
MAC-d flow information and the priority queue information for the HS-DSCH
configuration.
The SRNC-based power offset and measurement-related parameters are generated,
see "Power Control and Measurement Feedback Parameters" on page 53. Then the
SRNC initiates the synchronized RL reconfiguration preparation procedure to the
CRNC. This is a local procedure as HS-DSCH via the Iur interface is not supported and
cells in the DRNC are taken into account as non-HSDPA-capable.
The UL part of the PS BE RAB is established on DCH. Therefore, all Node Bs in the
active set are configured with UL DCH information and UL physical channel information.
The “DCH Specific Info” IE contains a mandatory UL and DL transport format set. When
HS-DSCH is used on the DL, the DL TFS of the DCH associated with the PS BE RAB
is set up and configured to 0 kbit/s using a TFS with one TF. The number of transport
blocks contained is set to “zero”.
Since the UE is assigned to an HS-DSCH resource belonging to a particular cell within
a particular Node B, only the affected Node B is configured with the HS-DSCH
configuration parameters and the affected cell within that Node B is identified by the
HS-DSCH RL ID.
The admission control is performed in the CRNC, see "HSDPA Admission Control and
Congestion Control" on page 99. If the resources are admitted, the CRNC allocates an
HS-DSCH RNTI such that it is unique for the selected cell, see "Allocation of H-RNTI"
on page 72. Additionally, the CRNC allocates the “Measurement Power Offset” param-
eter, see "Power Control and Measurement Feedback Parameters" on page 53. Then
the CRNC initiates the NBAP synchronized RL reconfiguration preparation procedure.
The NBAP: RL RECONFIGURATION PREPARE message contains the following
information:
• For all Node Bs:
– DCH/DPCH information
• For the Node B containing HS-PDSCH RL ID:
– MAC-d flow/priority queue configuration
– Power offset and measurement feedback information
– H-RNTI
– HS-PDSCH RL ID
The Node B assigns the codes after receiving the HS-DSCH information. Furthermore,
the Node B configures the MAC-hs entity, HARQ processes, and scheduler with the
received information.
The NBAP: RL RECONFIGURATION READY message contains the following
information:
• From all Node Bs:
– TNL address info DCH: UL PS DTCH (for ALCAP)
• From the Node B containing HS-PDSCH RL ID:
– MAC-d flow TNL address info (for ALCAP)
– Initial capacity information
– The HS-SCCH code information
– The HARQ memory partitioning information
The CRNC sends the received information to the colocated SRNC upon reception of the
NBAP RL RECONFIGURATION READY message. The SRNC initiates the ALCAP
transport bearer establishment procedures. The transport bearer for the DCH part
carries the UL DTCH and is established toward all Node Bs/DRNCs in the active set. If
55
the “Transport Bearer Modification Feature” flag is set to “ON” for the DL direction of this
DCH, the link characteristics for connection admission control (CAC) are set to the DCH
rate used, that is 0 kbit/s. Otherwise, they remain configured according to the maximum
rate that this DCH may use. The transport bearer for the MAC-d flow is established
toward the Node B containing the HS-DSCH RL ID.
The NBAP: RL reconfiguration commit procedures are initiated after successful
completion of the transport bearer establishment procedures and the RRC radio bearer
setup procedure is initiated.
The UE is configured with the following information:
• H-RNTI (from CRNC)
• Within the “RB mapping info” IE:
– Multiplexing options, see "RAB Multiplexing Options" on page 46
• Within the “Added or Reconfigured DL TrCH Information” IE:
– HARQ process information (from Node B)
– MAC-d flow/priority queue configuration (from SRNC: RBT)
– MAC-hs reset indicator set to “true”
• Within the “Downlink HS-PDSCH Information” IE:
– HS-SCCH code set information (from Node B)
– Measurement feedback information (from SRNC/CRNC)
• Within the “Uplink DPCH Power Control Info” IE:
– ACK/NACK control info (SRNC)
• Within the “Downlink information for each radio link” IE corresponding to selected
HSDPA serving cell:
– Serving HS-DSCH radio link indicator
The procedure finishes upon reception of the RRC: RADIO BEARER SETUP
COMPLETE message.
The following failures result in the RAB establishment procedure failing:
• NBAP: RL reconfiguration reparation failure with an NBAP cause not equal to
“not enough user plane processing resources”
• ALCAP: TB setup failure
• RRC: radio bearer setup failure
In the event of these failures, a RAB ASSIGNMENT RESPONSE message is sent to the
core network indicating that establishment of the RAB failed. Any resources established
for the RAB are released. If an RRC RADIO BEARER SETUP FAILURE message is
received, a radio failure occurs which results in dropping the RRC connection since the
Node B is already committed to the new configuration. The reason is that RRC
connection reestablishment is only supported if a RAB exists.
The following failures result in a retry on DCH:
• Admission control failure including an NBAP: RL reconfiguration failure with the
cause “not enough user plane processing resources”. For more information see
"Pre-emption and Interaction with Admission Control" on page 71.
Fig. 4.4 shows the message sequence chart for RAB setup (DCH to HS-DSCH).
56
UE Node 1 Node B2 SRNC
Decision to establish RAB

RLs already exist
HSDPA Cell Selection
Allocate HS-DSCH RNTI
NBAP: RL RECONFIGURATION PREPARE DCH to add (UL DTCH)

HS-DSCH to add
HS-DSCH RNTI
HS-PDSCH RL ID
NBAP: RL RECONFIGURATION READY

DCH Information Response
HS-DSCH FDD Information Response
NBAP: RL RECONFIGURATION PREPARE

DCH to add (UL DTCH)

DCH Information Response
ALCAP Iub Transport Bearer Setup (HS-DSCH)
ALCAP Iub Transport Bearer Setup (UL DCH)
ALCAP Iub Transport Bearer Setup (UL DCH)
NBAP: RL RECONFIGURATION COMMIT
New H-RNTI
RRC: RADIO BEARER SETUP Downlink HS-PDSCH Iinformation
RB mapping info ->
DL HS-DSCH MAC-d flow id
Added/reconfigured DL TrCH information ->
RRC: RADIO BEARER SETUP COMPLETE
HS-DSCH
Fig. 4.4 Message sequence chart for RAB setup (DCH to HS-DSCH)
57
4.1.1.10 RAB Setup Procedure from FACH to HS-DSCH
The RAB setup from FACH to HS-DSCH is triggered upon reception of a RAB assign-
ment request for a PS interactive or background RAB with the following preconditions:
1. The radio bearer combination currently contains only DCCH.
2. The UE supports HSDPA.
3. The UE is in Cell_FACH state.
If conditions 1 and 2 are not true, the procedures to establish the RAB on DCH or FACH
are initiated.
The SRNC checks the setting of the “Channel for Interactive or Background Class
RABs” parameter upon RAB setup if the UE is in Cell_FACH state:
• “Cell_FACH”
The SRNC proceeds with PS RAB establishment in Cell_FACH state.
• “Cell_DCH”
Cell selection is applied as described in "HSDPA Mobility Handling" on page 73. This
selects an HSDPA-enabled cell if available. PS RAB establishment on HS-DSCH is
initiated as described below if an HSDPA-enabled cell can be found on any frequen-
cy. Otherwise, the PS RAB is established in Cell_DCH state.
If an HSDPA-enabled cell is found, the SRNC assigns the HS-DSCH RL ID as the RL
ID of the target cell. The radio bearer translation algorithm is called, see "Impacts on the
Radio Bearer Translation" on page 47. This produces the MAC-d flow information and
the priority queue information for the HS-DSCH configuration.
The SRNC based power offset and measurement related parameters are generated,
see "Power Control and Measurement Feedback Parameters" on page 53. Then the
SRNC initiates the RL setup procedure. This is only done locally, since channel-type
switching via the Iur interface is not possible. There is only one Node B in the active set
and this is connected via the Iub interface.
The UL part of the PS BE RAB is established on DCH. The Node B is therefore
configured with UL DCH information and UL physical channel information. The “DCH
Specific Info” IE contains a mandatory UL and DL transport format set. When HS-DSCH
is used on the DL, the DL transport format set of the DCH associated with the PS BE
RAB is configured to 0 kbit/s using a transport format set with one transport format. The
number of transport blocks contained is set to “zero”.
The CRNC initiates the NBAP RL setup procedure. The NBAP: RL SETUP REQUEST
message contains the following information:
• UL/DL DPCH info
• UL/DL DCH info for the DCCH
• UL DCH info for the PS DTCH
• MAC-d flow/priority queue configuration
• Power offset and measurement feedback information
• H-RNTI
• HS-PDSCH RL ID
The Node B assigns the codes upon reception of the HS-DSCH information. Further-
more, the Node B configures the MAC-hs entity, the HARQ processes, and the
scheduler with the information received.
58
The NBAP: RL SETUP RESPONSE message contains the following information:
• TNL address info for the DCH: DCCH (for ALCAP)
• TNL address info for DCH: UL PS DTCH (for ALCAP)
• TNL address info for the MAC-d flow (for ALCAP)
• Initial capacity information
• HS-SCCH Code information
• HARQ memory partitioning information
The CRNC sends the information received to the colocated SRNC upon reception of the
NBAP RL SETUP RESPONSE message. Then the SRNC initiates the ALCAP transport
bearer establishment procedures for the DCH: UL PS DTCH and for the DCH: DCCH.
For the DL direction of the DCH carrying DTCH, the link characteristics for CAC are set
to the DCH rate used, i.e. 0 kbit/s, only if the “Transport Bearer Modification Feature”
flag is set to “ON”. Otherwise they are configured according to the maximum rate that
this DCH may use.
The SRNC initiates the RRC radio bearer setup procedure upon successful completion
of the transport bearer establishment procedures. The UE is configured with the
following information:
• Within the “RB mapping info” IE:
– Multiplexing options, see "RAB Multiplexing Options" on page 46
– MAC-hs reset indicator set to “true”
• Within the “Downlink information for each radio link” IE corresponding to selected
HSDPA serving cell:
– Serving HS-DSCH radio link indicator (for the serving HSDPA cell in the active
set)
The procedure finishes upon reception of an RRC: RADIO BEARER SETUP
COMPLETE message.
• NBAP: RL setup failure with cause not equal to “not enough user plane processing
resources”
core network indicating that the establishment of the RAB failed. Furthermore, any
resources established for the RAB are released.
The following failures result in a retry on DCH:
• Admission control failure including NBAP: RL setup failure with cause “not enough
user plane processing resources”
Fig. 4.5 shows the message sequence chart for RAB setup (FACH to HS-DSCH).
59
UE Node B SRNC
Decision to establish RAB on HS-DSCH

No RLs exist currently
Cell Selection:
see “HSDPA Mobility Handling”
NBAP: RL SETUP REQUEST DCH to add (for SRB)

HS-DSCH to add (DL DTCH)
HS-DSCH RNTI
HS-PDSCH RL ID
NBAP: RL SETUP RESPONSE

- HS-SCCH Code Information
ALCAP Iub Transport Setup (HS-DSCH)
ALCAP Iub Transport Setup (UL DTCH)
ALCAP Iub Transport Setup (SRB)
New H-RNTI
RRC: RADIO BEARER SETUP Downlink HS-PDSCH Iinformation
RB mapping info ->
DL HS-DSCH MAC-d flow id
RRC: RADIO BEARER SETUP COMPLETE
HS-DSCH
Fig. 4.5 Message sequence chart for RAB setup (FACH to HS-DSCH)
60
4.1.1.11 Channel-Type Switching from FACH to HS-DSCH
The procedure is initiated by PS RAB buffer overflow on UL or DL, see "Traffic Monitor-
ing and Channel-Type Switching" on page 53. With channel-type switching from FACH
to HS-DSCH, an HSDPA-enabled cell is selected, see "HSDPA Mobility Handling" on
page 73. The UE is switched to HS-DSCH as described below if an HSDPA-enabled cell
can be found on any frequency. Otherwise, the UE is switched to Cell_DCH state.
The procedure for channel-type switching from FACH to HS-DSCH is similar to the
procedure for RAB establishment from FACH to HS-DSCH, see "Channel-Type Switch-
ing from FACH to HS-DSCH" on page 61. The RRC procedure, however, is the trans-
port channel reconfiguration procedure instead of the radio bearer setup procedure.
The TRANSPORT CHANNEL RECONFIGURATION message contains the following
information:
• Within the “Downlink Information for Each Radio Link” IE corresponding to selected
HSDPA serving cell:
– Serving HS-DSCH radio link indicator (for the serving HSDPA cell in the active
set)
The following failures result in the failing of the channel-type switching procedure:
• AC failure - NBAP: RL setup failure
• RRC: transport channel reconfiguration failure
In the event of these failures, the connection reverts to Cell_FACH state and any
resources already assigned are released.
Fig. 4.6 shows the message sequence chart for channel-type switching from FACH to
HS-DSCH.
61
UE Node B RNC
Decision to switch PS RAB

from FACH to HS-DSCH
Cell Selection:
see “HSDPA Mobility Handling”
NBAP: RL SETUP REQUEST DCH to add (for SRB)

HS-DSCH to add (DL DTCH)
HS-DSCH RNTI
HS-PDSCH RL ID
NBAP: RL SETUP RESPONSE

- HS-SCCH Code Information
ALCAP Iub Transport Setup (HS-DSCH)
ALCAP Iub Transport Setup (UL DTCH)
ALCAP Iub Transport Setup (SRB)
RRC: TRANSPORT CHANNEL RECONFIGURATION New H-RNTI

Downlink HS-PDSCH Iinformation
RRC: TRANSPORT CHANNEL RECONFIGURATION COMPLETE HS-DSCH
Fig. 4.6 Message sequence chart for channel-type switching from FACH to HS-DSCH
4.1.1.12 Channel-Type Switching from HS-DSCH to FACH

The procedure is initiated if inactivity is detected on both UL and DL, see "Traffic Moni-
toring and Channel-Type Switching" on page 53.
This procedure is very similar to the existing procedure for channel-type switching from
Cell_DCH to Cell_FACH state. The differences are:
• Use of the RRC procedure radio bearer reconfiguration instead of physical channel
reconfiguration to send the “Deleted DL TrCH information” IE which deletes the
MAC-d flow.
• Deallocation of the H-RNTI
• Release of the Iub transport block for HS-DSCH (MAC-d flow) in addition to the
DTCH and DCCH transport blocks
62
Fig. 4.7 shows the message sequence chart for channel-type switching from HS-DSCH
to FACH.
UE Node B1 Node B2 RNC
Trigger to switch a RAB

from HS-DSCH to FACH
RRC: RADIO BEARER RECONFIGURATION RRC State Indicator = FACH

DL Deleted TrCH information
(MAC-d flow)
Cell Update (cell reselection)
RRC: RADIO BEARER RECONFIGURATION COMPLETE
NBAP: RL DELETION REQUEST
NBAP: RL DELETION RESPONSE
NBAP: RL DELETION REQUEST
NBAP: RL DELETION RESPONSE
Deallocate HS-DSCH RNTI
ALCAP Iub Transport Bearer Release (HS-DSCH)
ALCAP Iub Transport Bearer Release (DCCH)
ALCAP Iub Transport Bearer Release (UL DTCH)
ALCAP Iub Transport Bearer Release (DCCH)
ALCAP Iub Transport Bearer Release (UL DTCH)
Fig. 4.7 Message sequence chart for channel-type switching from HS-DSCH to FACH
63
4.1.1.13 RAB Setup Procedure from HS-DSCH to DCH
RAB setup from HS-DSCH to DCH is triggered upon reception of a RAB assignment
request to establish a RAB while the current RAB combination uses the HS-DSCH and
the target RAB combination will not use HS-DSCH, see "Impacts on the Radio Bearer
Translation" on page 47.
The radio bearers mapped onto HS-DSCH on the DL must be switched to DCH. The
radio bearer translation mechanism is called with the “HS-DSCH Required” indicator set
to “not required”. The radio bearer translation algorithm outputs a DCH only
configuration, assigning the initial rate for the PS BE RAB.
If the new RAB also uses AM RLC, the SRNC regenerates the RLC window sizes based
on the RB type, see "Impacts on the Radio Bearer Translation" on page 47. The SRNC
then initiates the RB reconfiguration procedure, see "Radio Bearer Reconfiguration Pro-
cedure" on page 69.
The SRNC initiates the synchronized RL reconfiguration preparation procedure to:
• Delete the HS-DSCH at the Node Bs.
• Reconfigure simultaneously the DCH which has a current DL rate of 0 kbit/s. The UL
DCH is reconfigured if the current rate differs from the target rate.
• Add the DCH for the RAB that is to be established.
Afterward, AAL2 establishment procedures are initiated for the new RAB and the RL
reconfiguration commit procedure is initiated.
The DL link characteristics for CAC are configured to the used DCH rate if the “Transport
Bearer Modification Feature” flag is set to “on”. Otherwise, they remain configured to the
maximum rate that the DCH may use.
The SRNC then sends the RB SETUP message to specify the new DCH configuration.
The UE stops using the HS-DSCH configuration and starts using the DCH configuration.
Furthermore, the RB SETUP message contains the “Deleted DL TrCH information” IE
to delete the MAC-d flow in order that the UE uses the DCH RB multiplexing option.
The CRNC releases the H-RNTI allocated to the UE after the completion of the RRC
procedure. Upon reception of the RB SETUP COMPLETE message, the SRNC
releases the Iub transport bearer (TB) that was used for the MAC-d flow.
The SRNC then activates the DL Tx power dedicated measurements to control bit rate
adaptation which was not active while the DL was using HS-DSCH.
• NBAP: RL reconfiguration preparation failure with NBAP cause not equal to “not
enough user plane processing resources”
core network indicating that the establishment of the RAB failed. Any resources
established for the RAB are released. If an RRC RADIO BEARER SETUP FAILURE
message is received, an RRC connection reestablishment procedure is also required
since the Node B is already committed to the new configuration.
The following failures result in a retry at the minimum rate of DCH:
• Admission control failure and NBAP RL reconfiguration preparation failure with the
NBAP cause “not enough user plane processing resources”
For failure handling of radio bearer reconfiguration, see "Radio Bearer Reconfiguration
Procedure" on page 69.
64
Fig. 4.8 shows the message sequence chart for RAB setup (HS-DSCH to DCH).
UE Node 1 Node B2 RNC
Trigger to set up a RAB which results in a

RAB combination not allowed on HS-DSCH
-> reconfiguration to DCH only
OPT 1 Performed if new

RAB uses RLC AM
Radio Bearer Reconfiguration
NBAP: RL RECONFIGURATION PREPARE DCH to add (UL/DL DTCH for new RAB)
DCH to modify (UL/DL DTCH for PS RAB)
HS-DSCH to delete (DL DTCH)

DCH to add (UL/DL DTCH for new RAB)
DCH to modify (UL/DL DTCH for PS RAB)
ALCAP Iub Transport Bearer Setup (new DCH)
ALCAP Iub Transport Bearer Setup (new DCH)
RRC State Indicator = DCH

RRC: RADIO BEARER SETUP Added/reconfigured DL TrCH information
Added/reconfigured UL TrCH information
- if no mac multiplexing
- add UL/DL DCH for new DTCH
RRC: RADIO BEARER SETUP COMPLETE - reconfigure UL/DL DCH for PS DTCH
Deallocate H-RNTI
Dedicated Measurement Activation for DL Tx power events A/F
Fig. 4.8 Message sequence chart for RAB setup (HS-DSCH to DCH)
65
4.1.1.14 RAB Release Procedure from HS-DSCH to DCH
RAB release from HS-DSCH to DCH is triggered upon reception of a request to release
the RAB which is using HS-DSCH such that the UE remains in RRC connected mode.
These triggers are:
• RAB assignment request to release the PS RAB
• Iu release command from the PS domain when the Iu signaling connection exists for
the CS domain
This procedure is very similar to the existing RAB release procedure for an SRB + PS
RAB to an SRB with the following differences:
• The NBAP: RL RECONFIGURATION PREPARE message additionally contains the
“HS-DSCH to delete” IE.
• The RRC: RADIO BEARER RELEASE message additionally contains the “Deleted
DL TrCH Information” IE for the HS-DSCH resources to be released.
• The CRNC releases the H-RNTI allocated to the UE after completion of the RRC
procedure.
• The SRNC has to release the Iub TB for the HS-DSCH, too.
Fig. 4.9 shows the message sequence chart for RAB release (HS-DSCH to DCH).
66
Trigger to release a RAB which is on HS-DSCH

Revert to DCH

DCH to delete (UL DTCH)
HS-DSCH to delete (DL DTCH)

DCH to delete (UL DTCH)
RRC: RADIO BEARER RELEASE

RRC State Indicator = DCH
Deleted DL TrCH Information (DCH)
Deleted DL TrCH Information (HS-DSCH)
RRC: RADIO BEARER RELEASE COMPLETE Deleted UL TrCH Information
Deallocate H-RNTI
ALCAP Iub Transport Bearer Release (UL DCH)
ALCAP Iub Transport Bearer Release (UL DCH)
Fig. 4.9 Message sequence chart for RAB release (HS-DSCH to DCH)
67
4.1.1.15 RAB Release Procedure from Multicall
RAB release from multicall is triggered if the UE has more than one RAB and receives
a trigger to release one of them. This initiation is unchanged.
In addition to the existing actions, the RLC window sizes are regenerated according to
the values derived from the UE memory availability, see "Impacts on the Radio Bearer
Translation" on page 47.
Furthermore, a radio bearer is reconfigured if the following conditions are satisfied:
• The UE is HSDPA-capable.
• The UE has two RABs which use AM RLC.
• The procedure releases one of the two RABs using AM RLC.
The radio bearer reconfiguration procedure is performed upon completion of the RAB
release procedure, that is, after sending the RAB ASSIGNMENT RESPONSE message
to the core network.
If the UE fails the radio bearer reconfiguration and the cause is “configuration
unsupported”, the RNC reverts the local RLC parameters to what they were before the
radio bearer reconfiguration and resumes the governing RAB setup procedure. The
RAB setup procedure may fail due to limited UE memory. In the event of other failure
causes, the RNC initiates the Iu release procedure.
Fig. 4.10 shows the message sequence chart for RAB release from multicall.
Trigger to release a RAB when

two RABs exist
Perform existing RB Release procedure
OPT 1 For HSDPA-capable UEs when

PS BE RAB remains and RAB
to be released was AM RLC
Radio Bearer Reconfiguration
Fig. 4.10 Message sequence chart for RAB release from multicall
68
4.1.1.16 RRC Connection Reestablishment Procedure
RRC connection reestablishment is triggered upon reception of an NBAP: RL FAILURE
INDICATION message for the last radio link set in the UE’s active set. Afterward, the
RNC starts the timer T314RNC and waits for an RRC: CELL UPDATE message from the
UE with cause “RL Failure” or “RLC Unrecoverable error”. This is the same trigger as for
the procedure to reestablish an RRC connection on DCH.
If the RRC: CELL UPDATE message is received before the NBAP: RL FAILURE
INDICATION message, the RNC deletes all resources in the first step except the Iu
resources and the internal UE context. Afterward, the RNC starts the timer T314RNC and
waits for the next retransmitted CELL UPDATE message. This second CELL UPDATE
message triggers the reestablishment procedure.
RRC connection reestablishment may be forced by the RNC, for example in the event
of an RLC-unrecoverable error on DCCH detected by UTRAN. This includes the release
of all UTRAN resources except the Iu resources and the internal UE context. The
disappearance of the DL radio links forces the UE to send a CELL UPDATE message.
These triggers are valid for HSDPA, too.
If the UE is HSDPA-capable and the RAB combination allows HS-DSCH usage, the
SRNC performs reestablishment to FACH instead of reestablishment to DCH or
HS-DSCH. UEs, however, are reestablished on DCH if they are HSDPA-non-capable or
HSDPA-capable with a RAB combination which is not allowed to use HS-DSCH. These
UEs may be reestablished in an HSDPA cell if such a cell is selected by the UE after it
detects a radio link failure.
If the UE uses HS-DSCH, the CELL UPDATE CONFIRM message includes additionally
the “Deleted DL TrCH information” IE in order to delete the MAC-d flow currently
configured in the UE. The UE responses with a TRANSPORT CHANNEL
RECONFIGURATION COMPLETE message.
4.1.1.17 Radio Bearer Reconfiguration Procedure

Radio bearer reconfiguration is initiated if a second AM RAB is set up or released. It is
used to modify the RLC parameters such that the UE’s used RLC buffer space is within
its capabilities. This procedure can only be called during a governing RAB setup/release
procedure, see "RAB Setup Procedure from DCH to HS-DSCH" on page 54 and "RAB
Release Procedure from Multicall" on page 68.
At first, the local RLC parameters are reconfigured to the new RLC parameters. Then
the RB reconfiguration procedure is initiated with the following IE setting:
• The “RRC State Indicator” is set to the current state of the UE, “Cell_DCH” or
“Cell_FACH”
• The “RB Information” to reconfigure is included, containing the new RLC
configuration for the PS BE radio bearer.
• If the UE is currently using HS-DSCH, the DL HS-PDSCH info is also included so
that the UE continues to receive DL HS-PDSCH.
• The activation time is omitted, implying immediate application of the new
configuration.
If an HSDPA-capable UE receives a RAB assignment request to set up a second RAB
that uses AM RLC, the existing AM RLC RAB is reconfigured to use the RLC window
sizes derived from the RB type. In the event of a RAB assignment to release one of two
RABs that use AM RLC, the remaining RAB is reconfigured to use the RLC window
69
sizes derived from UE available memory if the remaining RAB is eligible for HS-DSCH
usage.
If the UE fails the radio bearer reconfiguration and the cause is “configuration
unsupported”, the RNC reverts to the local RLC parameters used before the radio
bearer reconfiguration and resumes the governing RAB setup procedure. This RAB set-
up procedure may fail due to limited UE memory. In the event of other failure causes,
the RNC initiates the Iu release procedure.
Fig. 4.11 shows the message sequence chart for radio bearer reconfiguration.
UE SRNC
Change local RLC parameters
RRC: RADIO BEARER RECONFIGURATION

RB Information to reconfigure (DL RLC info)
Downlink PDSCH Information (unchanged)
Activation time = “now”
RRC: RADIO BEARER RECONFIGURATION COMPLETE
Fig. 4.11 Message sequence chart for radio bearer reconfiguration
4.1.1.18 SRNS Relocation Procedure

The RNC includes the appropriate RLC configuration in the CELL UPDATE
CONFIRM/RB RECONFIGURATION message if the UE is ascertained to be HSDPA
capable from the relocation container. That is, any AM BE RAB has the “RB Mapping
Info” IE as described in section "RAB Multiplexing Options" on page 46 and the RLC
window size according to "Impacts on the Radio Bearer Translation" on page 47. The
RLC window size is derived from UE available memory if the PS BE RAB is the only AM
RLC RAB. If more than one AM RLC RAB exist, the smaller RLC window size is derived
from the RB type.
4.1.1.19 RAB Setup Procedure from CCH to DCH and DCH to DCH
This procedure is changed in a way that radio bearer reconfiguration is performed be-
fore RAB setup in the event of:
• The UE is HSDPA capable.
• The existing RAB combination includes a PS BE RAB.
• The existing RAB combination includes only one AM RLC RAB.
• The RAB to be setup is AM RLC.
The procedure is applicable for a HSDPA-capable UE that has a PS BE RAB (in
Cell_FACH or Cell_DCH state) and is therefore configured with the RLC window sizes
derived from UE available memory if the RNC receives an RAB assignment request for
a PS streaming RAB (which also uses AM RLC). In this case it is necessary to change
the RLC window sizes to the values derived from the RB type. For more information see
"Impacts on the Radio Bearer Translation" on page 47.
70
Fig. 4.12 shows the message sequence chart for RAB setup (CCH to DCH, DCH to
DCH).
GSM GSM SRNC
OPT 1 Performed in the event of:

- UE is HSDPA capable
- existing RAB combination
includes PS BE
Radio Bearer Reconfiguration - existing RAB combination
includes only one AM RLC RAB
1 - RAB to be set up is AM RLC
Existing RAB establishment procedure
Fig. 4.12 Message sequence chart for RAB setup (CCH to DCH, DCH to DCH)
4.1.1.20 Pre-emption and Interaction with Admission Control

Admission control is requested for HS-DSCH resources in the following procedures:
• RAB establishment (DCH to DCH/HS-DSCH)
The RAB to be established requests a DL HS-DSCH and a UL DCH. In this case,
the UL/DL DCHs already exist for the DCCH. If, however, the rate is 13.6 kbit/s
(standalone DCCH rate), it will be reduced to 3.4 kbit/s and this load reduction is
accounted for by the admission control. The UL DCH for the new RAB is established
in all cells of the active set if the active set of the UE has more than one cell but the
DL HS-DSCH is established only in the selected HS-DSCH serving cell.
• RAB establishment (FACH to DCH/HS-DSCH)
The RAB to be established requests for a DL HS-DSCH and a UL DCH and for an
UL/DL DCH supporting DCCH.
• Channel-type switching (FACH to DCH/HS-DSCH)
The RAB to be established requests a DL HS-DSCH and a UL DCH and for an
UL/DL DCH supporting DCCH.
• Change of the serving HS-DSCH cell
The RAB requests only the DL HS-DSCH because the UL DCH and the UL/DL DCH
supporting DCCH are already established. The UL DCH, however, may be switched
from a non-HSDPA-capable CHC to an HSDPA-capable CHC, in which case Node B
admission control (user plane resource availability) may fail the request.
• Active set update (SHO addition) when using HS-DSCH
The RAB requests a UL DCH and a UL/DL DCH supporting the DCCH. No
HS-DSCH resources are requested in this scenario.
Radio-link pre-emption is not supported for the HS-DSCH/DCH combinations.
The “Pre-emption Capability” IE for the MAC-d flow is set to “shall not trigger pre-
emption” by the SRNC. The “Pre-emption Capability” IE is part of the allocation/retention
priority. The core network includes the allocation/retention priority for each RAB to be
set up or modified by the UTRAN in the RANAP RAB ASSIGNMENT REQUEST or
RELOCATION REQUEST messages.
71
If the Pre-emption feature is switched on and the “Allocation/Retention Priority” IE was
received in the RAB assignment request, the “Pre-emption Capability” IE of the DCH for
the relevant DTCH is set to “shall not trigger pre-emption” when the HS-DSCH is also
requested.
Admission control failure in the above HS-DSCH establishment procedures can occur
for the following reasons:
1. Failure to allocate the Node B resources
2. Failure to allocate the DL DCH resources
3. Failure to allocate the UL DCH and/or UL HS-DPCCH resources
Failure due to reason 1 can occur because of DCH or HS-DSCH channel card resource
shortage in the Node B. The RNC identifies admission control failure when it receives
an NBAP message with the NBAP failure cause set to “not enough user plane process-
ing resources”.
In the event of RAB establishment, a retry on DCH is attempted. Even if the failure
occurred due to DCH resource shortage with the reason 2) or 3), the retry on DCH
should use the received “Allocation/Retention Priority” IE which could result in success-
ful admission with pre-emption of another user. The retry on DCH is attempted at the
“minimum” rate, which is when the received allocation/retention priority parameters are
applied. This avoids the possibility of a third retry being required.
In the event of channel-type switching from FACH to DCH/HS-DSCH, the UE is kept in
Cell_FACH state regardless of the admission control failure type.
In the mobility scenarios, the reasons 1), 2) and 3) apply for active set update (SHO
addition). Furthermore the reasons 1) and 3) apply for a serving cell change. Failures
are handled as follows:
• The ongoing procedure is a soft handover addition:
– Upon an admission control failure due to reason 1) or 3) when the UL rate is
currently 384 kbit/s, the UL bit rate is adapted to 64 kbit/s and a soft-handover re-
try is performed. If this fails, reestablishment on FACH is performed.
– Upon admission control failure due to reason 1) or 3) when the UL rate is currently
64 kbit/s and due to reason 2), a channel-type switching from DCH/HS-DSCH to
the DCH minimum rate is performed (same procedure as outward mobility). In the
event of active set update (soft handover addition) failure, this is followed by a soft
handover retry. If this fails, reestablishment on FACH is performed.
• The ongoing procedure is a serving cell change:
A channel-type switching from DCH/HS-DSCH to DCH minimum rate is performed
(same procedure as outward mobility) followed by a soft handover retry. If this fails,
reestablishment on FACH is performed.
4.1.1.21 Allocation of H-RNTI

H-RNTI is the unique identifier of an HSDPA user within a cell. It is used to scramble the
control data on the HS-SCCH.
72
4.1.2 HSDPA Mobility Handling
The quality of the serving HS-DSCH cell always varies and the SRNC needs to move
the serving HS-DSCH cell to another cell if the quality is degraded or the serving
HS-DSCH cell is deleted. With the HSDPA Mobility Handling feature, it is possible to
establish the HS-DSCH on the cell in the active set where the quality is best. The system
throughput will thus be improved. Furthermore, this feature enables the deployment of
HSDPA in parts of the UMTS network, for example in hot spot areas.
The fundamental strategy is to establish the HS-DSCH on the best-quality cell within an
active set, wherever possible. If the best cell within the active set is a non-HSDPA-
capable cell and HS-DSCH is currently used, channel-type switching from HS-DSCH to
DCH is performed. For more information on RAB eligibility for HSDPA see "HSDPA RAB
Handling" on page 43.
An “HSDPA Cell” is defined in this document as a cell that supports HSDPA and has the
“Resource Operational State” set to “enabled”. A cell is not taken into account as an
HSDPA cell if it supports HSDPA but its operational state is “disabled”. The SRNC does
not try to establish HS-DSCH on such a cell. For more information see "HSDPA Code
and Power Allocation and Redimensioning" on page 108. HS-DSCH is not supported
via Iur interface. Therefore, all cells under the control of another RNC are considered to
be non-HSDPA cells.
The prerequisites for the handling of HS-DSCH are:
1. HSDPA-related parameters which characterize the HS-DSCH MAC-d flow are un-
changed during the call. For more information on these parameters, for example the
“Scheduling Priority Indicator” IE, see "HSDPA RAB Handling" on page 43.
2. HSDPA-related parameters are only sent to the nodes which are relevant for
establishing or releasing HS-DSCH.
3. The MAC-hs in the Node B is reset whenever the serving HS-DSCH cell changes.
4. The transport bearer of the Iub interface is reused if the serving HS-DSCH cell
changes under the control of the same Node B and the current serving HS-DSCH
cell is not deleted by the active set update procedure.
If the current serving HS-DSCH cell is deleted by the active set update procedure,
the transport bearer corresponding to this serving HS-DSCH cell is also deleted
during the active set update procedure. The active set update procedure is
performed to prepare the change of the serving HS-DSCH cell if the change of the
serving HS-DSCH is triggered by the reception of a measurement report with event
1A, 1B, 1C, or 1A’.
4.1.2.1 Scenarios for Mobility Handling of HS-DSCH

The following scenarios are supported for mobility handling of HS-DSCH.
HS-DSCH establishment
The scenarios supported upon HS-DSCH establishment are:
• Intrafrequency, intra-SRNC, intra-Node B handover
• Interfrequency, intra-SRNC, intra-Node B handover
The SRNC tries to establish HS-DSCH if the active set of the UE includes HSDPA-
capable cells (Cell_DCH state) or the UE has an RRC connection to a cell where
HSDPA is supported (Cell_FACH state). Fig. 4.13 shows the related intrafrequency,
intra-SRNC, intra-Node B handover scenario.
73
UE
HSDPA cell
Frequency#1’
UE Serving HS-DSCH cell
Frequency#1’
Node B
Fig. 4.13 HS-DSCH establishment if the UE is in Cell_DCH or Cell_FACH state
The SRNC tries to move the UE to an HSDPA-supporting cell if the UE has an RRC
connection to a cell which does not support HSDPA (Cell_FACH state) and channel-
type switching from FACH to HS-DSCH is triggered due to traffic monitoring. This is not
performed if a RAB is established. If such an HSDPA-supporting cell is available, the
SRNC establishs HS-DSCH on that cell. Fig. 4.14 shows the related interfrequency,
intra-SRNC, intra-Node B handover scenario.
UE
Non HSDPA cell
Frequency#1’
Frequency#2’
HSDPA cell
Frequency#1’
Frequency#2’
Node B
Fig. 4.14 HS-DSCH establishment if the UE is in Cell_FACH state
74
Inward mobility (DCH -> HS-DSCH)
The scenario supported upon inward mobility (DCH -> HS-DSCH) is:
• Intrafrequency, intra-RNC, inter-Node B handover
Channel-type switching from DCH to HS-DSCH is performed if the UE enters an
HSDPA-capable cell and the condition described in "Inward Mobility" on page 81 is met.
Fig. 4.15 shows the related intrafrequency, intra-RNC, inter-Node B handover
scenario.
UE
Non HSDPA cell HSDPA cell
Frequency#1’
Serving HS-DSCH cell

Active set
UE
Frequency#1’
Active set
Fig. 4.15 Inward mobility
Change of the serving HS-DSCH cell

The scenarios supported upon HS-DSCH cell change are:
• Intrafrequency, intra-RNC, intra-Node B handover
• Intrafrequency, intra-SRNC, inter-Node B handover
A change of the serving HS-DSCH cell is performed if the UE enters a new HSDPA-
capable cell because of an active-set change and the condition described in section
"Change of the Serving HS-DSCH Cell" on page 84 is met. Furthermore, the serving
HS-DSCH cell is changed if the quality of the serving HS-DSCH cell becomes worse
than other HSDPA-capable cells within the active set.
Fig. 4.16 and Fig. 4.17 show the intrafrequency, intra-RNC, intra-Node B handover
and intrafrequency, intra-RNC, inter-Node B handover scenarios for a change of the
serving HS-DSCH cell due to a change of the active set. A change of the serving
HS-DSCH cell within the active set is almost the same and not shown.
75
HSDPA cell
Frequency#1’
Active set
UE
Frequency#1’
Active set
Node B
Fig. 4.16 Change of the serving HS-DSCH cell within a Node B

HSDPA cell
Frequency#1’
Active set
UE
Frequency#1’
Active set
Node B1 Node B2
Fig. 4.17 Change of the serving HS-DSCH cell between two Node Bs
76
Outward mobility (HS-DSCH -> DCH)
The scenarios supported upon outward mobility (HS-DSCH -> DCH) are:
• Intrafrequency, intra-SRNC, inter-Node B handover
• Intrafrequency, inter-RNC handover
• Intrafrequency, inter-RNC (SRNC) relocation
• Interfrequency, intra-SRNC, inter-Node B handover
Channel-type switching from HS-DSCH to DCH is performed if the UE leaves an
HSDPA-capable cell or the quality of a non-HSDPA-capable cell meets the condition
described in section "Outward Mobility" on page 93. Fig. 4.18 shows the related intra-
frequency, intra-SRNC, inter Node B handover scenario.

HSDPA cell Non HSDPA cell
Frequency#1’
Active set
UE
Frequency#1’
Active set
Node B1 Node B2
Fig. 4.18 Outward mobility between two Node Bs
Channel-type switching from HS-DSCH to DCH is performed regardless of the HSDPA

capability of a cell if the UE enters a cell that is controlled by the DRNC and the quality
of the cell meets the condition described in section "Outward Mobility" on page 93
because HS-DSCH via the Iur interface is not supported. Fig. 4.19 shows the related
intrafrequency, inter-RNC handover scenario. If SRNS relocation has been
completed, channel-type switching from DCH to HS-DSCH can be performed as
described for inward mobility.
77
HSDPA cell
Frequency#1’
Active set
UE
Frequency#1’
Active set
SRNC DRNC
Fig. 4.19 Outward mobility between two RNCs
If Intrafrequency SRNS relocation without Iur interface is triggered, channel-type

switching from HS-DSCH to DCH is performed before the SRNS relocation procedure
is initiated, in other words before the SRNC sends the RANAP: RELOCATION
REQUIRED message. Fig. 4.20 shows the related intrafrequency, inter-RNC (SRNC)
relocation scenario. If SRNS relocation has been completed, channel-type switching
from DCH to HS-DSCH can be performed as described for inward mobility.

HSDPA cell
Frequency#1’
Active set
UE
Frequency#1’
Active set
SRNC
Fig. 4.20 Outward mobility between two RNCs (SRNC relocation)
78
If the SRNC receives a measurement report of event 2D/2D’/2D’’, channel-type
switching from HS-DSCH to DCH is performed and interfrequency/intersystem
handover might be performed.
The SRNC receives a measurement report of event 2D/2D’/2D’’ in the event of:
• The end of the coverage of an HSDPA-capable cell
• A fading gap
• High adjacent-channel interference
Fig. 4.21 shows the related interfrequency, intra-SRNC, inter-Node B handover
scenario.
Serving HS-DSCH cell

UE
Non HSDPA cell
Frequency#1’
Frequency#2’
HSDPA cell
UE UE
Frequency#1’
Frequency#2’
Node B1 Node B2 or GSM area
Fig. 4.21 Outward mobility between different frequencies/systems
4.1.2.2 MAC-hs Reset and Loss of Data

The variable parameters used in the MAC-hs, for example TSN or T1, are required to
be synchronized between the Node B and the UE for the HARQ process and the
reordering process at the UE. The SRNC informs the UE that the MAC-hs in the Node B
is reset and the variable parameters stored in the UE will be initialized. In UMR4.0-HS,
the MAC-hs in the Node B is always reset when the serving HS-DSCH cell is changed.
Therefore, it is preferred to set the “MAC-hs Reset Indicator” IE always to “true”. The
“MAC-hs Reset Indicator” IE is included in the TRANSPORT CHANNEL RECONFIGU-
RATION message but it is not included in NBAP messages from the Node B to the
CRNC.
If the MAC-hs in the Node B is reset, MAC-d PDUs already sent to the Node B and
stored in the MAC-hs are discarded. The SRNC stops transmission of HS-DSCH data
frames during a change of the serving HS-DSCH cell to minimize the loss of data.
If the UE is informed by the SRNC that the MAC-hs is reset, the UE sends the STATUS
PDU to the SRNC. The SRNC can now retransmit the SDUs lost due to the MAC-hs
reset.
79
4.1.2.3 Measurement Configuration
This section provides an overview of the differences from the measurement
configuration due to the introduction of HSDPA.
With UMR5.0, event 1D is introduced to detect the best cell within the active set, refer
to section "Change of the Serving HS-DSCH Cell" on page 84. Event 1D is a
measurement dedicated to HSDPA and independent of the measurements currently
defined, that is the measurement ID is newly assigned to event 1D.
Event 1D is configured in the event of:
• Setup: Upon the successful establishment of HS-DSCH
• Release: Upon release of HS-DSCH.
The same “Intrafrequency Cell Info List” IE is used for event 1D as for the intrafrequency
measurement events 1A, 1B and 1C.
4.1.2.4 HS-DSCH Establishment

The trigger conditions for HS-DSCH establishment are:
1. Cell_DCH state (no RAB is active)
A PS RAB is established and the active set includes an HSDPA-capable cell.
2. Cell_FACH state
A PS RAB is established (no RAB is active) or channel-type switching is performed
from FACH to HS-DSCH and an HSDPA-capable cell is available.
PS RAB establishment
In UMR5.0, HS-DSCH is not established in Cell_DCH state if compressed mode is ac-
tive in the UE since simultaneous activation of compressed mode and HS-DSCH is not
supported. Therefore, compressed mode is deactivated before HS-DSCH is estab-
lished. If the SRNC receives event 2D/2D’/2D’’, channel-type switching from HS-DSCH
to DCH is performed and compressed mode is activated again.
Upon PS RAB establishment, the selection of the serving HS-DSCH cell depends on the
RRC state of the UE:
• Idle
HSDPA-capable UEs are moved to the HSDPA-capable cell when establishing an
RRC connection as follows:
– The “HCS_PRIO” IE of the HSDPA-capable cell should have a value lower than
the value of the non-HSDPA-capable cell so that all UEs send RRC CONNEC-
TION REQUEST messages from the non-HSDPA-capable cell.
– The “Frequency info” IE in the RRC CONNECTION SETUP message is set to the
frequency of the cell where HSDPA is supported if all of the following conditions
are met: The HSDPA feature is enabled, the UE differentiation is set to “true”, and
the “Access Stratum Release Indicator” IE is set to “REL-5”. Furthermore, the
”Establishment Cause” IE is set to “originating interactive call”, “originating back-
ground call”, “terminating interactive call”, or “terminating background call”. The
“Protocol Error Indicator” IE is set to “false” or is not included in the RRC
CONNECTION REQUEST message.
This mechanism is not applicable if the “Resource Operational State” IE in the
“HS-DSCH Resource Information” IE is set to “disabled”.
If no cell is available due to load control, the RRC connection establishment
procedure might be rejected. For more information on the load control mechanism
see UE Differentiation.
80
• Cell_FACH
The SRNC establishes a PS RAB on HS-DSCH if no other RAB is active at this time,
the UE has an RRC connection to an HSDPA cell, and the UE supports HSDPA.
• Cell_DCH
The UE establishes the RRC connection as described for Idle mode. The SRNC
establishes HS-DSCH when a PS RAB is established, no other RAB is active at this
time, compressed mode is not active, and the UE supports HSDPA as follows.
– If the active set consists of one cell and this cell is an HSDPA cell, the SRNC
establishes HS-DSCH on that cell. Otherwise, the SRNC establishes DCH
instead of HS-DSCH.
– If the active set consists of multiple cells, the SRNC establishes HS-DSCH on the
cell which was added last. If this cell is a non-HSDPA cell or is controlled by the
DRNC, the SRNC establishes DCH instead of HS-DSCH.
Channel-type switching from FACH to HS-DSCH

Upon channel-type switching from FACH to HS-DSCH due to traffic monitoring, the
SRNC moves the UE to the HSDPA cell if the UE has an RRC connection to a non-
HSDPA-capable cell and the UE supports HSDPA. If the UE has an RRC connection on
the HSDPA cell, the SRNC tries to perform channel-type-switching from FACH to
HS-DSCH on that cell. This feature is applicable only when both the HSDPA feature and
the UE differentiation are set to “true”.
This mechanism is not applicable if the “Resource Operational State” IE in the
“HS-DSCH Resource Information” IE is set to “disabled”.
If channel-type switching from FACH to HS-DSCH fails, the UE remains in the cell where
the UE currently has the RRC connection. If the target HSDPA cell is overloaded,
channel-type-switching from FACH to DCH is performed to the original cell where the
UE currently has the RRC connection. Channel-type-switching from FACH to DCH may
fail if the original cell is overloaded, too.
The load control mechanism for this feature is described in UE Differentiation. For
information on the message sequence charts see "RAB Setup Procedure from DCH to
HS-DSCH" on page 54.
4.1.2.5 Inward Mobility

Inward mobility is triggered if the UE enters an area where HSDPA is supported and the
quality of the HSDPA cell is the best within the cells reported by measurement event 1A,
1B, 1C, or, if configured, 1A’. HS-DSCH is established only if the quality of the reported
HSDPA cell is the best and much better than the reported non-HSDPA cells in order to
avoid frequent channel-type switching between DCH and HS-DSCH. In addition,
channel-type switching from DCH to HS-DSCH is not performed if compressed mode is
active in the UE.
The SRNC selects the serving HS-DSCH cell based on the measurement report (1A,
1B, 1C, or if configured 1A’). The quality of each cell is derived from the “CPICH Ec/N0”
IE included in the “Cell Measured Results” IE. HS-DSCH is only established if the differ-
ence of the quality between the best HSDPA cell and the non-HSDPA cells is above a
predefined threshold in order to avoid frequent channel-type switching between DCH
and HS-DSCH. Furthermore, HS-DSCH is not established if compressed mode is active
in the UE.
81
The SRNC establishes HS-DSCH as follows:
1. The SRNC selects the new active set based on the “Event results” IE.
2. The SRNC checks whether or not the best cell is an HSDPA cell.
– If the best cell is a non-HSDPA cell or is under the control of the DRNC, the SRNC
performs an active set update.
– If the best cell is an HSDPA cell and is under the control of the SRNC, the differ-
ence in quality between the best HSDPA cell and the non-HSDPA cells is
checked. The SRNC performs an active set update if this difference is below the
predefined threshold. If the difference is above the predefined threshold, the
SRNC performs an active set update followed by channel-type switching from
DCH to HS-DSCH and setup of measurement 1D.
If the check of the measurement report results in an intrafrequency SRNS relocation
without Iur interface, SRNS relocation is performed instead of an active set update and
channel-type switching from DCH to HS-DSCH.
Fig. 4.22 shows how a new radio link is established via a new Node B and HS-DSCH
is established on that radio link. In this document, the red line indicates the transport
bearer for DCH and the blue line indicates the transport bearer for HS-DSCH.
SRNC SRNC
Node B1 Node B2 Node B1 Node B2
UE UE
Fig. 4.22 Inward mobility
The SRNC includes all HSDPA-related parameters in the RADIO LINK RECONFIGU-
RATION PREPARE and the TRANSPORT CHANNEL RECONFIGURATION messag-
es since this is the first establishment of HS-DSCH and the UE and the Node B do not
have these parameters.
Fig. 4.23 shows the message sequence chart for inward mobility. If the trigger for
establishing the HS-DSCH is a measurement report (1B or 1C), the deletion of the radio
link(s) in Node B1/Node B2 might be performed by the active set update procedure. If
the radio link(s) have already been established via Node B2, the RL addition procedure
is used to establish new radio link(s) via Node B2.
Since DL bit rate adaptation is not applicable when HS-DSCH is used, the CRNC
terminates the transmitted code power (radio link quality) measurement by sending a
DEDICATED MEASUREMENT TERMINATION REQUEST message to the related
Node Bs upon the successful configuration of measurement 1D. The rate for the UL
DTCH is changed to 64 kbit/s if the rate is other than 64 kbit/s and the transport bearer
is modified accordingly. For more information on the handling of the transport bearer for
DTCH see "HSDPA RAB Handling" on page 43.
82
UE Node B1 Node B2 SRNC
MEASUREMENT REPORT (Event 1A)
Decision to perform
CTS (DCH -> HS-DSCH)
RADIO LINK SETUP REQUEST

Active Set Update
RADIO LINK SETUP RESPONSE
ALCAP Iub Transport Bearer Setup (DCH)
ACTIVE SET UPDATE
ACTIVE SET UPDATE COMPLETE
DCH -> HS-DSCH (CTS) Allocate H-RNTI
RADIO LINK RECONFIGURATION PREPARE

(Modification of UL DTCH (if necessary), Deletion of DL DTCH)
(Modification of UL DTCH (if necessary),
Deletion of DL DTCH,
Establishment of HS-DSCH)
RADIO LINK RECONFIGURATION READY
ALCAP Iub Transport Bearer Reconfiguration

(Modification of UL DTCH (if necessary), Deletion of DL DTCH)
ALCAP Iub Transport Bearer Reconfiguration

(Modification of UL DTCH (if necessary),
Deletion of DL DTCH)
RADIO LINK RECONFIGURATION COMMIT
TRANSPORT CHANNEL RECONFIGURATION
UE can start “listening” to the HS-DSCH

at the specified activation time
TRANSPORT CHANNEL RECONFIGURATION COMPLETE
MEASUEMENT CONTROL (Event 1D) (Setup)
Fig. 4.23 Message sequence chart for inward mobility
83
4.1.2.6 Change of the Serving HS-DSCH Cell
A change of the serving HS-DSCH cell occurs if the UE uses HS-DSCH and moves with-
in the area where HSDPA is supported. The purpose of a change of the serving
HS-DSCH cell is to establish the HS-DSCH on the best cell within the active set.
The trigger conditions for serving HS-DSCH change are:
1. Measurement report (event 1A, 1B, 1C, or, if configured, 1A’) from the UE and the
quality of the current serving HS-DSCH cell is worse than the quality of another
reported HSDPA cell. A change of the serving HS-DSCH cell is only performed if the
quality of another HSDPA cell is much better than the quality of the current serving
HS-DSCH cell in order to avoid frequent changes of the serving HS-DSCH cell.
2. Measurement event 1D detects the change of the best HSDPA cell within the active
set.
Measurement report 1D
Measurement event 1D detects the change of the best HSDPA cell within the active set.
If the reported cell is a non-HSDPA cell, channel-type switching from HS-DSCH to DCH
is performed. In addition, channel-type switching from HS-DSCH to DCH is performed
if the reported cell is controlled by the DRNC since HS-DSCH via the Iur interface is not
supported.
The measurement 1D is configured as follows:
1. The “Triggering Condition 2” IE in the MEASUREMENT CONTROL message is set
to “active set cells”.
2. The measurement starts if HS-DSCH is established.
3. The measurement stops after HS-DSCH is released.
The measurement objects are the same as for other intrafrequency measurements. A
cell individual offset is not used for event 1D. Therefore, the “Use CIO” IE to evaluate
the actual quality of the cell is not included in the MEASUREMENT CONTROL
message. The SRNC selects the serving HS-DSCH cell based on the measurement re-
port for event 1D and establishes HS-DSCH.
The SRNC selects the cell reported by the measurement report of event 1D.
1. If this cell is an HSDPA cell and is controlled by the SRNC, the SRNC performs a
change of the serving HS-DSCH cell.
2. If this cell is a non-HSDPA cell or is controlled by the DRNC, the SRNC performs
channel-type switching from HS-DSCH to DCH, see 4.1.2.7"Outward Mobility" on
page 93.
The SRNC ignores the measurement report of event 1D if the reported cell is the same
as the current serving HS-DSCH cell.
Fig. 4.24 shows how the serving HS-DSCH cell is moved from one radio link to another
under the control of the same Node B.
84
SRNC SRNC
UE UE
Fig. 4.24 Intra-Node B change of the serving HS-DSCH cell due to measurement event 1D
The SRNC sends a RADIO LINK RECONFIGURATION PREPARE message to the

related Node B, that is Node B1 in Fig. 4.24. The RADIO LINK RECONFIGURATION
PREPARE message includes the cell-specific parameters since the Node B1 already
has the HSDPA-related parameters. The Node B knows the cell where HS-DSCH is
newly established and where HS-DSCH is deleted by referring to the “HS-PDSCH RL
ID” IE.
Similarly, the TRANSPORT CHANNEL RECONFIGURATION message includes the
cell-specific parameters since the UE already has the HSDPA-related parameters. In
addition, the “MAC-hs Reset Indicator” is set to “true” in the TRANSPORT CHANNEL
RECONFIGURATION message.
Fig. 4.25 shows the message sequence chart for an intra-Node B change of the serving
HS-DSCH cell due to measurement event 1D. The “target cell” indicates the cell where
HS-DSCH will be established and the “source cell” indicates the cell where HS-DSCH
was established before the serving HS-DSCH cell was changed.
85
UE Node B1 SRNC
Decision to change HS-DSCH serving cell
Allocate H-RNTI
(for target cell)
UE can start “listening” to the new

HS-DSCH at the given activation time
Deallocate H-RNTI
(for source cell)
Fig. 4.25 Message sequence chart for an intra-Node B change of the serving HS-DSCH cell (event 1D)
Fig. 4.26 shows how the serving HS-DSCH cell is moved from one radio link to another
radio link between two different Node Bs.
SRNC SRNC
UE UE
Fig. 4.26 Inter-Node B serving cell change due to measurement event 1D
The SRNC sends a RADIO LINK RECONFIGURATION PREPARE message to the

Node Bs concerned, these being Node B1 and Node B2 in Fig. 4.26. The RADIO LINK
RECONFIGURATION PREPARE message sent to the Node B which releases
HS-DSCH, that is Node B1 in Fig. 4.26, only includes “HS-DSCH MAC-d flows to
delete” to delete all HS-DSCH MAC-d flows.
The RADIO LINK RECONFIGURATION PREPARE message sent to the Node B which
establishes HS-DSCH, that is Node B2 in Fig. 4.26, includes all HSDPA-related
86
parameters since this is the first HS-DSCH establishment for that Node B. The HSDPA-
related parameters are the same as the parameters used to configure HS-DSCH. The
TRANSPORT CHANNEL RECONFIGURATION message includes only the cell-
specific parameters since the UE already has the HSDPA-related parameters. In
addition, the “MAC-hs Reset Indicator” is set to “true” in the TRANSPORT CHANNEL
RECONFIGURATION message.
Fig. 4.27 shows the message sequence chart for inter-Node B serving cell change due
to measurement event 1D. The “target cell” indicates the cell where HS-DSCH will be
established and the “source cell” indicates the cell where HS-DSCH was established be-
fore the serving HS-DSCH cell was changed.
MEASUREMENT REPORT (Event 1D)
Allocate H-RNTI
(for target cell)
RADIO LINK RECONFIGURATION PREPARE (Deletion of HS-DSCH)
RADIO LINK RECONFIGURATION PREPARE (Establishment of HS-DSCH)

Deallocate H-RNTI
(for source cell)
Fig. 4.27 Message sequence chart for inter-Node B serving cell change (event 1D)
87
Measurement report 1A, 1B, 1C, or, if configured, 1A’
The active set of a UE varies as the UE moves from one cell to another. As a conse-
quence, a new HSDPA cell can be added to the active set and this cell might be the best
one. The quality of each cell is derived from the CPICH Ec/N0 IE included in the “Cell
Measured Results” IE.
The SRNC selects the serving HS-DSCH cell based on the measurement report of
event 1A, 1B, 1C or, if configured, 1A’ and a predefined threshold to avoid frequent
change of the serving HS-DSCH cell.
The SRNC selects the new active set based on the “Event results” IE. Afterward, the
SRNC confirms whether the current serving HS-DSCH is deleted:
• The current serving HS-DSCH is not deleted:
– The best cell is the current serving HS-DSCH cell or the best cell is not the current
serving HS-DSCH cell but the difference between the quality of the best cell and
the current serving HS-DSCH cell is below the predefined threshold. In this case,
the SRNC performs an active set update.
– The best cell is not the current serving HS-DSCH cell and the difference in quality
between the best cell and the current serving HS-DSCH cell is above the
predefined threshold. In this case, the SRNC performs an active set update
followed by a change of the serving HS-DSCH cell if the best cell is an HSDPA
cell and is controlled by the SRNC. If the best cell is a non-HSDPA cell or is con-
trolled by the DRNC, the SRNC performs channel-type switching from HS-DSCH
to DCH.
• The current serving HS-DSCH is deleted:
The SRNC stops transmission of the HS-DSCH data frame.
– If the best cell is an HSDPA cell and is controlled by the SRNC, the SRNC
performs an active set update followed by a change of the serving HS-DSCH cell.
– If the best cell is a non-HSDPA cell or is controlled by the DRNC, the SRNC
performs channel-type switching from HS-DSCH to DCH.
If the check of the measurement report results in an intrafrequency SRNS relocation
without Iur interface, SRNS relocation is performed instead of an active set update
and/or channel-type switching from DCH to HS-DSCH.
If the change of the serving HS-DSCH cell is triggered by the measurement reporting
event 1A or 1A’, the current serving HS-DSCH cell is not deleted by the active set update
procedure. If, however, the change of the serving HS-DSCH cell is triggered by meas-
urement reporting event 1B or 1C, the current serving HS-DSCH cell might be deleted
by the active set update procedure. Therefore, the message sequence chart is different
in both cases.
Fig. 4.28 shows a scenario where the radio link on which HS-DSCH was previously
established is not deleted after the change of the serving HS-DSCH cell.
88
SRNC SRNC
UE UE
Fig. 4.28 Change of the serving HS-DSCH cell due to measurement event 1A
If the active set update procedure is completed, the message sequence is the same as
for inter-Node B change of the serving HS-DSCH cell due to measurement event 1D. If
the new radio link is established via a Node B that currently has HS-DSCH and
HS-DSCH is moved to that radio link, the message sequence after the active set update
procedure is the same as for an intra-Node B change of the serving HS-DSCH cell due
to measurement event 1D. Fig. 4.29 shows the message sequence chart for the change
of the serving HS-DSCH cell due to measurement event 1A where the current serving
HS-DSCH cell is not deleted. “Target Cell” indicates the cell where HS-DSCH will be
established and “Source Cell” indicates the cell where HS-DSCH was established
before the serving HS-DSCH cell was changed.
89
m
MEASUREMENT REPORT (Event 1A)
Active Set Update RADIO LINK ADDITION REQUEST
RADIO LINK ADDITION RESPONSE
ACTIVE SET UPDATE
Serving HS-DSCH Cell Charge Allocate H-RNTI

(for target cell)
RADIO LINK RECONFIGURATION PREPARE (Deletion of HS-DSCH)

Deallocate H-RNTI
(for source cell)
Fig. 4.29 Message sequence chart for the change of the serving HS-DSCH cell (event 1A)
90
Fig. 4.30 shows a scenario where the radio link on which HS-DSCH was previously
established is deleted after the change of the serving HS-DSCH cell.
SRNC SRNC
UE UE
Fig. 4.30 Change the serving HS-DSCH cell due to measurement event 1C
If the active set update procedure is completed, the current serving HS-DSCH cell is
deleted. In order to minimize the loss of data, the SRNC stops the transmission of
HS-DSCH data frames before the active set update procedure is performed. The SRNC
sends a RADIO LINK RECONFIGURATION PREPARE message to the Node B
concerned, that is Node B2 in Fig. 4.30, if the active set update procedure is complete.
The RADIO LINK RECONFIGURATION PREPARE message includes all HSDPA-
related parameters which were used in the previous configuration of HS-DSCH. The
TRANSPORT CHANNEL RECONFIGURATION message includes all HSDPA-related
parameters since the radio link on which HS-DSCH is mapped has been deleted by the
active set update procedure and the UE has released all HSDPA-related parameters.
Fig. 4.31 shows the message sequence chart for the change of the serving HS-DSCH
cell due to measurement event 1C. The “target cell” indicates the cell where the
HS-DSCH will be established and the “source cell” indicates the cell where the
HS-DSCH was established before the serving HS-DSCH cell was changed.
The transport bearer corresponding to the source serving HS-DSCH cell is deleted by
the active set update procedure and the transport bearer corresponding to the target
serving HS-DSCH cell is newly established if
• the current serving HS-DSCH cell is deleted by the active set update procedure AND
• both the source serving HS-DSCH cell and the target serving HS-DSCH cell are
controlled by the same Node B (the intra-Node B case)
91
MEASUREMENT REPORT (Event 1C)
ACTIVE SET UPDATE
RADIO LINK DELETION REQUEST
RADIO LINK DELETION RESPONSE
Deallocate H-RNTI
(for source cell)
HS-DSCH Reestablishment Allocate H-RNTI

(for target cell)

Fig. 4.31 Message sequence chart for the change of the serving HS-DSCH cell (Event 1C)
92
4.1.2.7 Outward Mobility
Outward mobility occurs if the UE leaves the area where HSDPA is supported. In this
case, the quality of the non-HSDPA cell is much better than the quality of the HSDPA
cell or the HSDPA cell is removed from the active set. Therefore, channel-type switching
from HS-DSCH to DCH is performed.
The trigger conditions for outward mobility are:
1. Measurement report (event 1A, 1B, 1C, 1D, or, if configured, 1A’) from the UE and
the quality of the non-HSDPA cell is better than the quality of the HSDPA cells. Chan-
nel-type switching from HS-DSCH to DCH is performed only when the quality of the
current serving HS-DSCH cell is much worse than the quality of the non-HSDPA
cells in order to avoid frequent channel-type switching between HS-DSCH and DCH.
2. Measurement report (event 1B or 1C) from the UE and no HSDPA cell will be
included in the next active set.
3. Measurement report (event 1A, 1B, 1C, 1D, or, if configured, 1A’) from the UE and
the quality of the cell under the control of the DRNC is better than the quality of the
HSDPA cells under the control of the SRNC.
4. Measurement report (event 2D/2D’/D’’) from the UE. Channel-type switching from
HS-DSCH to DCH is performed only when the quality of the current serving
HS-DSCH cell is much worse than the quality of the non-HSDPA cells in order to
avoid frequent channel-type switching between HS-DSCH and DCH.
5. Measurement report (event 1A, 1C, or, if configured, 1A’) from the UE and
intrafrequency SRNS relocation without Iur interface is triggered.
Outward mobility is subdivided into an intrafrequency and an interfrequency/intersystem
process.
Detection of outward mobility (intrafrequency process)

Outward mobility is detected during the change of the serving HS-DSCH cell process
due to:
• Quality degradation of the HSDPA cells because the UE leaves the area where
HSDPA is supported
• Removal of all HSDPA cells from the active set
• UE mobility toward the DRNC
• Initiation of intrafrequency SRNS relocation without Iur interface
If the SRNC receives a measurement report for the preparation of an SRNS relocation
during channel-type switching from HS-DSCH to DCH, it is treated as a measurement
report that is received within the time period between SRNS relocation is triggered and
the SRNC sends an RANAP: RELOCATION REQUIRED message.
If intrafrequency SRNS relocation with Iur interface is performed, the UE does not use
HS-DSCH because HS-DSCH via Iur interface is not supported.
Fig. 4.32 shows how a new radio link is established via a new Node B while this Node B
does not support HSDPA.
93
SRNC SRNC
UE UE
Fig. 4.32 Outward mobility
The current serving HS-DSCH cell is deleted if the active set update procedure is
completed. The SRNC stops transmission of the HS-DSCH data frame before channel-
type switching from HS-DSCH to DCH in order to minimize the loss of data. If the active
set is not changed, that is the trigger is event 1D or SRNC relocation, only channel-type
switching from HS-DSCH to DCH is performed.
Fig. 4.33 shows the message sequence chart for outward mobility. For more informa-
tion on the handling of the transport bearer for DTCH see "HSDPA RAB Handling" on
page 43.
Since DL bit rate adaptation is applicable when DCH is used, the CRNC sends a
DEDICATED MEASUREMENT INITIATION REQUEST message to the related
Node Bs to initiate the transmitted code power (radio link quality) measurement if
measurement event 1D is released.
94
MEASUREMENT REPORT (Event 1B/1C)
Decision to perform CTS (HS-DSCH -> DCH)
ACTIVE SET UPDATE
RADIO LINK DELETION REQUEST
RADIO LINK DELETION RESPONSE
Deallocate H-RNTI
ALCAP Iub Transport Bearer Release (DCCH + DTCH)
HS-DSCH Reestablishment RADIO LINK RECONFIGURATION PREPARE (Modification of UL/DL DTCH)
ALCAP Iub Transport Bearer Setup (UL/DL-DSCH)
RADIO BEARER RECONFIGURATION
UE can start “listening” to DCH

at the given activation time
RADIO BEARER RECONFIGURATION COMPLETE
MEASUREMENT CONTROL (Event 1D) (Release)
Fig. 4.33 Outward mobility
95
Detection of outward mobility (interfrequency / intersystem process)
If the UE enters the end of the coverage of an HSDPA-capable cell, the quality of that
cell becomes insufficient and the SRNC may receive a measurement report of
event 2D/2D’/2D’’.
The following procedure is performed if the SRNC receives the measurement report of
event 2D/2D’/2D’’:
1. The SRNC performs channel-type switching from HS-DSCH to DCH without
changing the frequency/system.
2. The SRNC orders the UE to perform interfrequency/intersystem measurement.
If the condition for interfrequency/intersystem handover is met, the UE is moved to an-
other frequency or system. The UE stays on the frequency currently used if the condition
for an interfrequency/intersystem handover is not met and interfrequency/intersystem
measurement is deactivated.
4.1.2.8 DRNC Behavior

HSDPA is not established via the Iur interface. If the RNC acts as a DRNC, the SRNC
may request the DRNC to establish HS-DSCH. In this case, the DRNC rejects the
request with the case value “DL Shared Channel Type not Supported”.
4.1.2.9 Error Handling

This section summarizes the handling of failures.
HS-DSCH establishment or release

HS-DSCH establishment or release is subdivided into two phases:
• Active set update
• Channel-type switching between HS-DSCH and DCH or change of the serving
HS-DSCH cell
For more information on error handling see "HSDPA RAB Handling" on page 43.
When channel-type switching from DCH to HS-DSCH is performed, the active set
update procedure has been successfully completed (event 1A, 1B, 1C, or, if configured,
1A’). In the case of event 1D, however, the active set is unchanged.
In the event of an admission control failure or an NBAP failure (RL reconfiguration
prepare failure) or an ALCAP failure, DCH is still available even if HS-DSCH is not avail-
able. Therefore, the SRNC keeps the current configuration, that is DCH. Channel-type
switching from DCH to HS-DSCH is triggered by the next active set update procedure.
When channel-type switching from HS-DSCH to DCH is performed, the active set
update procedure has been successfully completed (event 1A, 1B, 1C, or, if configured,
1A’). In the case of event 1D or 2D/2D’/2D’’, however, the active set is unchanged.
In the event of an NBAP/RNSAP failure (RL reconfiguration prepare failure with a cause
value other than “not enough user plane processing resources”) or an ALCAP failure,
HS-DSCH is released and RRC connection reestablishment is performed since
HS-DSCH is not established on the best cell any more. Channel-type switching from
FACH to HS-DSCH is triggered by traffic monitoring.
Upon an admission control failure or an NBAP/RNSAP failure (RL reconfiguration
prepare failure with the cause value “not enough user plane processing resources”), a
retry at the minimum rate of the DCH is performed.
96
When the serving HS-DSCH cell is changed, the active set update procedure has been
successfully completed (event 1A, 1B, 1C, or, if configured, 1A’). In the case of event
1D or 2D/2D’/2D’’, however, the active set is unchanged. Since the associated DCH has
already been established, failures due to admission control in the CRNC never happen.
In the event of an NBAP failure (RL reconfiguration prepare failure with a cause value
other than “not enough user plane processing resources”) or an ALCAP failure,
HS-DSCH is released and RRC connection reestablishment is performed since
HS-DSCH is not established on the best cell any more. Channel-type switching from
FACH to HS-DSCH is triggered by traffic monitoring.
Upon an admission control failure or an NBAP/RNSAP failure (RL reconfiguration
prepare failure with the cause value “not enough user plane processing resources”), a
retry at the minimum rate of the DCH is performed.
If an RRC message fails and RRC connection reestablishment is allowed according to
the current system, RRC connection reestablishment is performed. The failure handling
of RRC messages depends on the type of error, for example the cause value.
RL failure of the RL on which the serving HS-DSCH cell is mapped

If the CRNC receives a RADIO LINK FAILURE INDICATION message with the cause
value “synchronization failure” from the cell where HS-DSCH is currently established
and the radio link concerned is not the last one, the radio link is deleted. The UL
synchronization immediately gets lost and channel-type switching from HS-DSCH to
DCH is performed. This behavior is similar to outward mobility handling where the
serving HS-DSCH cell is deleted by event 1B. If the radio link concerned is the last one,
RRC connection reestablishment is performed. If the cause value of the RADIO LINK
FAILURE INDICATION message is other than “synchronization failure”, no HSDPA
specific error handling is performed.
Reception of measurement report 1D during change of the serving HS-DSCH

cell/outward mobility
If the SRNC receives a measurement report of event 1D during a change of the serving
HS-DSCH cell/outward mobility and the active set update is completed, the SRNC
handles this report in a way similar to other intrafrequency measurement reports during
RAB setup. Measurement reports other than event 1D are handled during inward
mobility/change of the serving HS-DSCH cell/outward mobility similarly to their handling
during RAB setup. If the SRNC receives a measurement report of event 1D during an
active set update, the SRNC handles this report in a way similar to other intrafrequency
measurement reports during an active set update.
Initiation of measurement event 1D

Since event 1D is necessary to detect the best cell within the active set, it results in a
RELEASE CALL message.
Missing RL restore indication

The CRNC expects to receive an RL RESTORE INDICATION message during radio link
establishment:
• First establishment of a radio link set in the active set
This occurs upon channel-type switching from FACH to HS-DSCH.
• Addition of a radio link set to the active set
This occurs upon channel-type switching from DCH to HS-DSCH or serving
HS-DSCH cell change followed by an active set update. Even if the UL
97
synchronization is not achieved in the new radio link, the SRNC receives an ACTIVE
SET UPDATE COMPLETE message via the existing radio links. The SRNC starts
the change of the serving HS-DSCH cell upon reception of the ACTIVE SET
UPDATE COMPLETE message regardless of the reception of an RL RESTORE
INDICATION message from the cell where HS-DSCH is established. If the timer
T_sync has expired, the same error handling is applied as described for a radio link
failure of the radio link onto which the serving HS-DSCH cell is mapped.
4.1.2.10 UE Differentiation
The purpose of the UE differentiation is to assign power resources to HSDPA UEs as
much as possible. This section describes the interdependencies between UE
differentiation, load control, cell configuration, and UE type.
The available load-control types are:
• No load control
• Load-overflow mechanism
• Load-balancing mechanism
UE differentiation uses the load-overflow mechanism. A traffic overflow from
frequency 1 to frequency 2 occurs if a cell in frequency layer 1 is not able to carry
additional radio links. In the UE differentiation mechanism, the CRNC selects the cell to
be checked depending on the cell configuration and the UE type, that is R99 or HSDPA.
Tab. 4.7 shows the interdependencies between UE differentiation, load control, cell
configuration and UE type. “HSDPA” indicates the cell where HSDPA is supported and
the HSDPA state is enabled. “non HSDPA” indicates the cell where neither HSDPA is
supported nor the HSDPA state is enabled. If HSDPA is disabled, UE differentiation is
not performed even if UE differentiation is enabled.
UE differentiation enabled UE differentiation disabled
HSDPA - non HSDPA UE differentiation (Note 1) Load control: Load control type
(R99 UE in non HSDPA cell)
(HSDPA UE in non HSDPA cell)
HSDPA - non HSDPA Load control: Load control type Load control: Load control type
(R99 UE in HSDPA cell)
(HSDPA UE in HSDPA cell)
non HSDPA - non HSDPA Load control: Load control type Load control: Load control type
(R99 UE)
non HSDPA - non HSDPA Load control: Load control type Load control: Load control type
(HSDPA UE)
Tab. 4.7 Interdependency between UE differentiation, load control, cell configuration and UE type
Note 1: A non-HSDPA cell is selected at first. If this procedure fails, an HSDPA cell is
selected. The load-overflow mechanism is applied in the cell in both cases.
Note 2: An HSDPA cell is selected at first. If this procedure fails, a non-HSDPA cell is
selected. The load-overflow mechanism is applied in the cell in both cases.
98
4.1.3 HSDPA Admission Control and Congestion Control
The HSDPA feature in UMR5.0 requires functionality to admit UEs onto the HSDPA
channel, i.e. the HS-DSCH and the HS-PDSCH. UEs which support HSDPA are only
admitted to the HSDPA channel if certain preconditions, such as a successful load
check and the support of the applied service or bearer on the HS-DSCH, are fulfilled.
In general, setting up each PS bearer on the HSDPA channel is preferred in order to
maximize the gain HSDPA provides to the user and the cell capacity. UMR5.0 supports
only the setup of PS Interactive/Background bearers on the HS-DSCH. Although used
in an HSDPA-capable cell, these bearers sometimes have to be set up on dedicated
channels (DCHs), however, if a UE is only capable of 3GPP Rel 99 or if no more HSDPA
resources are available, etc. To avoid such a scenario, additions and changes have
been made to the existing rate restriction algorithm.
If, however, PS Interactive/Background RABs are set up on DCHs, the operator is able
to restrict or to lower the rates on the relevant DCH. This keeps the available HSDPA
resources as high as possible. As applied for the existing restriction control mechanism,
this is performed by limiting the minimum available spreading factor (SF) rather than the
rate itself.
4.1.3.1 Radio Resource Management (RRM) Issues

This section deals with the following topics:
• RRM functionalities in the controlling RNC (CRNC) affected by HSDPA
• Interactions between RRM functions
RRM functionalities in the controlling RNC (CRNC)

The CRNC handles the cell-related RRM functionalities. Fig. 4.34 illustrates those RRM
functionalities that are located in the CRNC. HSDPA admission control affects the high-
lighted functionalities.
Resource Load Control Congestion Node B Measurem. Power Control

Allocation Control Control
Admission Interfrequency Congestion Measurement Initial Values for

Control Load Control Control Reporting Control Power Control
Code Allocation, Preprocessing

Release Control
Restriction
Control Affected by HSDPA
Admission Control
Fig. 4.34 Radio resource management functions in the CRNC
Interactions between RRM functions

Admission control reacts upon different serving RNC (SRNC) radio link (RL) requests
by either reporting a response or a failure. Admission control’s behavior upon reception
of requests related to DPCHs has only been slightly modified.
Admission control handles HSDPA-related requests in a similar way to DPCH-related
requests. The handling is based on the DPCHs required by the HSDPA-capable UE. In
99
general, each UE on a PS RAB which is associated to the HSDPA channel requires the
following:
• Downlink (DL) direction
– One associated DPCH with spreading factor (SF) 256
• Uplink (UL) direction
– One DPCH in the uplink (UL) direction for the HS-DPCH (for HARQ and CQI) with
SF 256
– One associated DPCH (signaling radio bearer SRB) for traffic of varying SF re-
gardless of whether or not waiting data exists
The decision of admission control about whether or not to admit a UE on a channel de-
pends on periodic common measurements. The relevant measurement reports are sent
via NBAP. These reports indicate the ratio of non-HSDPA power in relation with the
maximum configured power in the relevant Node B. Each report is treated by higher-lay-
er-filtering (floating average) over a certain time frame.
Fig. 4.35 illustrates the interactions between admission control and code allocation in-
cluding the protocols and measurements, call processing, and OAM databases in the
event of allocating or deallocating resources.
CRNC: Congestion Indication

CRNC CRNC OAM
Measure- Dynamic Database
NBAP: Common Measurement Report ment Database
Database
Resource Allocation
}
Yes RNSAP: Radio Link Setup Response
No RNSAP: Radio Link Setup Failure

RNSAP: Radio Link Setup Request
Yes RNSAP: Radio Link Addition Response

Allocate Resources
No RNSAP: Radio Link Addition Failure

RNSAP: Radio Link Addition Request Admission
Control
Yes RNSAP: Radio Link Reconfiguration Ready
RNSAP: Radio Link Reconfiguration No RNSAP: Radio Link Reconfiguration Failure
Prepare
Deallocate Resources
RNSAP: Radio Link Deletion Response
}
RNSAP: Radio Link Deletion Request
DL Scrambling
and
RNSAP: Radio Link Reconfiguration
Channelization
Commit
Code
RNSAP: Radio Link Reconfiguration Allocation/Release
Cancel
Fig. 4.35 Interactions between admission control and code allocation
100
4.1.3.2 Load, Power, and Code Management
In the event of a request to set up, reconfigure, or hand over a new radio link, admission
control determines the current load. The decision regarding whether to admit or reject
this request is based on the load value determined and the additional load occurring
through the radio link’s setup, reconfiguration or handover. Admission control applies
the following formula for this decision:
currentLoad + newLoad – oldLoad < Threshold
In UMR5.0, dynamic reallocation of codes used for the HS-DSCH is not performed.
Therefore, no trigger is needed.
Definition of the system load

No changes have been made in comparison to the last product release prior to UMR5.0
for the received total wideband power (RTWP) on the UL.
In the DL direction, on the other hand, the system load is calculated analogously to the
algorithm defined in UMR3.5. The total transmitted carrier power measurement, howev-
er, is replaced by the measurement of the non-HSDPA power if both the cell is capable
of serving HSDPA and the non-HSDPA power measurement has been successfully es-
tablished.
The transmitted-carrier power measurements will only be set up if HSDPA has been dis-
abled or the Node B does not support non-HSDPA power measurements due to an up-
grade phase, etc. In this case, admission control performs the load calculation with the
results of the transmitted-carrier power measurements.
When setting up a DL radio link for HSDPA, admission control is performed for the as-
sociated dedicated physical channels (DPCHs). The admission control algorithm then
has to admit these channels in a similar way as for other dedicated channels. In order
to take into account the associated DPCHs and the UL DPCH of the HS-DPCCH of all
HSDPA users in the event of congestion, too, congestion control is adapted to this situ-
ation. For details, please refer to "Congestion Control Algorithm" on page 106.
Update of load values

On the UL, the update of the load values is based on the RTWP measurements. The
update is then performed upon setup, release, handover, or reconfiguration of the rele-
vant radio link.
In the DL direction, admission control updates the load values of the non-HSDPA load
when handling a new non-HSDPA measurement report and at the setup, release,
handover, or reconfiguration of the relevant radio link.
Allocation of the power for HS-DSCH

The allocation of the power for the HS-DSCH is described in "Code and Power Alloca-
tion" on page 112.
Error handling
If the non-HSDPA power measurements cannot be initiated, transmitted carrier power
measurements will be started instead. As a consequence, the cell operates only in non-
HSDPA mode. "State Management" on page 108 describes the specific handling of the
measurement setup and the related error handling in more detail.
101
4.1.3.3 Admission Control in the CRNC
This section describes the handling of radio link setups, reconfigurations, and hando-
vers by admission control in the CRNC.
In general, HSDPA admission control does not interact with admission control for DPCH
users. If a congestion occurs on the UL or if the setup of either the associated DPCH in
the UL direction or the UL DPCH for the HS-DPCCH fails, however, admission control
rejects admitting PS bearers on the HSDPA channel.
With regard to the admission decision for HSDPA users, the CRNC which is aware of its
associated Node Bs distinguishes between a new-call request/transport channel-type
switching (CTS) and a soft/softer handover. In this context, the distinction is as follows:
a completely new radio bearer, on the one hand, is set up in its own RNC. In other words,
the SRNC is identical with the CRNC. A radio link setup request via the RNSAP protocol,
on the other hand, identifies a soft/softer/hard handover. If an RRC connection reestab-
lishment request is received via the Iur interface, however, CTS is performed because
UMR5.0 does not support HSDPA via the Iur interface.
Basically, the HSDPA feature impacts on admission control handling for HSDPA users
with respect to the following topics:
• Handovers due to
– Change of the serving HSDPA cell
– Inward mobility
– Outward mobility
• New calls and call reestablishment
• Reconfiguration from DCH to HS-DSCH and vice versa
Handovers
Whenever a handover of an existing bearer associated with the HSDPA channel is per-
formed, the MAC-hs is reset. If congestion occurs, admission control does not reject the
handover of the related DPCHs. Furthermore, the handover of a PS bearer on the old
cell’s HSDPA channel to be located on the new cell’s HSDPA channel is performed in a
similar way as a handover for DCHs.
With respect to mobility, admission control handling is performed as follows, depending
on the relevant case:
• Case 1: Change of the serving HSDPA cell
– In this case, only the UL load information for the HS-DPCCH of the new serving
cell is provided because the SRB and the UL dedicated traffic channel (DTCH)
parts have already been configured. This requires a new handling method.
– Upon RL reconfiguration, the old HSDPA UL DPCCH load is deducted from the
old serving cell. This requires a new handling method, too.
– For the new serving cell, nothing has to be released, which is also a new handling
method.
– The CRNC allocates the H-RNTI (radio network temporary identify) for the new
serving cell.
– The CRNC deallocates the H-RNTI for the old serving cell.
• Case 2: Inward mobility
– On the DL, the load information for the associated DPCH (SRB 3.4 kbit/s) is avail-
able.
– On the UL, the load information for both the HS-DPCCH (for the HSDPA radio link)
and the associated DPCCH is available (UL PS bearer 64 or 384 kbit/s).
– In both the UL and DL directions, the old load information is available.
102
– Upon RL reconfiguration, the old load of all cells in the active set is removed. This
handling method is the same as that currently applied.
– The CRNC allocates the H-RNTI.
• Case 3: Outward mobility
– On the DL, the new load information for the DCH is available.
– On the UL, the new load information for the DCH is available.
– In both the DL (SRB) and UL (HS-DPCCH-related PS bearer for the HSDPA radio
link with 64 or 384 kbit/s) directions, the old load information is available.
– The CRNC deallocates the H-RNTI.
New calls and call reestablishment

New CS streaming or conversational bearers are set up as specified in product releases
prior to UMR5.0. In the event of a multicall, the new bearer is set up in DCH state. The
setup is automatically performed by the SRNC. Furthermore, the cell’s capability of pro-
viding HSDPA service must be determined as described in "Code and Power Allocation"
on page 112.
Admission control then has to verify the possibility of setting up the required UL DPCH
for the SRB and PS traffic (i.e. the associated DPCH) and both the UL- and DL-associ-
ated DPCHs for the HS-DPCCH. Therefore, in the event of a RAB setup or an increase
of the load, admission control checks the “Congestion Indication” IE and will only pro-
ceed if this IE’s value is “FALSE”. If this condition is not fulfilled, however, admission
control rejects the setup on the HSDPA channel.
NOTE
i When admission control rejects the setup on the HSDPA channel, a retry on
DCH state with the minimum rate is attempted. RAB pre-emption will then ap-
ply, too.
Admission control uses several load thresholds for the different DPCHs which are re-
quired for an HSDPA-capable UE to operate. The thresholds are as follows:
• For the associated DPCH on the DL, the threshold for the SRB 3.4 kbit/s is applied.
The HS-DPCCH required in the UL direction uses the threshold for this SRB, too.
• For the associated DPCH on the UL, the thresholds for the PS interactive/back-
ground bearers is applied. Their corresponding UL rate thresholds are based on the
slope function.
• Since the HS-DPCCH is only used for control issues, a new load is applied for the
HS-DPCCH which is exclusively applicable to the HSDPA radio link, thus requiring
a new physical channel type attribute for the HS-DPCCH. The gain factors Bc and
Bd, however, will only be system data.
With regard to requirements concerning the signal-to-interference ratio (SIR), the values
of the channels mentioned before are applied.
Since two channels, i.e. the associated DPCH and the HS-DPCCH which is only appli-
cable for the HSDPA radio link, are always used on the UL, HSDPA admission control
has to consider these two pieces of load information.
With respect to call establishment and reestablishment in UMR5.0, admission control
handling is performed as follows, depending on the relevant case:
• Case 1: PS RAB setup triggering a DCH to HS-DSCH procedure
Admission control handles this situation in the same way as an inward mobility
handover.
103
• Case 2: PS RAB setup triggering a FACH to HS-DSCH procedure or CTS due to
traffic triggering a FACH to HS-DSCH procedure
Admission control handles these situations in the same way as an inward mobility
handover. In these situations, however, only one radio link is applicable and no load
information is available.
• Case 3: HS-DSCH to DCH procedure due to RAB assignment/release
Admission control handles this situation in the same way as an outward mobility
handover.
• Case 4: HS-DSCH to FACH procedure due to inactivity or reestablishment to
FACH
– No new resources are required.
– Both on the DL (SRB) and on the UL (HS-DPCCH for the HSDPA radio link and
the UL PS bearer with 64 or 384 kbit/s), the old load information is available.
– Upon RL reconfiguration, the old load of all cells in the active set is removed.
Thus, the admission control “Release Resource Indicator” IE has to include two
pieces of the old UL load information: one for the UL PS DTCH and one for the
UL HS-DPCCH.
– The CRNC deallocates the H-RNTI.
Reconfiguration from DCH to HS-DSCH and vice versa

Reconfiguring an HSDPA-related bearer to a DCH and vice versa is only supported dur-
ing a mobility handover and in the event of a change from single call to multicall.
4.1.3.4 Restriction Control in the CRNC for HSDPA

NOTE
i HSDPA restriction control is an optional feature controlled by the SWP “HSDPA Restric-
tion Control“ flag and only enabled if the feature is part of the contract.
In most cases, it is more beneficial for the whole system to set up a PS radio bearer (only
PS interactive/background bearer in UMR5.0) on top of the HS-PDSCH instead of on
top of the DCH. Some situations may occur, however, in which the setup of the PS in-
teractive/background bearer on top of the DCH is required. This exception is valid for
the following situations:
• No support of HSDPA by the UE
• No support of the multicall/bearer combination on the HSDPA channel by the UE
The UE supports the PS interactive/background bearer on top of the HS-PDSCH but
not for the required service combination.
• Not enough user plane processing resources
The UE supports the PS interactive/background bearer on top of the HS-PDSCH.
One of the following situations occurred, however:
– No more resources are available in the Node B’s hs-CHC. As a consequence, the
Node B rejects the setup of the PS bearer on top of the HSDPA channel with the
cause set to “Not Enough User Plane Processing Resources“.
– The current load is too high in order to allow the setup of the associated DPCHs.
As a consequence, admission control rejects the setup of the PS bearer on top of
the HS-PDSCH. In this situation, however, a retry on the DCH with the minimum
UL/DL rate of 8 kbit/s/8 kbit/s and pre-emption is possible.
In any of these situations, the admission of the PS interactive/background bearer on the
DCH is to be limited to rates equal to or lower than 128 kbit/s in HSDPA-capable cells.
This is due to avoid HSDPA-capable UEs not allowed on the HS-PDSCH or Rel 99-only
104
UEs consume cell capacity and thus degrading the performance of HSDPA. Otherwise,
HSDPA would suffer from a lack of available resources because it can only use the pow-
er remaining after DPCH bearers have been served. As currently applied, this restriction
is performed by limiting the minimum available spreading factor rather than the rate it-
self.
The operator can restrict the minimum available SF, using the additional new restriction
control functionality with the following key properties:
• This rate restriction is to be independent of the normal rate restriction.
Therefore, an additional new separate parameter which is configurable via the OMC-
R is specified in order to restrict the minimum available SF for the PS interac-
tive/background RAB on top of the DCH in the relevant HSDPA cell.
• The new rate restriction only applies for the PS interactive/background bearers on
the DCH in an HSDPA-capable cell. PS interactive/background bearers on DCHs in
non-HSDPA-capable cells, however, are not affected.
• The effectively-allowed minimum SF is the maximum of the following: the minimum
SF allowed by the normal restriction control and the minimum SF allowed by the spe-
cific restriction control for the PS interactive/background bearer.
Therefore, the existing (normal) restriction control is modified in such a way that it is
able to determine this maximum and, consequently, the applicable SF.
The following mathematical expression is applied when determining the effectively-
allowed minimum SF:
minEffSF = max [minNormSF ,minHsdpaSF ]
• Setting the minimum available SF for the PS interactive/background RAB on the

DCH in an HSDPA-capable cell to the lowest SF (8) in the OMC-R will disable this
new restriction control mechanism.
• The new rate restriction mechanism is only available if the specific cell’s HSDPA
channel serves a predefined number of HSDPA-capable UEs. Otherwise, the SFs
and, therefore, the rates, too, will not be restricted, thus maximizing the throughput
for the Rel 99 UEs.
• The parameters are cell-specific
The new restriction control algorithm is only applied if both the “HSDPA Restriction Con-
trol“ optional feature flag is enabled and the number of UEs using HSDPA service ex-
ceeds a predetermined threshold. Admission control thus uses the already allocated H-
RNTI to determine the number of UEs allocated on the HSDPA channel.
Changed restriction control procedure for HSDPA

Admission control uses the already allocated H-RNTI to determine whether HSDPA-ca-
pable UEs are assigned to the HSDPA channel. The new rate restriction mechanism is
applied when the allocated H-RNTI is greater than the specified threshold and the ad-
mission of a new PS interactive/background bearer is evaluated. Furthermore, admis-
sion control determines the minimum effectively allowed SF.
If the new restriction control algorithm fails only due to the minimum SF allowed by the
normal restriction control, the currently existing restriction failure cause will always be
used.
In the event of a bearer failing the new HSDPA restriction control, the CRNC always pro-
vides the failure cause of the HSDPA restriction control to the SRNC. Furthermore, the
CRNC always provides the minimum available SF to the SRNC.
105
At the setup (RAB establishment, reestablishment, or CTS) or handover of a bearer (soft
or inter-frequency handover), the new HSDPA-specific restriction control mechanism is
applied. The SRNC, however, then handles the restriction according to the current im-
plementation. In other words, it retries the procedure with the minimum rate instead of
the minimum SF.
Furthermore, the new HSDPA-specific restriction control is applied for bearer reconfig-
uration, i.e. bit rate adaptation UP or DOWN. A failure in the BRA procedure due to HSD-
PA restriction control requires a new error handling of the SRNC. If the normal restriction
causes the failure, however, the existing handling will be applied.
Handling of a BRA request upon activation of HSDPA restriction control

If the threshold for activating the HSDPA-specific restriction control has been reached,
the PS interactive/background bearer may issue a BRA UP or DOWN procedure. Re-
gardless of whether the BRA UP or BRA DOWN procedure is used, i.e. in any configu-
ration of the bearer, the SRNC performs the subsequent error handling if the bearer fails
due to the HSDPA-specific restriction check. The following actions are carried out per
UTRAN cell:
• First, the SRNC cancels that RL reconfiguration over the SRNC and/or the DRNC
which has successfully been reconfigured before.
• The SRNC checks the value of the minimum available SF.
– If the RLs in the active set fail due to the HSDPA-specific restriction control when
the UE is in soft handover state, the SRNC selects the minEffSF.
– If the current bearer’s SF is smaller than the minimum available SF, the SRNC per-
forms a BRA DOWN procedure to a DL rate which is equal to the rate indicates
by the minimum available SF or the next lower rate.
– Otherwise, if the current bearer’s SF is greater than the minEffSF, the SRNC will
keep the current configuration of the bearer(s).
4.1.3.5 Admission Control in the Node B

In UMR5.0, no admission control mechanism for the HS-DSCH, and therefore for
HSDPA, exists in the Node B. The Node B, however, may reject bearers due to a lack
of resources.
The setup of that DL DPCH which is associated to the HS-DSCH is treated by the
Node B’s admission control algorithm for dedicated channels. In UMR5.0, this admis-
sion control algorithm, however, is extended in such a way that its operation is based on
the non-HSDPA power instead of the transmitted carrier power if the affected UTRAN
cell is capable of serving HSDPA.
4.1.3.6 Congestion Control Algorithm

Congestion control defines the absolute limits for DCH radio bearers in situations when
the network runs out of resources in either the UL or the DL direction. Introducing the
HSDPA feature does not impact on the congestion control algorithm on the UL.
In the DL direction, in contrast, resources on the HS-DSCH are allocated for HSDPA-
capable UEs as long as both the predefined thresholds for HSDPA services are not ex-
ceeded and these resources are available in the system. The congestion decision does
therefore not directly depend on the usage of the HS-DSCH. For this reason, the non-
HSDPA transmitted carrier power is used to decide about whether or not a congestion
106
occurred. The algorithm applied is the same as introduced in the UMR3.5 Enhanced
Congestion Control feature.
Compared to UMR4.0, the congestion control algorithm has been modified as follows:
• Both event-triggered and periodic measurements for congestion control are based
on the non-HSDPA transmitted carrier power instead of the total transmitted carrier
power.
• With regard to non-HSDPA UEs, stage 1 and stage 2 activities for congestion reso-
lution will remain the same. HSDPA-capable UEs, however, are not treated in
stage 1.
• The congestion control algorithm takes account of UEs from both the primary and
the secondary scrambling code tree. The algorithm furthermore prioritizes bearers
of the same downlink spreading factor from the secondary scrambling code tree.
Congestion detection
The CRNC uses measurement events E to detect congestion. The procedure applied is
according to 3GPP TS 25.133, with one exception: on the DL, the decision about wheth-
er or not congestion occurred depends on the current non-HSDPA transmitted carrier
power.
The same exception applies for error handling. If the event-triggered common measure-
ment initiation request for the non-HSDPA transmitted carrier power fails, congestion
control uses the measurement value reported by the periodic common measurement.
This implementation is the same as applied for admission control.
Congestion resolution
Mainly non-HSDPA bearers on the DL and the UL cause congestions in UTRAN cells
which provide HSDPA service. Since only resources left from DCH bearers are provided
for HSDPA UEs to transmit on the HS-DSCH, no actions are performed on HSDPA UEs
during stage 1. UEs which transmit on the HS-DSCH must therefore be excluded from
stage 1 regardless of their service type (PS interactive or PS background). Furthermore,
PS streaming bearers are not handled in stage 1.
In stage 2, HSDPA UEs are then listed together with other UEs in the specific UTRAN
cell. The UEs which use the HS-DSCH are ranked according to the SF of their associ-
ated DPCH. Those UEs which are to be reconfigured or dropped are then selected in
two stages.
The following rules apply for these two stages:
• The congestion control algorithm handles UEs with the lowest downlink (DL) spread-
ing factor (SF) first, considering both the primary and the secondary scrambling
code tree.
• If bearers have identical DL SFs and, furthermore, if these DL SFs are comprised
from the primary and the secondary scrambling code tree, bearers from the second-
ary scrambling code tree are treated first. In other words, the algorithm prioritizes
bearers from the secondary scrambling code tree over those from the primary
scrambling code tree with the same DL SF.
For details about the different congestion stages (stage 1 and stage 2), please refer to
the OMN:RNC Cell Configuration - Basics.
107
4.1.3.7 Integration of the Admission Control Algorithm for HSDPA
HSDPA admission control is integrated into the existing admission control algorithms.
The only differences are:
• In the event of a soft handover for an HSDPA-related bearer, the restriction check is
skipped.
• At RAB setup, the restriction check is skipped for HSDPA-related bearers.
• With regard to common measurements, the non-HSDPA measurement report is
used instead of the transmitted carrier power measurement report if the UTRAN cell
is capable of providing HSDPA service.
4.1.4 HSDPA Code and Power Allocation and Redimensioning

This section deals with the HSDPA code and power allocation and redimensioning. This
topic contains the following issues:
• HSDPA RRC connection state management and handling
• Code allocation and setup of the HSDPA physical channels
– Highspeed physical downlink shared channel (HS-PDSCH)
– Highspeed shared control channel (HS-SCCH)
• Setup of the “Non-HSDPA Transmit Power” measurement
• Deletion of HSDPA resources
The first three issues in this list are related to logical OAM which is the signaling asso-
ciated with the control of logical resources, such as channels and cells. The logical OAM
is performed in the RNC although physically implemented in the Node B.
4.1.4.1 State Management

A UTRAN cell is capable of providing HSDPA service as soon as the new “High Speed
Downlink Packet Access Channel” object (MOC HSDPA) is configured. The resource
status indication (RSI) and the audit response HSDPA capability information indicate the
capabilities of the Node B which is associated to the relevant UTRAN cell. The RNC,
however, does not use this information do decide if the CRNC is to initialize the HSDPA
resources. This scenario is in line with the implementation principle in product releases
prior to UMR5.0, such as power capability values. In the event of a configuration mis-
match, i.e. if the Node B is not capable of HSDPA although the configuration data re-
quires HSDPA, NBAP (Node B application part) failure handling is applied. The NBAP:
PHYSICAL SHARED CHANNEL RECONFIGURATION FAILURE message is thus
used.
Upon the setup of the HSDPA resources, the RSI is used to monitor the HSDPA re-
sources. The current status is indicated by means of the HS-DSCH resource informa-
tion. Fig. 4.36 provides an overview of the RSI handling.
In general, each status indication of an RSI contains the operational state (OST) and the
availability status (AVS) of the MOC HSDPA, i.e. the HSDPA channel.
108
Node B CRNC
HSDPA channels configured,

HSDPA operational state = enabled non-HSDPA power and
measurement set up
HSDPA-related failure in
the Node B
Resource status indication (RSI)

“HS-DSCH resource information
operational state: disabled”
Cell operational state: degraded Non-HSDPA measurements
will be continued (Node B will
use its transmitted carrier
HSDPA operational state = disabled power measurements and
map these onto the non-
HSDPA power measurement
report)
For all affected HSDPA

NBAP: Radio Link Deletion channels associated with the
degraded cell
Resolution of the HSDPA

failure in the Node B
Resource status indication

“HS-DSCH resource information
operational state: enabled”
Cell operational state: enabled
HSDPA operational state = enabled
Fig. 4.36 Handling of resource status indications
Upon reception of an RSI indicating “HS-DSCH resource information: operational

state = disabled“, the controlling RNC (CRNC) takes the following measures:
• Setting the state attribute of the MOC HSDPA to disabled
• Informing the operation and maintenance center (OMC) about the deactivated sta-
tus of the MOC HSDPA including the MOC’s availability status
• Triggering the release of all radio links that are both established on the degraded cell
and mapped to the disabled HS-DSCH. To release the links, radio link deletion pro-
cedures are executed. When these procedures are executed, the following cases
are distinguished:
– If the deleted radio link was the last one for the specific UE, the RNC initiates a
forced RRC Connection Reestablishment procedure. Upon reception of the cell
update information with the cause set to “Radio Link Failure Or RLC Unrecovera-
ble Error“, new radio resources are set up on a forward access channel (FACH).
109
– Otherwise, if further radio links are still active for the specific UE, the RNC issues
channel-type switching (CTS) from the HS-DSCH to a DCH.
Upon reception of an RSI indicating “HS-DSCH resource information: operational
state = enabled“, the controlling RNC (CRNC) takes the following measures:
• Setting the state attribute of the MOC HSDPA to enabled
• Informing the OMC about the reactivated status of the MOC HSDPA including the
MOC’s availability status
Tab. 4.8 provides an overview of the states supported by the HSDPA channel HS-
DSCH) and the corresponding trigger events.
HS-DSCH state/status Trigger event(s) for the relevant state combination
OST AVS
disabled offline This is the initial state combination. Furthermore, this

state combination is set in the event of one of the fol-
lowing:
- Creation of HS-DSCH object
- Deactivation of related UTRAN cell object
disabled not installed The local UTRAN cell is not available.
enabled empty set This state combination is set in the event of one of the
following:
- Completion of Physical Shared Channel Reconfigura-
tion Request (PSCRR) procedure for HS-DSCH es-
tablishment
- Reception of RSI with cause “HSDPA available“
- Reception of audit message with cause “HSDPA
available“
disabled dependency The AVS of the related cell is failed.
disabled failed This state combination is set in the event of one of the
following:
- Occurrence of a failure in the PSCRR procedure for
HS-DSCH establishment
- Reception of RSI with cause “HSDPA unavailable“
- Reception of audit message with cause “HSDPA un-
available“
- Completion of the PSCRR (code = 0) procedure for
HS-DSCH deletion triggered by non-HSDPA power
measurement failure
Tab. 4.8 Possible states of the HS-DSCH (HSDPA channel)
Furthermore, a dependency exists between the state of the HSDPA channel and the as-
sociated UTRAN cell. The state relations between these two objects are shown in
Tab. 4.9.
110
OST/AVS Trigger event(s) for the respective state
combination(s)
Cell state/status HS-DSCH
state/status
enabled/ enabled/ Both the UTRAN cell and the HS-DSCH are
empty set empty set available.
disabled/ disabled/ The HS-DSCH depends on the UTRAN
failed dependency cell’s availability. The UTRAN cell, in turn, is
faulty.
Note that under normal circumstances, this
state combination will not occur.
enabled/ disabled/ The UTRAN cell is available, whereas a fault
degraded failed occurred on the HS-DSCH. The HS-DSCH’s
failure impacts on the cell’s state.
enabled/ enabled/ The cause which led to the cell’s degrada-
degraded empty set tion does not impact on the HS-DSCH’s
state.
disabled/ disabled/ The cell is not available or removed and the
offline offline HS-DSCH’s state depends on the cell’s
state! Possible trigger events are:
- Local cell not activated
- Local deactivated after previous activation
disabled/ disabled/ The HS-DSCH’s state depends on the cell’s
not installed not installed state! Possible trigger events are:
- Local cell not available
- Local cell removed
- Interface failure on Iub interface
enabled/ disabled/ This state combination may only occur in the
empty set offline following situation:
The RNC optional feature handling indicated
the support of HSDPA (swp = “true”) and
creating the HSDPA objects was accepted.
At cell activation, however, the HSDPA sup-
port has been withdrawn (swp = “false”).
Tab. 4.9 Dependencies between cell states and HS-DSCH states
4.1.4.2 Common Measurements

The HSDPA feature requires the introduction of new common measurements whose in-
tention is to measure the transmitted carrier power of all codes not used for the trans-
mission of HS-PDSCHs and HS-SCCHs. These measurements are called the “Non-
HSDPA Transmit Power” measurement. The “Non-HSDPA Transmit Power” measure-
ment includes both periodic and event-triggered measurements which are initiated inde-
pendently. The periodic and event-triggered measurements are used for admission
control and congestion control, respectively.
This new common measurement is set up instead of the “Transmitted Carrier Power”
measurement which was used in product releases prior to UMR5.0. The “Non-HSDPA
111
Transmit Power” measurement, however, applies the same characteristics as the previ-
ous “Transmitted Carrier Power” measurement.
4.1.4.3 Code and Power Allocation

In general, no generic assignment of a guaranteed minimum power for HSDPA via the
Iub interface exists. As applied for streaming services, however, a guaranteed bit rate
can be assigned to HSDPA services. The required power is thus reported to the RNC
via the “HS-DSCH Required Power Value” IE. This information element indicates the
minimum necessary power for a specific priority class to meet the guaranteed bit rate
for all the established HS-DSCH connections, belonging to this priority class. This im-
plementation complies with 3GPP TS 25.433, NBAP Specification, section 9.2.1.31Iba.
The HSDPA resources of a UTRAN cell are represented by a sequence of channeliza-
tion codes. The channelization codes’ spreading factors (SFs) for HS-PDSCHs and HS-
SCCHs are 16 and 128, respectively. All HS-PDSCH and HS-SCCH channelization
codes which one single UE can receive are subordinated to one single primary scram-
bling code. However, no restrictions exist regarding associated DCHs. In other words,
the corresponding signaling radio bearer (SRB) can be assigned to any secondary
scrambling code of the cell, whereas the HSDPA channels must be assigned to the
UTRAN cell’s primary scrambling code.
A UTRAN cell’s HSDPA resources are operator-configurable. In UMR5.0, one code tree
is used and the maximum number of four HS-SCCHs can be configured.
As a restriction, however, the maximum configuration, i.e. 15 HS-PDSCHs and 4 HS-
SCCHs, is not possible if the paging channel (PCH) is mapped onto a dedicated sec-
ondary common control physical channel (S-CCPCH) in conjunction with the current al-
location of the common channels. Mapping of the PCH onto an S-CCPCH is optional. If
the PCH-optional S-CCPCH is configured, the maximum number of HS-SCCHs
(SF = 128) is reduced to three. In this case, the associated channels for HSDPA users
and all other UEs in the UTRAN cell are assigned to a secondary scrambling code if this
code is configured.
Fig. 4.37 provides an overview of the mapping of transport channels to their corre-
sponding physical channels.
112
Transport Channels Physical Channels
Dedicated Channel (DCH) Dedicated Physical Data Channel (DPDCH)
Dedicated Physical Control Channel (DPCCH)
Random Access Channel (RACH) Physical Random Access Channel (PRACH)
Common Packet Channel (CPCH) Common Pilot Channel (CPICH)

Broadcast Channel (BCH) Primary Common Control
Physical Channel (P-CCPCH)
Secondary Common Control
Forward Access Channel (FACH)
Physical Channel (S-CCPCH)
Paging Channel (PCH) Standalone SRB for PCCH (on S-CCPCH)
optional
Synchronization Channel (SCH)
Downlink Shared Channel (DSCH) Acquisition Indicator Channel (AICH)
Paging Indicator Channel (PICH)
Highspeed Downlink Shared Highspeed Physical Downlink

Channel (HS-DSCH) Shared Channel (HS-PDSCH)
HS-DSCH-related Shared Control
Channel (HS-SCCH)
Dedicated Physical Control Channel (UL)
for HS-DSCH (HS-DPCCH)
Fig. 4.37 Mapping of transport channels to physical channels
The setup for common channels is not changed with UMR5.0. In other words, none of
them is moved to a secondary scrambling code. Therefore, after the setup of the UTRAN
cell, the following channelization codes are used below one spreading factor of 16:
• 1 channelization code of SF = 64
• 1 channelization code of SF = 128 (optional)
• 4 channelization codes of SF = 256
Fig. 4.38 outlines this information.
113
16 + 15 * HS-PDSCH 16 .... 16
16
32 32
64 64 64 64
128 128 128 128 128 128 128 128
256 256 256 256 256 256 256 256 256 256 256 256 256 256 256 256
X Available Code (SF = X) X Used Code (SF = X) X Unavailable Code (SF = X)
Fig. 4.38 Basic code allocation strategy (code tree)
NOTE
i Before starting the initial code allocation for the HS-PDSCH, the RNC confirms that the
HSDPA feature is enabled by verifying that the SWP “HSDPA” flag has been set to
“true” (swp = true). This check is only performed during the setup of the cell. If the cell
has already been active when the SWP “HSDPA” flag’s value is set to “true”, the change
will only take effect at the next cell setup procedure.
If the flag’s value is set to “false”, no HSDPA capability is provided. Therefore, the same
cell setup procedure as in previous product releases will be applied.
When initially allocating the starting number of HS-PDSCH codes and the codes which
are used for the HS-SCCH, the code with the smallest number is used in both cases.
This handling is in line with the radio resource management of previous releases.
After the setup of the UTRAN cell, the CRNC reserves all specified codes for the HS-
PDSCH and the HS-SCCH, using the code tree (see Fig. 4.38). Furthermore, the
CRNC marks the descendant and ascendant codes of the specified codes as unavaila-
ble. To make sure that none of the code tree’s codes is assigned to any user, reserving
and marking is done simultaneously with the assignment of the common channel chan-
nelization codes in the code tree.
Fig. 4.39 and Fig. 4.40 show the UMR5.0 cell setup sequence. In UMR5.0, the cell set-
up procedure has been modified in comparison to the product release prior to UMR5.0.
114
0
Node B RNC
- NBAP cell setup

Cell setup - SysInfoUpdate SIB1,
2, 3, 11
Physical shared channel If the TPSCR expires
reconfiguration request
without any positive or
negative response, the
alt PSCR request will be
Physical shared channel 1
repeated a predefined
reconfiguration response number (N) of times. If
the N retries expire, the
HSDPA operational state = enabled
NBAP cell deletion will
be started.
par 2
Common transport channel setup As in UMR4.0, including
SIB5 and SIB7
2
Common measurements setup for RTWP
Common measurement
initiation request (cell, non-
HSDPA power, periodic)
alt Common measurement 3

initiation response (cell, non- A failure in the setup of
HSDPA power, periodic) an event-triggered
measurement does not
Common measurement have any impact on the
initiation request (cell, non- further procedure.
HSDPA power, event-triggered) Congestion control will
3
then rely on periodic
par 4 measurements
Common measurement
initiation failure (non-HSDPA
power, periodic, cause IE)
4
opt Resource status indication (RSI) 5
The RSI can be
“HS-DSCH resource information received or not
operational state: disabled” 5
4
Physical shared channel
reconfiguration request If the TPSCR expires
(number of both PDSCH without any positive or
and SCCH codes = 0) negative response, the
PSCR request will be
alt Physical shared channel 4 repeated for N times. If
reconfiguration response the N retries expire, the
NBAP cell deletion will
HSDPA operational state = disabled be started.
Periodic and event-

Common measurements setup for transmitted carrier power
triggered as in UMR4.0
4
Fig. 4.39 Setup of the HS-DSCH (part 1)
115
Node B RNC
Periodic and event-

Common measurements setup for transmitted carrier power
4
reconfiguration failure
(cause IE)
HSDPA operational state = disabled
NBAP cell deletion

4
3
2
1

reconfiguration failure
(cause IE)
HSDPA operational state = disabled
par 2
Common transport channel setup
Common measurements setup for received total wideband power
Periodic and event-

Common measurements setup for transmitted-carrier power
2
1
NBAP cell deletion
Fig. 4.40 Setup of the HS-DSCH (part 2)
In contrast to the previous product release, all common channels and measurements
are no longer independent of each other. With UMR5.0, the “Non-HSDPA Power” meas-
urement can only be set up upon completion of the “Physical Shared Channel Recon-
figuration” (PSCR) procedure, i.e. when the HS-DSCH is set up. This is due to the fact
that both measurements must be configured on the same channel coding card (CHC) in
the Node B. This CHC must be the specific card on which the HS-DSCH has been set
up and is maintained.
116
After successful setup of the UTRAN cell, the HSDPA resources are set up by sending
the NBAP: PHYSICAL SHARED CHANNEL RECONFIGURATION message to the
Node B. This message provides the “HS-PDSCH-FDD-Code-Information” and “HS-
SCCH-FDD-Code-Information” optional parameters for the HS-PDSCH and HS-SCCH,
respectively. Furthermore, the TPSCR timer is started.
Upon reception of the NBAP: PHYSICAL SHARED CHANNEL RECONFIGURATION
message, the Node B parses this message, thus verifying the availability of all neces-
sary resources. If establishing the Node B’s HSDPA resources fails, however, the
Node B sends an NBAP: PHYSICAL SHARED CHANNEL RECONFIGURATION FAIL-
URE message with a cause corresponding to the failure type which occurred. Tab. 4.10
provides information about the mapping of failure types and cause values.
NOTE
i An NBAP: PHYSICAL SHARED CHANNEL RECONFIGURATION FAILURE message
impacts neither on the operational state of the UTRAN cell nor on already instantiated
common transport channels.
Failure type Cause value
The Node B does not support HSDPA. CauseRadioNetwork:

No HSDPA license is available at all. “Requested Configuration Not Supported”
The total available number of HSDPA CauseRadioNetwork:
licenses is not sufficient. “Number Of Downlink Codes Not Supported“
The total amount of internal Node B CauseRadioNetwork:
resources is not sufficient. “Node B Resources Unavailable”
Tab. 4.10 Mapping of failure types and cause values
If the RNC receives neither an NBAP: PHYSICAL SHARED CHANNEL RECONFIGU-

RATION FAILURE message nor an NBAP: PHYSICAL SHARED CHANNEL RECON-
FIGURATION RESPONSE message before the expiry of the TPSCR, the RNC repeats
the request a predefined number (N) of times. As a consequence, the Node B is capable
of receiving and processing subsequent NBAP: PHYSICAL SHARED CHANNEL
RECONFIGURATION messages of the same configuration. If these N repetitions ex-
pire, the cell deletion procedure is triggered.
Upon reception of an NBAP: PHYSICAL SHARED CHANNEL RECONFIGURATION
FAILURE message, the RNC takes the following measures:
• Setting the state attribute of the MOC HSDPA to disabled
• Informing the OMC about the failed setup, including the failure’s cause value. The
NBAP failure will trigger the corresponding alarm as a consequence.
• Releasing the configured HSDPA codes in the code tree and making them available
to DCH users.
• Setting up the “Transmitted Carrier Power” common measurements in the way they
were performed in the product release prior to UMR5.0.
Upon reception of an NBAP: PHYSICAL SHARED CHANNEL RECONFIGURATION
RESPONSE message indicating the successful setup of HSDPA resources, in contrast,
the RNC takes the following measures:
• Setting the state attribute of the MOC HSDPA to enabled
• Informing the OMC about the successful setup
117
• Initiating the “Non-HSDPA Transmit Power” measurement (see "Common Measure-
ments" on page 111)
If the setup of the periodic “Non-HSDPA Transmit Power” measurement succeeds, the
HS-DSCH setup procedure ends. Additionally, a failed setup of the event-triggered
“Non-HSDPA Transmit Power” measurement does not impact on the HSDPA setup in
the relevant UTRAN cell.
Otherwise, if the periodic “Non-HSDPA Transmit Power” measurement fails, the RNC
takes the following measures:
• Informing the OMC about the failed periodic “Non-HSDPA Transmit Power” meas-
urement. This triggers the corresponding alarm indicating the unsuccessful periodic
“Non-HSDPA Transmit Power” measurement.
• Deleting the configured HSDPA codes by means of the NBAP: PHYSICAL SHARED
CHANNEL RECONFIGURATION message. In this case, the number of codes as-
signed to PDSCHs or SCCHs is set to zero. Nevertheless, the operational state of
the UTRAN cell is not impacted for DCH users and the cell still operates in non-HSD-
PA mode. Therefore, a deactivation and a subsequent activation procedure must be
applied to the cell in order to put the UTRAN cell in HSDPA operating mode.
If deleting the configured HSDPA codes fails, however, the RNC deletes the UTRAN
cell.
• Setting the HSDPA MOC’s operational state to disabled and its availability status to
failed. Furthermore, the RNC informs the OMC about the change of states by
means of an alarm and a notification.
• Releasing the configured HSDPA codes in the RNC’s code tree. These codes are
made available to DCH users.
• Setting up the “Transmitted Carrier Power” measurement which has been used in
product releases prior to UMR5.0.
4.1.4.4 Modification and Deletion of HSDPA Resources

Both the dynamic reallocation and the modification or deletion of any HSDPA resource,
i.e. the codes for HS-PDSCH and HS-SCCH, are only allowed if the operational state of
the relevant UTRAN cell is set to disabled. The cell must therefore first be deactivated
before modifying or deleting it. In addition to removing the cell plus the corresponding
common and dedicated channels, the Node B also has to release the existing AAL2
(ATM adaptation layer 2) connections to the MAC-d flow, the signaling radio bearers
(SRBs), and the uplink DCH of the HSDPA UEs. This is done by initiating an ALCAP
release to the RNC.
As soon as the cell is in the operational state disabled, the operator can modify the
HSDPA-related parameters or delete the MOC HSDPA to prevent HSDPA initialization
at the next cell activation. For details, refer to "Operating the Feature" on page 123.
When removing the UTRAN cell from the active set, thus deleting all existing common,
dedicated, and physical shared channels, an NBAP: PHYSICAL SHARED CHANNEL
RECONFIGURATION message requesting the deletion of HSDPA resources is obso-
lete and therefore not sent. Furthermore, hanging HSDPA resources cannot exist when
the UTRAN cell is removed for the same reason that this message is not sent.
NOTE
i In an HSDPA-capable cell, the HSDPA feature may be disabled and then reenabled
again. When disabling HSDPA, all HSDPA-related radio bearers must be released in
advance!
118
This chapter describes the functional split of mobility topics with respect to HSDPA. The
following items are covered:
• HSDPA RAB Handling
• HSDPA Mobility Handling
• HSDPA Admission Control and Congestion Control
• HSDPA Code and Power Allocation and Redimensioning

Not applicable.

Not applicable.

Admission and congestion control handling is implemented in the CRNC. Additionally,
admission and congestion control may impact on the SRNC with regard to the interfaces
between the SRNC and the CRNC.
In the Node B, the admission control algorithm is implemented in the core controller. The
algorithm is therefore modified such that the core controller uses the non-HSDPA power
instead of the transmitted carrier power.
The new HSDPA-related parameters impact on the LMT-RNC.

Not applicable.
119
The introduction of HSDPA in UMR5.0 requires new parameters to configure the sys-
tem’s mobility part with respect to the following:
• HSDPA RAB Handling
• HSDPA Mobility Handling
• HSDPA Admission Control and Congestion Control
• HSDPA Code and Power Allocation and Redimensioning

An additional parameter has been added to the “Radio Bearer Control” object for con-
trolling channel-type switching from HS-DSCH to FACH, see Tab. 4.11.
Name LMT-Name Range Default Description/Remarks

Value
Timer for the switch thsdsch_fach 0 .. 65535 s 30 s Period of uplink and downlink inactivity before
from HS-DSCH to the PS I/B RAB is switched from HS-DSCH to
FACH FACH0 means that inactivity is not monitored
and the connection is not switched to FACH
Tab. 4.11 New parameter for the “Radio Bearer Control” object
A new parameter, see Tab. 4.12, has been added to the “High Speed Downlink Packet
Access Channel” object (MOC HSDPA) introduced in "HSDPA Code and Power Alloca-
tion and Redimensioning" on page 108.

Value
HS-DSCH Power po_dsch -6 ..13 dB 3 dB Default Power offset between HS-PDSCH and
Offset step 0.5 P-CPICH/S-CPICH.
Note: This parameter must be set to the same
value for all cells within the same Node B.
Tab. 4.12 New parameter for the “High Speed Downlink Packet Access Channel” object
Tab. 4.13 shows the parameters related to HSDPA measurement information. Multiple
instances are supported per RNC [0 .. 12].

Value
UE HS-DSCH Phys- ue_cate 1 ..64 - UE category for HSDPA, part of UE capabili-

ical Layer Category ties.
CQI Feedback cqi_cyclek 0, 2, 4, 8, 10, 4 ms Period of repetition of a CQI measurement re-
Cycle k 20, 40, 80, port
160 ms
CQI Repetition Fac- cqi_rep 1 .. 4 1 Number of repetitions of a CQI report. Not nec-
tor essary if CQI Feedback Cycle k = 0.
Tab. 4.13 Parameters for the “HSDPA measurement information” object
120
Value
ACK-NACK Repeti- ack_nack_rep 1 .. 4 1 Number of repetitions of ACK/NACK reports

tion Factor
CQI Power Offset cqi_po 0 .. 8 5 Power offset used in the UL between the HS-
DPCCH slots carrying CQI information and the
associated DPCCH
ACK Power Offset ack_po 0 .. 8 5 Power offset used in the UL between the HS-
DPCCH slot carrying HARQ ACK information
and the associated DPCCH
NACK Power Offset nack_po 0 .. 8 5 Power offset used in the UL between the HS-
DPCCH slot carrying HARQ NACK information
and the associated DPCCH
HS-SCCH Power hsscch_po -32 .. +31.75 0 dB Power offset of HS-SCCH relative to the pilot
Offset dB bits on the DL DPCCH
Tab. 4.13 Parameters for the “HSDPA measurement information” object

The order of the reported cells included in the “Cell Measured Results” IE for event 1A,
1B, 1C, or if configured, 1A’ does not take into account any hysteresis. This means that
the order of the reported cells is changed even if the difference in quality of each cell is
extremely small, for example 0.1 dB.The “Cell change/CTS threshold” parameter is
used to avoid frequent change of the serving HS-DSCH cell or channel-type switching
between HS-DSCH and DCH triggered by event 1A, 1B, 1C or, if configured, 1A’.

Value
Hysteresis hyst1d 0 .. 7.5 dB 2 dB Determines the hysteresis value

by step of 0.5
Time to trigger tmtrg1d 0, 10, 20, 40, 640 ms Indicates the period of time between the timing
60, 80, 100, of event detection and the timing of sending the
120, 160, measurement report.
200, 240,
320, 640,
1280, 2560,
5000 ms
Tab. 4.14 Parameter for event 1D
The “Hysteresis” IE is used to avoid frequent measurement reports of event 1D. There-
fore, frequent change of the serving HS-DSCH cell or channel-type switching between
HS-DSCH and DCH can be avoided as well.
121
HSDPA admission control and congestion control requires modifications of the following
MMI-related issues:
• Parameters configurable at the LMT-RNC
• Performance measurement counters
Parameters configurable at the LMT-RNC

The LMT-RNC parameter which is listed in Tab. 4.15 has been modified with respect to
HSDPA admission control.
Name LMT-Name Range Default Description

value
Reporting period for mmti_tcp 0.01, 0.02 .. 10 Reporting period for admission control
transmitted carrier 60, 120, 180 This parameter indicates the interval in which
power .. 3600 s periodic reports of either the non-HSDPA
transmitted carrier power (if the cell is HSDPA-
capable) or the transmitted carrier power (if the
cell does not provide HSDPA service) is is-
sued.
Tab. 4.15 Admission control parameter at the LMT-RNC modified due to HSDPA
In addition, Tab. 4.16 lists the two new cell-specific parameters which are configurable
by the operator at the OMC-R to handle HSDPA admission control.

value
Minimum SF availa- minsf_hsdpa 8, 16, 32 8 The minimum SF available in a specific HSD-

ble for PS interac- PA cell for the PS interactive/background RAB
tive/background on if at least the predefined number (X) of UEs
DCH in HSDPA cell transmit on the HSDPA channel.
NOTE:
A similar parameter (“Minimum SF available“)
already exists. This parameter is still used be-
cause admission control determines the maxi-
mum of both parameters if the HSDPA
condition applies. Please refer to "Restriction
Control in the CRNC for HSDPA" on page 104.
Threshold for acti- actrc_hsdpa 0 .. 256 UEs 0 If the current number of UEs on the HSDPA
vating rate restric- channel exceeds this value in the relevant
tion for PS HSDPA cell, the CRNC will apply rate restric-
interactive/back- tion for the PS interactive/background RAB on
ground on DCH in the DPCH in this cell.
HSDPA cell If this parameter’s value is set to “0”, one HSD-
PA-capable UE on the HSDPA channel suffic-
es to start the rate restriction.
Tab. 4.16 New HSDPA admission control parameters at the LMT-RNC
122
Performance measurement counters
New counters are introduced with this release to measure the following performance in-
dicators. All counters are available per UTRAN cell:
• Number of HSDPA establishment attempts per cell
• Number of HSDPA establishment rejections per cell
• Number of successful HSDPA establishment outcomes per cell
A detailed description of new performance measurement counters is available in "HSD-
PA Performance Measurement Counters" on page 155.

Each UTRAN cell can have the new “High Speed Downlink Packet Access Channel” ob-
ject (MOC HSDPA). Multiple instances (0...1) of this object are supported per UTRAN
cell. Tab. 4.17 provides a list of those attributes featured by the MOC HSDPA with re-
spect to code and power allocation and redimensioning.

value
Number of HS-PD- no_pdsch 1 .. 15 - Available number of channelization codes for

SCH codes the HS-PDSCH
NrOfHSSCCHs no_scch 1 .. 4 - Available number of HS-SCCHs
Tab. 4.17 MOC HSDPA attributes for code and power allocation and redimensioning

Not yet applicable.
123
5 Modifications within UTRAN Operation and
Maintenance
Introducing the HSDPA feature with UMR5.0 requires modifications within the UTRAN
operation and maintenance (OAM). This chapter provides information of the RNC’s and
the Node B’s configuration management, state management, and fault management.
Furthermore, modifications to the Man-Machine Interface, i.e. the Radio Commander
(RC), the operation and maintenance tool set (OTS), and the LMTs for the RNC and the
Node B are described.

With regard to UTRAN operation and maintenance, the functional descriptions are sub-
sequently provided for
• "RNC" on page 124 and
• "Node B" on page 130
5.1.1 RNC
With respect to the HSDPA-capable RNC, this section describes the OAM modifications
in terms of:
• Equipment Management
• Transport Network Layer Management
• Radio Network Layer Management
• Optional Feature Handling Within the RNC
5.1.1.1 Equipment Management

To support HSDPA, the RNC requires new/modified hardware (HW) to be installed.
However, only model units with either eRNC configuration or mixed cRNC/eRNC con-
figuration are allowed for an upgrade to HSDPA. As a precondition for this upgrade,
model units affected must be equipped with CMP (composite/decomposite) or WCMP
(wideband CMP) cards. In general, all model units intended for HSDPA capability need
a firmware (FW) upgrade of their CMUX cards in the A/B/C-PRM (packet radio module)
and of their WLSC cards in the B/C-LSM (line switch module). RNC model units
equipped with BLSC modules must be exchanged by WLSC modules.
The following new HW cards must be installed for HSDPA support:
• Highspeed Downlink Shared Channel Trunk (HSDST) card
The mounting position of the HSDST is the B/C-LSM where C-LSM is the rack type
if eRNC model units are used.
• Highspeed Packet Radio Link Controller (HSPRLC) card
The mounting position of the HSPRLC is the A/B/C-PRM where B-PRM and C-PRM
are the rack types if eRNC model units are used.
The two new HW cards operate in single redundancy mode. Both HSDST and HSPRLC
are capable of plug&play operation. With regard to remote inventory management, both
new cards represent ob-RIU objects. Their inventory data is added to the existing inven-
tory data file (IDF).
124
Impacts on the RNC back end
On the RNC back end (RNC-BE) side, new HMI commands are introduced to configure
the HSDST and HSPRLC cards or components related to the radio network layer. Fur-
thermore, new HSDPA-specific parameters are added to existing commands.
Upon creation, modification, or deletion of an HSDPA-specific item at the LMT-RNC, the
RNC-BE sends a configuration change notification to the RNC-FE and increases the
configuration counter. The RNC-BE furthermore inserts an entry in the alignemnt file.
Impacts on the RNC front end

With full RC support of the HSDPA feature in UMR5.0, the information model of the RNC
front end has been adapted in such a way that all HSDPA-related commands and ob-
jects are available and can be configured.
As regards operation of HSDPA, the same tasks can be performed at the RC as at the
LMT-RNC.
State management
Tab. 5.1 provides the X.731-compliant states by which the new equipment is managed:
RNC-BE state RNC-FE state
AST OST AVS PRS SBS
ins unlocked enabled not applicable not applicable not applicable

ous locked disabled not applicable not applicable not applicable
flt unlocked disabled failed not applicable not applicable
lckft locked disabled failed not applicable not applicable
dgt_ous locked disabled in test not applicable not applicable
lckdgft locked disabled failed, in test not applicable not applicable
dwlod locked disabled not applicable initializing not applicable
dlfe locked disabled failed initializing not applicable
Tab. 5.1 State management for new RNC hardware cards
Fault management
With respect to the fault management of the new HSDST card, the following new HMI
output messages are introduced with UMR5.0:
• 0053299 hsdps_fault
The RNC-BE uses this alarm to notify the RNC-FE about the occurrence of a failure
in an HSDST card. The alarm will be cleared as soon as the cause for the fault is
removed and the equipment is in ins state. This is achieved by the following:
– The defective card is replaced.
– The result of the command diagnosis is OK.
– The equipment is reset by means of the corresponding command.
– Plug&play applies when the card is reinserted into the relevant module.
– A lock and unlock operation is successfully performed.
• 0053300 hsdps_fault_recovery
The cause for the fault which led to the 0053299 hsdps_fault alarm is removed and
the equipment is in ins state.
125
As regards the HSPRLC’s fault management, the existing alarms 0053268 cmuxbl_fault
and 0053269 cmuxbl_fault_recovery are modified with respect to the new card. The
0053268 cmuxbl_fault and 0053269 cmuxbl_fault_recovery alarms indicate the occur-
rence of a failure in the equipment subordinated to the CMUX and the failure’s recovery,
respectively.
In addition to these output messages, the following two existing HMI alarms are en-
hanced with information about HSPRLCs and HSDSTs. These alarms are applicable for
any trunk card in the RNC:
• 1348012 trunk_card_congestion_occurred
If the percentage of congestion for one specific card of an equipment group exceeds
the preset threshold value, the RNC-BE will inform the RNC-FE about the conges-
tion.
• 1348013 trunk_card_congestion_recovered
If the specific card’s percentage of congestion falls below the threshold value, this
alarm will be output, indicating that the congestion is over and thus clearing the
1348012 trunk_card_congestion_occurred alarm.
5.1.1.2 Transport Network Layer Management

On the Iub interface, the HSDPA traffic is shared with traffic on dedicated channels
(DCHs) on the same virtual channel (VC). This VC is configured for AAL2 (ATM adap-
tation layer 2) user traffic. Iub HSDPA traffic is possible both via E1/J1/T1 IMA groups
and via STM-1/OC-3 lines. No additional VC needs to be configured in the RNC; how-
ever, bandwidth requirements and the required number of available CIDs (call identifiers
inside AAL2 VCs) call for the creation of additional AAL2 VCs.
On the Iu interface, the HSDPA traffic is routed via the existing AAL5 (ATM adaptation
layer 5) packet-oriented traffic. Thus, like on the Iub interface, no additional VC needs
to be configured.
For proper use of the new HW cards, i.e. HSDST and HSPRLC, the HMI Trunk Equip-
ment Control command (atrk) is enhanced. In addition to existing parameters, both the
HMI blk/ublk atrk command and the view atrk command now contain the new HW cards’
identification numbers in order to block/unblock the trunk equipment and display its
state, respectively. Furthermore, the response messages of the view atrk command are
enhanced. Information is added both about the mapping between GMUX and HSPRLC
equipment and for displaying the new HW cards’ used bandwidth. The necessary infor-
mation about the HSDST and HSPRLC cards is added to the following HMI output mes-
sages:
• 1348004 card_block_complete
• 1348005 card_unblock_complete
• 1348006 trunk_card_to_be_blocked
5.1.1.3 Radio Network Layer Management

For HSDPA, additional parameters are introduced. These parameters impact on:
• Power and code settings for HSDPA channels
• Admission control
• Radio bearer (RB) control
• Measurement control for mobility handling
• HSDPA measurement with RNC-wide scope
126
The first two items refer to cells. All new attributes are embedded in one new MOC rep-
resenting the HSDPA channel (HS-DSCH) which is subordinated to the “UTRANCell”
MOC. The instantiation of the new MOC is optional. This MOC exists only if the cell pro-
vides HSDPA service.
Measurement control and radio bearer control are RNC-related attributes. The relevant
data is added to the existing MOCs affected and must be configured even if HSDPA is
not supported by the RNC.
Attributes related to HSDPA measurements with an RNC-wide scope are embedded in
a new MOC called “HSDPA Measurement Information”. As for the new HSDPA-channel-
related MOC, instantiation of this MOC is optional and exists only if the HSDPA feature
is supported.
If the operator wants to use HSDPA in a cell, the following steps have to be performed
in the given order:
1. Creation of the cell
2. Creation of the highspeed downlink shared channel (HS-DSCH) in a cell
3. Modification of OAM parameters via RC/LMT
4. Setup of the HS-DSCH in Node B
A detailed guideline description about HSDPA setup in a UTRAN cell is provided in the
section "Operating the Feature" on page 123.
State management
The state management of the HSDPA channel MOC which represents the HS-DSCH is
similar to that of common transport channels.
Upon creation of the MOC in the RNC, the initial combination of OST/AVS is set to dis-
abled/offline. Otherwise, if the HS-DSCH is set up in the Node B by means of the
NBAP: Physical Shared Channel Reconfiguration procedure, the MOC’s OST/AVS
combination will be enabled/empty_set. After the HSDPA setup in the Node B, the
Node B issues a resource status indication (RSI) message to the RNC.
Further details are described in the section "State Management" on page 108 in the
chapter HSDPA Code and Power Allocation and Redimensioning.
All HS-DSCH-related state/status values are compliant to ITU-T X.731.
Fault management
Whenever the Node B rejects the NBAP: PHYSICAL SHARED CHANNEL RECONFIG-
URATION REQUEST message during HS-DSCH creation or setup of the non-HSDPA
power measurement is not possible, an alarm is output by the RNC to the LMT/RC.
Therefore, a new message type is defined for the existing RNC back end alarm 1329100
nbap_failure. Furthermore, an alarm of severity “major” is newly created, indicating that
the HS-DSCH channel has failed in the Node B.
Tab. 5.2 lists the possible state transitions and the generated or cleared alarms at the
RNC front end during normal operation.
127
Previous OST/AVS Current OST/AVS RNC-FE alarm Remark
MOC Alarm content
- disabled/offline Cell No alarm Upon creation of the cell/HS-

DSCH, the OST/AVS values
are set to the initial values.
disabled/offline disabled/not installed Cell 66537 - ranLocal- Either the local cell is not an-
CellNotAvailable nounced or the interface to
the Node B is interrupted.
disabled/not installed disabled/offline Cell Local cell available The cell alarm is cleared.
disabled/offline disabled/failed Cell 66536 - ranCell- Cell activation failed.
NotOperational
disabled/failed disabled/offline Cell No alarm Operator action; therefore, no
alarm is output.
disabled/failed enabled/empty_set Cell Cell operable The existing alarm is cleared.
enabled/empty_set disabled/offline Cell No alarm Operator action; therefore, no
alarm is output.
enabled/empty_set disabled/failed Cell 66536 - ranCell- A cell failure occurred.
NotOperational
enabled/empty_set enabled/degraded Cell No alarm This transition is only possi-
ble if the HS-DSCH fails.
Thus, an HS-DSCH alarm ex-
ists.
- disabled/offline HS-DSCH No alarm Upon creation of the HS-
DSCH, the OST/AVS values
are set to the initial values.
disabled/offline disabled/not installed HS-DSCH No alarm The HS-DSCH’s state de-
pends on the cell’s state/sta-
tus. Therefore, a cell alarm is
sufficient.
disabled/not installed disabled/offline HS-DSCH No alarm The HS-DSCH’s state de-
pends on the cell’s state/sta-
tus. Therefore, a cell alarm is
sufficient.
disabled/offline disabled/failed HS-DSCH HS-DSCH inopera- This alarm is output if the HS-
ble DSCH setup in the Node B
fails.
disabled/failed disabled/offline HS-DSCH No alarm Operator action; therefore, no
alarm is output.
disabled/failed enabled/empty_set HS-DSCH HS-DSCH opera- The existing alarm is cleared.
ble
enabled/empty_set disabled/offline HS-DSCH No alarm Operator action; therefore, no
alarm is output.
Tab. 5.2 State transitions and generated alarms during normal operation (RNC-FE)
128
Previous OST/AVS Current OST/AVS RNC-FE alarm Remark
MOC Alarm content

enabled/empty_set disabled/failed HS-DSCH HS-DSCH inopera- An HS-DSCH failure oc-
ble curred.
enabled/empty_set disabled/dependency HS-DSCH No alarm This transition is only possi-
ble if the cell fails. Thus a cell
alarm already exists.
disabled/dependency disabled/offline HS-DSCH No alarm
disabled/dependency enabled/empty_set HS-DSCH No alarm The cell changes from disa-
bled/failed to enabled/
empty_set. Therefore, the
cell alarm is cleared.
Tab. 5.2 State transitions and generated alarms during normal operation (RNC-FE)
Tab. 5.3, on the other hand, provides the possible states and generated alarms after
state alignment.
OST/AVS RNC-FE alarm Remark
MOC Alarm content
disabled/offline Cell No alarm

disabled/not installed Cell 66537 - ranLocalCellNotAvail-
able
disabled/failed Cell 66536 - ranCellNotOperational The cell had reported inoperability
before.
enabled/empty_set Cell No alarm This is the default state.
disabled/offline HS-DSCH No alarm
disabled/not installed HS-DSCH No alarm
disabled/failed HS-DSCH HS-DSCH inoperable The HS-DSCH had reported inop-
erability before.
enabled/empty_set HS-DSCH No alarm This is the default state.
disabled/dependency HS-DSCH No alarm This state/status combination de-
pends on a cell failure where a cell
alarm exists.
Tab. 5.3 States and generated alarms after state alignment
5.1.1.4 Optional Feature Handling Within the RNC

With respect to HSDPA, two prerequisites exist for operating the HSDPA feature in the
RNC: the new HW cards and an additional HSDPA-related SW flag which enables or
disables the support of HSDPA from the SW’s point of view. This ’HSDPA’ flag, howev-
er, can only be switched (from ’HSDPA disabled’ to ’HSDPA enabled’ and vice versa)
by Siemens AG/NEC service staff.
129
The creation of any item related to HSDPA is rejected as long as the ’HSDPA’ flag is
disabled. Configuring HSDPA-related attributes which are added to existing MOCs,
however, will be accepted but ignored.
After having successfully created the HSDPA-related MOCs but disabled the HSDPA
feature later on, the configured states will be kept. The RNC therefore checks the
’HSDPA’ flag with cell activation to confirm whether or not HSDPA service is provided
for the cell. If the flag indicates that HSDPA is not supported, the setup of HSDPA in the
Node B will be skipped. When activating a cell in a Node B, it must be kept in mind that
HSDPA operation is only possible on one carrier frequency per Node B and that only
symmetrical HSDPA configurations in all radio cells on the same carrier frequency are
allowed in UMR5.0.
Furthermore, the download procedure will fail if HSDPA-related MOCs are included in
this procedure.
5.1.2 Node B
With respect to the HSDPA-capable Node B, this section describes the OAM modifica-
tions in terms of:
• Equipment Management
• Transport Network Layer Management
• Radio Network Layer Management
• Optional Feature Handling Within the Node B
5.1.2.1 Equipment Management

If the Node B is supposed to support HSDPA, an HSDPA-capable channel coding card
(CHC) must be installed. The following two options exist:
• Reuse/installation of the CHC96 with a SW load updated for HSDPA
• Installation of the new hs-CHC
Although both types of CHCs can coexist within one Node B, it must be mentioned that
HSDPA traffic can be processed by either the CHC96 or the hs-CHC exclusively as soon
as both types are installed. As regards Node B’s remote inventory management, the
new hs-CHC represents an ob-RIU object.
The Node B’s initial trigger to set up HSDPA operation is the configuration of the ’local-
CellE’ managed object instances (MOIs) in the database, thus either enabling or disa-
bling HSDPA for a particular UTRAN cell. At system start-up, the Node B then evaluates
each instance’s current configuration and triggers the setup of an HSDPA-capable CHC
in HSDPA mode according to the rules listed below. This implementation avoids time-
consuming and complex reconfiguration of CHCs because the Node B already knows
at start-up time how many cells support HSDPA and no HSDPA-related or Rel 99 traffic
must be shifted to other CHCs.
1. The Node B always sets up an hs-CHC in HSDPA mode if such a type of card is in-
stalled.
2. If neither a hs-CHC is installed nor any of the installed hs-CHCs is equipped with a
HSDPA high-capacity license and if a HSDPA-capable CHC96 is installed, the
Node B sets up the CHC96 in HSDPA mode.
3. Otherwise, if neither an hs-CHC nor an HSDPA-capable CHC96 is installed, the
Node B will reject any HSDPA setup request by means of an NBAP: PHYSICAL
130
SHARED CHANNEL RECONFIGURATION FAILURE message containing the ap-
propriate probable cause information.
NOTE
i The number of HSDPA-capable CHCs in HSDPA mode the Node B sets up is equal to
the number of ’localCellE’ MOIs with HSDPA support enabled.
Only at start-up time and at the first installation of an HSDPA-capable CHC, the Node B
determines the type of CHC to be used for HSDPA operation. The CHC type selected
for HSDPA processing is then kept until the next restart of the Node B.
Furthermore, the Node B checks whether the number of codes signaled in the NBAP:
PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST message is equal to
the number of codes being allocated to cells already configured in HSDPA mode. Here,
the principle of symmetrical distribution of codes to HSDPA cells must be observed.
However, if this condition is not observed, the Node B will reject the HSDPA setup by
means of an NBAP: PHYSICAL SHARED CHANNEL RECONFIGURATION FAILURE
message containing proper probable cause information. The distribution of HSDPA cells
on available HSDPA-capable CHCs is performed in a kind of round-robin manner, thus
resulting in HSDPA cells being evenly distributed on the appropriate CHCs. This func-
tionality is currently implemented for Rel 99 cells, as well. An example is provided in
table 3.2 on page 30.
Due to the new and changed HW for supporting HSDPA, the N2CH MOC representing
all CHCs has been adapted as follows:
• The existing attribute “chType” notifying the type of CHC being used has been ex-
tended by a new value which indicates the hs-CHC.
• A new attribute has been added to this MOC indicating the cell IDs of those HSDPA
cells served by the HSDPA-capable CHC.
State management
The following applies for an HSDPA-capable CHC’s state management with regard to
implementation-specific and logical OAM:
• Implementation-specific OAM
In general, the locking or shutting down of an HSDPA-capable CHC currently provid-
ing HSDPA service is only possible if no cell(s) will go down or be affected. In other
words, no common channel may reside on that CHC. As a consequence, a request
to lock or shut down a CHC operating in HSDPA mode is rejected as long as any
superior cell has not been deleted in advance. Cell deactivation, on the other hand,
requires all common channels to be removed from the relevant CHC in advance.
Upon acceptance of a request to lock or shut down the CHC, Rel 99 traffic running
on the affected HSDPA-capable CHC will be shifted to other CHCs as far as possible
according to the current implementation. HSDPA calls, however, will be lost because
no call context migration of HSDPA calls exists in UMR5.0.
• Logical OAM
In this context, the state management function treats the physical shared channel
which is used by HSDPA traffic in the same way as a dedicated channel for Rel 99
traffic. Although the physical shared channel is considered as a common resource
from 3GPP’s point of view, call context migration is not supported.
Fault management
If a failure occurs in an HSDPA-capable CHC, thus leading to a situation in which no
HSDPA-traffic processing is possible, the Node B issues an NBAP: Resource Status In-
131
dication (RSI) to the controlling RNC (CRNC). This RSI indicates the loss of the HSDPA
service for that specific HSDPA cell.
This RSI results in the HS-DSCH’s combination of operational state/availability status
(OST/AVS) being set to disabled/failed. The affected cell’s OST/AVS combination is
set to enabled/degraded. As a consequence, all HSDPA radio links will be dropped and
the RNC sends an NBAP radio link failure indication for each radio link.
5.1.2.2 Transport Network Layer Management

As previously mentioned, at the Iub interface HSDPA traffic is shared with DCH traffic
at the same VC used for AAL2 user traffic. Therefore, no changes are necessary within
the Node B.
On the pysical layer, the Node B supports HSDPA traffic both via E1/J1/T1 lines with
IMA and via STM-1/OC-3 lines.
5.1.2.3 Radio Network Layer Management

The Node B’s call processing functionality is extended for the support of HSDPA. Fur-
thermore, the functionality of the local UTRAN cell (“localCellE” MOC) is adapted to the
requirements of HSDPA. This allows an indication of whether HSDPA is supported or
not and of the applied modulation scheme. For details, see "Impacts on the LMT-
Node B" on page 141.
5.1.2.4 Optional Feature Handling Within the Node B

The HSDPA feature is subject to the general SW licensing policy of
Siemens AG/NEC Corporation which is valid for the Node B. In other words, the princi-
ple of “pay-as-you-grow” is applied.
The following two types of licenses are applied for the HSDPA feature in UMR5.0:
• HSDPA data throughput license
• HSDPA high-capacity license
HSDPA data throughput license

The HSDPA data throughput license specifies the peak data throughput of HSDPA traf-
fic which may be processed by one Node B. One license corresponds to a peak data
throughput of 2.4 Mbit/s per Node B. The total number of licenses (N) defines the total
peak data throughput peakDataThroughputNodeB as a multiple of 2.4 Mbit/s. In other
words, peakDataThroughputNodeB = N * 2.4 Mbit/s, where N is in the range from 1 to 6.
During operation, the Node B confirms that this peak data throughput is not exceeded.
Therefore, the Node B recalculates the possible peak data throughput depending on the
HSDPA configuration at each NBAP: Physical Shared Channel Reconfiguration proce-
dure. The calculation is performed according to the following algorithm:
A
peakDataThrough numberOf modulation
putNodeB
= ∑ Codes ( i )
•
Scheme ( i )
• 0.48 Mbit ⁄ s
i=1
132
where
• A
Indicates the number of configured ’LocalCellE’ objects in the Node B
• numberOfCodes(i)
Indicates the number codes in cell i which are allocated by the RNC during the
NBAP: Physical Shared Channel Reconfiguration procedure
• modulationScheme(i)
Specifies the modulation scheme (HSDPA configuration) applied in cell i. This fac-
tor’s values indicate the following:
– “0”: HSDPA processing in cell i is disabled
– “1”: HSDPA processing in cell i is enabled, using only QPSK
– “2“: HSDPA processing in cell i is enabled, using 16QAM and QPSK
If the calculated possible peak data throughput exceeds the licensed peak data through-
put, i.e. if peakDataThroughputNodeB > peakDataThroughputNodeB, the Node B will re-
ject the NBAP: Physical Shared Channel Reconfiguration procedure with the cause set
to “Not Enough User Plane Processing Resources“.
The update of an HSDPA data throughput license of a CC at runtime becomes effective
without a system restart. In the event of CC redundancy, the higher license value be-
comes effective after a license update of one of the CCs.
HSDPA high-capacity license

The HSDPA high-capacity license is only applicable to the new hs-CHC. The license de-
fines the number of HSDPA users per UTRAN cell which one hs-CHC supports. Com-
pared to a CHC96, which supports 24 HSDPA users at an uplink rate of 64 kbit/s, the
HSDPA high-capacity license allows the maximum number of HSDPA users per cell and
hs-CHC to be increased by 50%. In other words, the hs-CHC will then support
36 HSDPA users in the same scenario.
Without activating the HSDPA high-capacity license, however, the hs-CHC supports
only Rel 99 traffic, even if an HSDPA data throughput license is activated for the specific
hs-CHC.
133
The functional split for UTRAN OAM is not applicable. With regard to the RNC, the
Node B, HSDPA mobility, the transport network layer, the Uu interface, and the HSDPA
performance measurement counters, the relevant functional splits are described in the
corresponding chapters:
• Modifications in the RNC HW/SW Architecture
• Modifications in the Node B HW/SW Architecture
• HSDPA Mobility
• Transport Network Layer (TNL) Modifications
• Air Interface (Uu) Modifications
• HSDPA Performance Measurement Counters

NOTE
i The command lines, GUI windows, and MOC names provided below are only assump-
tions, as their syntax is subject to change.
Both the RC and the LMTs support the changes in the network elements’ (NEs) infor-
mation models and databases, i.e. of the RNC and the Node B. Thus, the new MOCs
including their attributes are displayed at the graphical user interfaces (GUIs); the new
or modified commands and parameters are supported by the command line interfaces
(CLIs).
Furthermore, the OAM tool set (OTS) is affected by the changes of the NEs’ information
models and databases for HSDPA compliancy.
5.3.1 Impacts on the RC GUI

With UMR5.0, the RC GUI displays the new MOCs Hsdps and Hprlc representing the
new RNC HW cards HSDST and HSPRLC, respectively.
The icons of the Hsdps MOC, on the one hand, are situated in the Atm Sum panel which
represents the LSM module. As already done for the MOCs Tifs, TifdSide, Wcmps, and
WcmpdSide in previous releases, the icons for the Hsdps MOC are shown in the graph-
ical area of the panel on the related slots within the background picture using dynamic
icon labels. The label of these icons is HSDPS. The Hsdps MOC provides the same at-
tributes, actions, and notifications as the Wcmps MOC already does. These attributes,
actions, and notifications are handled by the RC in the same way as in previous releas-
es.
The Hprlc MOC, on the other hand, is located in the PswcB Sum panel and in the PswcE
Sum panel representing the PRM(B), B-PRM and C-PRM modules. In the background
picture, the labels of all slots which can be used for the HSPRLC card are renamed into
PRLC/HSPRLC. The Hprlc MOC provides the same attributes, actions, and notifications
as the Wcmps MOC already does. These attributes, actions, and notifications are han-
dled by the RC the way it has been done in previous releases.
Furthermore, the new MOCs (HSDPA channel and HSDPA radio resource management
containing the HSDPA measurement information) of the RNC RAN part are displayed
on the RC GUI. The HSDPA-channel-related MOC subordinated to the UtranCell MOC
is displayed via a new entry in the “Cell SubObject” list. Only one instance of the
HSDPA-channel-related MOC can be created per HSDPA cell. The “Cell SubObject” list
134
therefore contains exactly one additional entry if the cell supports HSDPA. In contrast,
as regards the the HsRadioResMngmt MOC representing the HSDPA radio resource
management and subordinated to the RANFunction MOC, up to three instances can be
created. These instances are all situated in the RAN Sum panel, each displayed as a
separate icon. In the default sort order of this panel, the HsRadioResMngmt MOC is
sorted before the Adj RNC icons.
In addition to these new MOCs, new attributes for existing MOCs are introduced with
this release. In the RNC, both the sbs3gRadioBearerCtrl MOC and the
sbs3gIntraFreqHoCtrl MOC have been adapted. In the Node B, on the other hand, the
two MOCs N2Ch (see "Ch" on page 141) and N2LocalCellE (see "LocalCellE" on
page 142) have been modified.
The new and modified HSDPA-related performance measurement counters for the
Node B, which are described in the chapter "HSDPA Performance Measurement
Counters" on page 155, are furthermore supported by the RC.
5.3.2 Impacts on the LMT-RNC

This section provides information on new and modified CLI commands with respect to
the radio access network (RAN). These commands can be entered at the LMT-RNC
command line interface (CLI). The LMT-RNC provides functionality to configure HSDPA
data to UTRAN cells and to set HSDPA call control data on the RNC site, thus operating
the HSDPA feature in the whole system.
Furthermore, information about new and modified output messages is contained in this
section.
5.3.2.1 New CLI Commands

Tab. 5.4 provides an overview of the new RNC-BE CLI commands and their corre-
sponding operations.
HMI Operation Sub-item Description

command
hsdpa cre - Creates a new instance

del - Deletes an existing instance
mod - Modifies an existing instance
view - Displays the instance’s settings
view st Displays the state information of
an HSDPA channel instance
hsrrm cre - Creates a new instance
mod - Modifies an existing instance
view - Display’s the instance’s settings
hstci mod - Modifies an existing instance
view - Displays an instance’s settings
Tab. 5.4 New CLI commands
135
HMI Operation Sub-item Description
command
hsrc cre - Creates a new instance

view - Displays an instance’s settings
Tab. 5.4 New CLI commands
hsdpa
The new CLI hsdpa command has been introduced to set, modify, and control the pa-
rameters of the HSDPA channel (HS-DSCH). The HSDPA channel must be configured
for each cell in which the HSDPA feature is to be operated. Tab. 5.5 lists the parameters
of the HSDPA channel which can be controlled by the CLI hsdpa command.
Of course, all parameters are new.
Parameter name Default value Parameter description
cellid not applicable Cell identifier

nodebid not applicable Node B identifier
no_pdsch not applicable Number of HS-PDSCH channelization codes
no_scch not applicable Number of HS-SCCH channelization codes
po_dsch 6 HS-DSCH power offset
Tab. 5.5 Parameters for the hsdpa command
The related UTRAN cell must first be deactivated whenever the data of one channel is
to be changed by means of the cre, del, or mod operation. The view operation does not
only show the settings/data of the specific HSDPA channel but its state.
If a downlink common channel (DLCC; dlcc CLI command or Downlink Common Chan-
nel GUI window) with “ccho_type=0” or “ccho_type=1” exists, the combination of
“no_pdsch=15“ and “no_scch=4” is not allowed for the hsdpa CLI command.
With regard to configuration alignment, the relevant configuration data is included in the
configuration alignment file.
NOTE
i The HSDPA channel is subordinated to the associated UTRAN cell. Therefore, if the cell
is deleted, the HS-DSCH will automatically be deleted, too.
hsrrm
The new hsrrm CLI command controls the radio resource data for each UE category. In
UMR5.0, UE categories 1 to 6, 11, and 12 are supported.
The HSDPA radio resources must be configured whenever HSDPA is to be started. For
this reason, the hsrrm-related parameters as provided in Tab. 5.6 are introduced with
UMR5.0. All parameters are new.
136
ue_cate not applicable UE HS-DSCH physical layer category

Currently, only UE category types 1 to 6, 11,
and 12 are supported.
cqi_cyclek 4 Channel quality information (CQI) feedback
cycle k
cqi_rep 1 CQI repetition factor
ack_nack_rep 1 ACK-NACK repetition factor
cqi_po 5 CQI power offset
ack_po 3 ACK power offset
nack_po 3 NACK power offset
hsscch_po 3 HS-SCCH power offset
Tab. 5.6 Parameters for the hsrrm command
Upon creation of an instance’s data, the data which is managed by the hstci command
will automatically be created at the same time as the relevant default value(s). The same
applies for the deletion of an hsrrm instance’s data. In other words, when the hsrrm-re-
lated data is deleted, the hstci-related data will also be deleted simultaneously. This is
because the same key parameter is used for both the hsrrm and the hstci commands.
hstci
The new hstci CLI command controls the transport channel information for each UE cat-
egory. As stated above, the instances of this item are automatically created upon crea-
tion of an hsrrm item and the parameters are set to their default values. Usually these
values do not need to be changed. If a modification becomes necessary, however, the
mod operation can be issued. Tab. 5.7 lists the hstci-related parameters, which are all
new.
ue_cate not applicable UE HS-DSCH physical layer category

Currently, only UE category types 6, 11, and
12 are supported.
macws 16 MAC-hs window size
t1 50 T1 timer
dlrate_peak ue_cate = 6: Downlink peak CPS-SDU rate (Iub/Iur AAL2)
2,048,000 bit/s
ue_cate = 11:
936,000 bit/s
ue_cate = 12:
1,864,800 bit/s
Tab. 5.7 Parameters for the hstci command
137
dlrate_avg ue_cate = 6: Downlink average CPS-SDU rate (Iub/Iur

100,000 bit/s AAL2)
ue_cate = 11:
25,000 bit/s
ue_cate = 12:
50,000 bit/s
dlsize_peak 360 Downlink peak CPS-SDU size (Iub/Iur AAL2)
dlsize_avg 360 Downlink average CPS-SDU size (Iub/Iur
AAL2)
ulrate_peak 56 Uplink peak CPS-SDU rate (Iub/Iur AAL2)
ulrate_avg 0 Uplink average CPS-SDU rate (Iub/Iur AAL2)
ulsize_peak 56 Uplink peak CPS-SDU size (Iub/Iur AAL2)
ulsize_avg 56 Uplink average CPS-SDU size (Iub/Iur AAL2)
brate_peak ue_cate = 6: Downlink peak bit rate (HSPRLC)
2,048,000 bit/s
ue_cate = 11:
936,000 bit/s
ue_cate = 12:
1,864,800 bit/s
brate_avg ue_cate = 6: Downlink average bit rate (HSPRLC)
100,00 bit/s
ue_cate = 11:
25,000 bit/s
ue_cate = 12:
50,000 bit/s
brate_min 0 Downlink minimum bit rate (HSPRLC)
Tab. 5.7 Parameters for the hstci command
With regard to configuration alignment, the relevant configuration data is only included
in the “config_file_all” file if the all-alignment is performed by means of the view align dk
all command.
hsrc
The new hsrc command controls the RAB combination control data. Tab. 5.8 lists the
hsrc-related parameters, which are all new.
rab1 psib Radio access bearer #1

ul_rate1 64 kbit/s, Uplink rate for radio access bearer #1
384 kbit/s
Tab. 5.8 Parameters for the hsrc command
138
With regard to configuration alignment, the relevant configuration data is only included
in the “config_file_all” file if the all-alignment is performed by means of the view align dk
all command.
5.3.2.2 Modified CLI Commands

In addition to the new CLI commands, existing RNC-BE CLI commands have been mod-
ified in order to adapt their functionality to the requirements of the new HSDPA feature
as introduced in UMR5.0. The HSDPA feature impacts on the following RNC-BE com-
mands:
• ifmrms
• rbc
• dlcc
• cell adc
ifmrms
With the introduction of HSDPA in UMR5.0, the data for the measurement report of
event 1D is necessary. The ifmrms-related parameters have therefore been enhanced
by the two parameters in Tab. 5.9.
hyst1d 2 Hysteresis for event 1D

tmtrg1d 640 Time to trigger for event 1D
Tab. 5.9 New parameters for the ifmrms command
rbc
The timer for channel-type switching (CTS) from HS-DSCH to FACH has been added to
the rbc-related parameters. For details, see Tab. 5.10.
thsdsch_fach 30 Timer for the switch from HS-DSCH to FACH
Tab. 5.10 New parameters for the rbc command
dlcc
From the code allocation point of view, the dlcc command cannot specify either the
“ccho_type=0“ or “ccho_type=1” when the hsdpa command configures the allocated
number of HS-PDSCH channelization codes and the allocated number of HS-SCCH
channelization codes according to the following pattern:
• [Number of HS-PDSCH] = 15
• [Number of HS-SCCH] = 4
For this situation, therefore, a new error number has been defined for the dlcc command.
139
With regard to configuration alignment, this command is not influenced because no pa-
rameter is changed. The relevant configuration data is therefore included in the config-
uration alignment file.
cell adc
Due to the introduction of the HSDPA feature, the existing cell adc command has been
enhanced with parameters to supervise the UTRAN cell’s admission control for HSDPA
calls. Tab. 5.11 provides the relevant information.
minsf_hsdpa 8 Minimum available spreading factor for the

PS Interactive/Background RAB on a DCH in
an HSDPA cell
actrc_hsdp 0 Threshold to activate the rate restriction for
the PS Interactive/Background RAB on a
DCH in an HSDPA cell
Tab. 5.11 New parameters for the cell adc command
5.3.2.3 New Output Messages at the LMT-RNC

With respect to HSDPA, new RNC-BE outputs are introduced in UMR5.0. The following
messages are new with this release:
The RNC-BE uses this alarm to notify the RNC-FE about the occurrence of a failure
in an HSDST card. The alarm will be cleared as soon as the cause for the fault is
removed and the equipment is in ins state. This is achieved by the following:
– The defective card is replaced.
– The result of the command diagnosis is OK.
– The equipment is reset by means of the corresponding command.
– Plug&play is executed when the card is reinserted into the relevant module.
– A lock and unlock operation is successfully performed.
The cause for the fault which led to the 0053299 hsdps_fault alarm is removed and
the equipment is in ins state.
• 1329203 hsdpa_state_changed
This message indicates that the state of the HSDPA channel (HS-DSCH) has
changed.
5.3.2.4 Modified Output Messages at the LMT-RNC

With respect to the new HW equipment in the RNC and the HSDPA channel, existing
HMI alarms have been extended by parameters representing the two new cards or the
HSDPA channel. Tab. 5.12 lists the modified output messages in relation to the affected
MOCs:
140
HMI output message Affected MOC
Hsdps Hprlc Hsdpa
0053268 cmuxbl_fault X
0053269 cmuxbl_fault_recovery X
1152001 state_of_device_changed X X
1293001 ast_changed_notifcation X X
1329100 nbap_failure X
1348004 card_block_complete X X
1348005 card_unblock_complete X X
1348006 card_reserved_to_be_blocked X X
1348012 trunk_card_congestion_occurred X X
1348013 trunk_card_congestion_recovered X X
Tab. 5.12 Modified output messages at the LMT-RNC
5.3.3 Impacts on the LMT-Node B

With respect to HSDPA, modifications have been made to the following Node B-related
MOCs in UMR5.0:
• Ch
This MOC defines a channel coding card (CHC).
• LocalCellE
This functional MOC is a container for all hardware-managed objects (HMOs) re-
quired for a particular local cell.
NOTE
i The following attribute names are mere proposals but not yet fixed!
Ch
Tab. 5.13 lists the new and modified attributes related to the “Ch“ MOC. The operator
has read-only access to these attributes.
Attribute name Value range Attribute description
assignedHsdpa- not applicable This new attribute indicates the IDs of those
Cells UTRAN cells which are served by an HSDPA-
capable CHC.
Tab. 5.13 New and modified attributes related to the Ch object in the Node B
141
chType [0;2] This attribute specifies the type of CHC which
Granularity: 1 is used. The attribute’s values indicate the fol-
lowing:
- “0”: CHC48
- “1“: CHC96
- “2”: hs-CHC
The attribute value for the hs-CHC has been
added in UMR5.0.
Tab. 5.13 New and modified attributes related to the Ch object in the Node B
LocalCellE
Tab. 5.14 lists the new attributes related to the “LocalCellE“ MOC. These attributes can
be configured by the operator.
hsdpaSupport [0;1] This attribute enables HSDPA processing for

Granularity: 1 a specific UTRAN cell. The attribute’s values
indicate the following:
- “0”: HSDPA processing disabled
- “1”: HSDPA processing enabled
modulationScheme [0;1] This attribute specifies the modulation
Granularity: 1 scheme to be applied in a specific cell. This
parameter becomes relevant only if HSDPA
support has been enabled for this cell. The at-
tribute’s values indicate the following:
- “0”: QPSK is exclusively applied
- “1“: 16QAM and QPSK are applied
hsdpaScheduler- [0;1] This parameter specifies which type of sched-
Type Granularity: 1 uler is to be used in a given cell. The values in-
dicate the following:
- “0”: User-throughput-optimized scheduler
(Proportional Fair scheduler)
- “1“: Cell-throughput-optimized scheduler
(Maximum CIR scheduler)
Tab. 5.14 New attributes related to the LocalCellE object in the Node B
5.3.4 OAM Tool Set (OTS)

The HSDPA feature requires modifactions to the CM+ module of the OTS. The CM+
module comprises the south- and north-bound interfaces of the OTS and the OTS core.
5.3.4.1 Extensions for South-Bound Import Operations and OTS Core

Due to the changes in the information models of both the RNC and the Node B, the cor-
responding model of the OTS core is updated. In accordance with this update, the da-
tabase uploads (reverse engineering function) for both the RNC and the Node B must
be updated accordingly, too. The only additional functionality required for the newly in-
142
troduced classes is the ability to create, delete, and modify these classes by means of
the CM Editor.
As regards the Node B, the HSDPA-dependent changes in the information model have
already been implemented in the product release prior to UMR5.0.
5.3.4.2 Extensions for South-Bound Export Operations

The bulk generation of the RNC’s and the Node B’s databases is extended in order to
support the modifications within the relevant information models. Additionally, the delta
generator of the OTS is extended for supporting the following use cases:
• Creation, deletion, and modification of the “HSDPAChannel” class as a child class
of the “UtranCell”. The following order of actions has to be observed for creating or
modifying the “HSDPAChannel” class:
– Deactivation of the relevant cell
– Creation, deletion, or modification of the “HSDPAChannel” class
– Activation of the relevant cell
• Creation, deletion, and modification of the “HSDPA Measurement Information” class
as a child class of the “RANFunction“.
Furthermore the Node B’s bulk mode exclusively supports setting the HSDPA-support
flag and the modulation scheme of the “LocalCellE“ object. Managing the HSDPA-sup-
port flag, however, complicates the activation of HSDPA for the customer with respect
to OAM. The complication is caused by the following:
• The operation requires a restart of all affected Node Bs.
• The HSDPA feature must be enabled per cell on both the RNC and the Node B. The
configuration between these two network elements must therefore be kept consist-
ent.
It is unavoidable to accept this complication because the Node B’s hardware must know
the number of cells supporting HSDPA at startup. Threfore, the HSDPA-capable CHC
can perform a switch to HSDPA operation during its startup, thus avoiding the acitivation
of HSDPA at a later point in time upon reception of the channel reconfiguration request
from the RNC. This online reconfiguration of the HSDPA-capable CHC is very time-con-
suming. If a CHC96 is concerned, for example, Rel 99 calls must be allocated on other
cards before the switchover to HSDPA mode.
5.3.4.3 Consistency Checks

The OTS is extended by a consistency check confirming that the Node B’s CallProc
MOC uses only those frequency layers for which HSDPA capability is activated. When
using HSDPA, a Node B with a 1/1/1 configuration, for example, is not allowed to use
frequency layer 2.
Another check confirms that the configuration of HSDPA in the RNC and the Node B is
consistent. This consistency check indicates HSDPA channels created in the RNC for
UTRAN cells which do not support HSDPA (hsdpaSupport = 0). On the other hand, it is
permissible to have no HSDPA channels configured in UTRAN cells with HSDPA sup-
port (hsdpaSupport = 1).
Third, it is confirmed that the number of channelization codes used per HSDPA channel
is identical throughout the whole Node B. The principle of symmetric distribution of
channelization codes on all cells is thus kept.
143
The introduction of the HSDPA feature requires the following extensions for north-bound
interfaces in the OTS:
• The MCCM is extended by vendor-specific data containers for all attributes and
classes defined for the RNC and the Node B. The valid use cases for north-bound
interfaces are equivalent to those for the south-bound export operations mentioned
above.
NOTE
i Although the support of HSDPA and the applied modulation scheme have to
be configured in the Node B, this is not modeled at the MCCM interface.
• The RNPC interface is extended by a new class representing the HSDPA channel.
This class models the following attributes:
– Number-of-HS-PDSCH-codes
– MaxNrOfHSSCCHs

As regards both the RNC and the HSDPA-capable Node Bs, HSDPA configuration via
both LMT-Node B and RC is possible.
6 Transport Network Layer (TNL) Modifications

HSDPA provides for higher data throughput per UE and per cell. In comparison to Re-
lease 99, HSDPA
• allows user throughput of more than 384 kbit/s
• increases the maximum cell data throughput from 1 Mbit/s to a theoretical maximum
of 13.98 Mbit/s
Such increased data rates require either E1/J1/T1 IMA groups or STM-1/OC-3 lines for
the Iub interface. The maximum throughput is only achievable using STM-1/OC-3 lines.
Using IMA, the cell data throughput is limited to some 12 Mbit/s. On the Iub interface,
HSDPA data is carried through the same AAL2 user plane VCs as is conventional
Rel 99 traffic. On the Iu interface, HSDPA data uses the same AAL5 user plane VCs as
conventional user plane traffic. HSDPA is not supported over Iur.
HSDPA is used for interactive and background traffic classes. This traffic is expected to
exhibit pronounced bursts that might use an Iub interface to full capacity. A flow control
mechanism (see below) in combination with QoS differentiation is introduced to allow for
maximum Iub usage while at the same time providing that HSDPA traffic does not inter-
fere with Rel 99 traffic. In the event of congestion, HSDPA traffic is discarded first.
HSDPA is carried on the same ATM AAL2 VCs as is conventional traffic. Therefore, on
the transport network layer there are no configuration changes for HSDPA in compari-
son to conventional Release 99 networks. However, because of the increased band-
width requirements and the limited number range of call identifiers (see below) inside an
AAL2 VC, it is necessary to configure more AAL2 user plane VCs on the Iub interface.
AAL2 user plane VCs can be shared between several calls. To facilitate this, the VC car-
ries several AAL2 links which each are associated with an individual call. AAL2 links are
identified by their CID (call identifier) that is transported as an additional header byte of
an ATM cell.
Each HSDPA user requires 3 CIDs to be allocated, which are used for UL DTCH (A-
DCH), DCCH, and HS-DSCH. Thus, HSDPA support adds the requirement for 1 addi-
tional CID to each call. If there are 64 HSDPA users to a radio cell, and 3 radio cells to
a Node B, the CID requirements add up to 576 CIDs per Node B. Since the CID is an 8
bit number (ranging from 0 to 255; not all values are available for usage), at least 3 AAL2
VCs must be allocated just to provide enough CIDs for a fully equipped HSDPA capable
Node B.
6.1.1 Flow Control

With regard to HSDPA, it is not the RNC but the Node B that controls the transfer rate
on Iub. This transfer rate is adjusted to the transfer rate that is achieved on the air inter-
face, Uu. For each HSDPA UE, the Node B maintains a buffer (’priority queue’) that
stores the HSDPA user data until it is transmitted over the Uu interface. The Node B re-
quests data from the RNC using the credit-based flow control mechanism of 3GPP
TS25.435, ’Iub Interface User Plane Protocols for COMMON TRANSPORT CHANNEL
Data Streams’. By requesting more or fewer data packets from the RNC, this buffer is
kept at a filling level between an upper and a lower boundary. Among other factors, the
net Uu transfer rate depends on radio interference and the number of retransmissions.
145
Refilling the priority queues is subject to the availability of bandwidth on the Iub inter-
face: if conventional traffic does not leave enough bandwidth, HSDPA buffers may tem-
porarily go empty. This is an intentional behavior since HSDPA data is of the interactive
and background traffic type and conventional traffic always takes precedence over it.
Flow control for a certain queue is activated during the NBAP: RL Setup Procedure, or
if the Node B receives an HS-DSCH Capacity Request control message from RNC.
For each HS-DSCH Capacity Request message the Node B responds with a HS-DSCH
Capacity Allocation message. This message contains information elements (Credits, In-
terval, Repetition Period) which can be interpreted by the RNC as an offer regarding
data rates or data packets.
After the first capacity allocation, the HS-DSCH MAC-d flow control is mainly driven by
the filling level of the Node B HS-DSCH priority queues. Depending on that filling level,
the Node B sends further adequate HS-DSCH capacity allocation message to the RNC.
6.1.1.1 Priority Queue Management

MAC-d is the protocol in the radio network layer (see 2.1.1 "HSDPA Protocol Stack in
UTRAN") that is used for data transfer and mapping between logical channels and trans-
port channels. Each HS-DSCH is represented as a MAC-d flow and occupies an AAL2
CID within the VC for AAL2 user plane traffic.
Managing the priority queues includes the following functions:
• Setup of new priority queues, upon request by the SRNC
• Deletion of priority queues, if required
• Processing of incoming data
• Transport block assembly and transfer of the transport block to the HS-PDSCH sym-
bol rate processing entity
• Reporting relevant information to the scheduler
• Error handling.
6.1.2 QoS Mechanism

Within the RNC, QoS differentiation is performed on the AAL2 level. The assigned pri-
orities are:
highest UDI, PS Streaming, AMR voice

low PS best-effort traffic on DCH
lowest HS-DSCH
These assignments make sure that HSDPA traffic has least priority.
146
The changes on the transport network layer with regard to HSDPA impact on both the
RNC and the Node B. For more information, refer to "Interworking Between RNC and
Node B" on page 35.

The RNC atrk HMI command (ATRK Interface GUI window) serves to view, block and
unblock traffic that the RNC itself (rather than the operator) assigns to its hardware re-
sources. This command has been expanded to also offer parameters related to the traf-
fic that is automatically assigned to HSDST and HSPRLC cards.
The new hardware also introduces the following new HMI output messages:
The existing alarms
• 0053268 cmuxbl_fault
• 0053269 cmuxbl_fault_recovery
• 1348012 trunk_card_congestion_occurred
• 1348013 trunk_card_congestion_recovered
are modified to also cover faults in the HSPRLC hardware. For details see "Fault man-
agement".

Not yet applicable.
147
7 Air Interface (Uu) Modifications
With the support of HSDPA, the Uu interface is upgraded to 3GPP Release 5. This
change provides new Uu interface functionalities for the HSDPA-capable Node Bs, such
as:
• MAC-hs protocol for scheduling between UEs
• Adaptive modulation and coding (AMC)
• Management of data queues for each UE

The UMTS air interface (i.e. Uu interface) is the radio interface between the UMTS ter-
restrial radio access network (UTRAN) and the user equipment (UE). The Uu interface
comprises the control plane (C-plane) for signaling and the user plane (U-plane) for the
transfer of user data. The Uu interface consists of three protocol layers:
• Physical layer (L1/PHY)
• Data link layer (L2)
The data link layer is divided into sublayers:
– Medium Access Control Protocol (L2/MAC)
– Radio Link Control Protocol (L2/RLC)
– Broadcast/Multicast Control Protocol (L2/BMC)
– Packet Data Convergence Protocol (L2/PDCP)
• Network layer (L3)
The radio resource control protocol (L3/RRC) is the only element of the network lay-
er.
Fig. 7.1 provides an overview of the Uu interface’s protocol architecture. Service access
points are marked as ellipses.
148
C-plane signaling U-plane information
GC Nt DC
Duplication avoidance
GC Nt DC
UuS boundary
control L3
RRC
PDCP
PDCP L2/PDCP
control
control
control
control
BMC L2/BMC
RLC RLC
RLC RLC L2/RLC
RLC RLC
RLC RLC
Logical Channels
MAC L2/MAC
Transport Channels
PHY L1
Fig. 7.1 Uu interface protocol architecture
The 3GPP Release 5 (Rel 5) RNC is able to interoperate with a UE of Rel 99, Rel 4, and
Rel 5 via the Uu interface.
To support HSDPA, minimum changes are required in the UTRAN for compliancy to the
Rel 5 version of protocols at the Uu interface. These changes impact on Uu layer 1 (L1),
layer 2 (L2), and layer 3 (L3).
7.1.1 Changes on the Uu Interface Layer 1

Compared to 3GPP Rel 99, the functionalities of the physical layer measurements on
the Uu L1 (physical layer) are changed by Rel 5 with respect to the following:
• Received total wideband power (RTWP)
• Signal to interference ratio (SIR)
According to 3GPP Rel 5, the Rx antenna connector is the reference point when meas-
uring the RTWP.
Furthermore, Rel 5 demands changes concerning the measurement of the SIR. In an
RL set consisting of more than one RL, the reported value must be the linear summation
of each RL’s SIR in the RL set. If Rx diversity is used, the RL’s SIR must be the linear
summation of each Rx antenna’s SIR for that RL. In addition, if cell portions are defined,
SIR measurement must be possible in each cell portion.
The HSDPA-capable Node Bs already comply with these requests.
149
The Rel 5-compliant upgrade of the Uu interface impacts on the Uu layer 2 (L2) which
consists of the broadcast/multicast control (BMC), packet data convergence protocol
(PDCP), radio link control (RLC), and media access control (MAC). The broadcast/mul-
ticast control, the packet data convergence protocol, and the media access control re-
main unchanged after the upgrade from 3GPP Rel 99 to Rel 5.
Radio Link Control (RLC)

In 3GPP Rel 5, the special length indicator (LI) values “111 1100” and
“111 1111 1111 1100” are optionally used on the downlink (DL) whereas in Rel 99,
these LI values were mandatory. The Rel 5 RNC always applies these special LIs.
These values indicate the first octet of an RLC signaling data unit (SDU) in RLC unac-
knowledged mode (UM). Both LI values are utilized to inform the UE that the RLC sign-
aling data unit (SDU) exactly matches the data field of the RLC protocol data unit (PDU),
thus enabling faster decoding on the UE side because the UE then does not have to
search for the end of the RLC SDU.
On the uplink (UL), in contrast, these special LI values must be used in the 3GPP Rel 5-
compliant UMR5.0, whereas in Rel 99, both LIs were forbidden on the UL. Possible in-
terworking problems on the UL between Rel 99 RNCs and Rel 5 RNCs are avoided due
to the fact that the Rel 99 RNC already supports the handling of the two special LI values
on the UL in each RLC protocol machine.
On the RLC, there is no further impact on RNC because no new services/functions are
mapped onto logical channels.

The following functionalities of the Uu L3 are affected by this Rel 5-compliant Uu modi-
fication:
• Radio resource control protocol
• Identification of a UE’s 3GPP release
• Features previously supported
• RRC error handling
7.1.3.1 Impacts on the Radio Resource Control (RRC) Protocol

The RRC is the Uu L3 protocol. The RRC protocol defines protocol extensions in order
to add new values or choices to existing IEs, or to add new IEs to existing messages.
Generally, three different types of message structures are defined: Rel 99, Rel 4, and
Rel 5 RRC structures. According to 3GPP, the UE always comprehends the complete
transfer syntax specified for its supported protocol version (backward compatibility). A
Rel 5 UE, therefore, is able to comprehend Rel 99 and Rel 4 message structures as
well.
In the Rel 5 RRC protocol, two new types of protocol extensions are defined by 3GPP:
non-critical and critical extensions. Non-critical extensions are allowed for both uplink
150
(UL) and downlink (DL) messages, whereas critical extensions can only be applied in
DL direction. These two kinds of message extensions are processed as follows:
• Non-critical extensions
In general, the receiver processes messages including non-critical extensions which
are not comprehended as if these extensions were absent.
The sending of messages containing non-critical extensions is performed by adding
a non-critical extension container at the end of a release-specific message. Thus,
such messages consist of two parts - the actual message and a non-critical exten-
sion. Both parts are release-specific.
• Critical extensions
When receiving a message including a critical extension which is not comprehend-
ed, the receiver will entirely reject this message and inform the sender about the re-
jection. A partial rejection of messages is not possible.
To send messages with critical extensions, a new version of the message has to be
defined. The newly defined version is indicated at the beginning of the message.
Here, again, the message structures of the different releases (Rel 99, Rel 4, and
Rel 5) are distinguished.
Due to the introduction of 3GPP Rel 5-compliant critical and non-critical message exten-
sions, enhanced functionalities are required for the RNC’s Rel 5 RRC decoder and en-
coder:
• Rel 5 RRC decoder
The Rel 5 decoder is able to comprehend Rel 99, Rel 4, and Rel 5 UL messages in-
cluding all non-critical extensions introduced up to Rel 5. The decoded messages
will then be sent to the RNC application.
• Rel 5 RRC encoder
RNC’s Rel 5 RRC encoder must take care of the UE’s release in order to use the
appropriate message structure and include only those critical and non-critical exten-
sions supported by the relevant release. Thus, the inclusion of protocol extensions
from releases later than the UE’s release is prevented.
In UMR5.0, all HSDPA-related messages are encoded with a Rel 5 structure. The
following messages are affected:
– CELL UPDATE CONFIRM
– RADIO BEARER SETUP
– RADIO BEARER RELEASE
– RADIO BEARER RECONFIGURATION
– TRANSPORT CHANNEL RECONFIGURATION
– MEASUREMENT CONTROL (Rel 4 structure with Rel 5 non-critical extensions)
7.1.3.2 Identification of a UE’s 3GPP Release

The Rel 5 RNC obtains the UE’s supported protocol version upon one of the three
events listed below. In each of these cases, the relevant messages include the new “Ac-
cess Stratum Release Indicator“ IE indicating the 3GPP release which the UE supports.
Rel 99 is indicated whenever this IE is absent, whereas the presence of the IE indicates
either Rel 4 or Rel 5.
The UE furthermore sends its radio access capabilities contained in the RRC: UE CA-
PABILITY INFORMATION. This information always includes Rel 99 capabilities and op-
tionally Rel 4 and/or Rel 5 capabilities, depending on the UE’s release.
The RNC then stores this information for the duration of the call.
151
• RRC connection establishment
The establishment of an RRC connection is inititated upon reception of the RRC:
CONNECTION REQUEST message. The UE always includes the ’Access Stratum
Release Indicator’ IE in this message. The UE may send other radio access capa-
bilities in the RRC: COONECTION SETUP COMPLETE message, together with
Rel 99 capabilities.
The RNC then stores any capability information received for the duration of the call.
• Inter-RAT handover to UTRAN
An inter-RAT handover to UTRAN is performed upon reception of the RANAP: RE-
LOCATION REQUIRED message.
The RNC checks if the ’Access Stratum Release Indicator’ IE is present.
– If the ’Access Stratum Release Indicator’ IE is absent during inter-RAT handover
to UTRAN, the RNC treats the relevant UE as Rel 99 UE.
– Otherwise, if both the INTER RAT HANDOVER INFO part of the relevant RRC
container includes this IE and the IE indicates Rel 4 or Rel 5, the RNC initiates
the “UE Capability Enquiry” procedure due to the fact that Rel 4 and Rel 5 IEs are
not part of the RRC container for inter-RAT handover to UTRAN. Thereupon, the
RNC proceeds as described above.
• Serving Radio Network Subsystem (SRNS) relocation
The SRNS relocation is performed upon reception of the RANAP: RELOCATION
REQUIRED message.
In the event of an SRNS relocation, the identification procedure is similar to that of
an inter-RAT handover.
– First, the SRNC includes the UE capabilities, containing Rel 99, Rel 4 and Rel 5
capabilities, in the SRNS Relocation RRC container. This container is then trans-
ferred to the target RNC (TRNC).
– The TRNC, in turn, checks either whether the ’Access Stratum Release Indicator’
IE is present and all Rel 5-related UE radio access capabilities have been re-
ceived, or, alternatively, whether the ’Access Stratum Release Indicator’ IE is ab-
sent, thus implying a Rel 99 UE. If neither of these conditions is met and if no PS
interactive/background RAB exists, the target RNC performs the “UE Capability
Enquiry“ procedure.
This behavior of the TRNC is necessary in case the the SRNC supports a 3GPP re-
lease lower than that of the UE and of the TRNC. In such a scenario, the SRNC is
not able to decode/encode all UE capability IEs and therefore omits them from the
RRC container.
The reason why the TRNC checks for an existing PS interactive/background RAB is
the following: If the RRC container does not include Rel 5 capabilitiesduring the re-
location resource allocation, the TRNC then treats this UE as Rel 99-capable only
and assign the resources accordingly (e.g. PRLC resource). At a later point in time,
however, if the TRNC determines this particular UE as HSDPA-capable, it would not
be possible to reallocate some resources (e.g. HS-PRLC) to any existing PS inter-
active/background RAB. As a consequence, the UE would therefore continuously
have to treated as Rel 99 only. The above check thus avoids such a scenario.
If a UE supports 3GPP Rel 99 or Rel 4, the RNC treats this UE as if it was of Rel 99.
Therefore, Rel 4/5 features and/or message structures including critical extensions are
not used. On the other hand, if a UE supports Rel 5, the RNC applies Rel 5 message
152
structures to only those messages containing HSDPA-related IEs. Other messages are
of Rel 99 structure. The following messages may contain HSDPA-related IEs:
• CELL UPDATE CONFIRM
SRNC relocation on FACH and re-establishment on FACH
• RADIO BEARER SETUP
RAB setup from FACH/DCH to HS-DSCH and from HS-DSCH to DCH
• RADIO BEARER RELEASE
RAB release from HS-DSCH to DCH
• RADIO BEARER RECONFIGURATION
Setup or release of a second PS BE RAB
• TRANSPORT CHANNEL RECONFIGURATION
Channel-type switching (CTS) from FACH to HS-DSCH
• MEASUREMENT CONTROL
Setup of event 1D
7.1.3.3 Impacts of 3GPP Rel 5 on Previously Supported Features

For stable operation of an HSDPA-cabable Uu interface, few changes to previously sup-
ported features are essential. Features affected by Rel 5 HSDPA are:
• Security mode control
• Radio bearer control procedures
• Tx diversity
The establishment and the release of an RRC connection, however, are not affected by
the 3GPP Rel 5 Uu interface modifications.
Security mode control

If the UE sends a security mode failure, the SRNC will send the next message on the
signaling radio bearer 2 (SRB2). The COUNT-I value of this message will be higher than
the value of the COUNT-I which was used prior to sending the SECURITY MODE COM-
MAND message and then incremented by one. In previous releases, the value for the
RRC switching network (SN), being one part of the COUNT-I, was not incremented in
the event of a wrap-around.
Radio bearer control procedures

In Rel 99, the RADIO BEARER RECONFIGURATION message always included the
“Primary CPICH Info“ IE if FDD was used. Thus, as a restriction, the UTRAN had to in-
form a cell about whether it uses the RADIO BEARER RECONFIGURATION message
to move the UE to CELL_FACH state or not. The UE, however, performed cell selection
and notified the UTRAN when it selected another cell than indicated by the UTRAN.
In contrast to this scenario, Rel 5 removes the above restriction. Therefore, the RNC
does not have to include the “Primary CPICH Info“ IE in the event of a relocation to
CELL_DCH.
Tx diversity
In Rel 99, UEs were permitted to apply Tx diversity to all RLs in the active set even if the
UTRAN had not indicated Tx diversity for some of them.
Rel 5 clarifies that UEs can apply Tx diversity to only those RLs for which Tx diversity is
indicated by the UTRAN. However, since UEs were already allowed to recognize the ac-
153
tive RLs in non-diversity cells (individual RL mode NONE) in Rel 99, this change simply
means a clarification of the UE’s behavior.
NOTE
i In UMR5.0, Node Bs are not capable of providing Tx diversity for HSDPA cells.
7.1.3.4 RRC Error Handling

The RNC’s RRC handling of unknown, unforeseen, and erroneous protocol data is com-
pliant to 3GPP TS 25.331, section 9. The RNC’s RRC decoder comprehends all new
and modified Rel 4/5 messages and IEs and forwards them to the RNC application.
Since no new UL messages are introduced by Rel 4 and Rel 5, there is no need to apply
a graceful application error handling.

Not applicable.

Not applicable.

Not applicable.
154
8 HSDPA Performance Measurement Counters

Tab. 8.1 shows the performance measurement counters that are newly introduced with
support of HSDPA. Modifications to existing scanners are listed in Tab. 8.2.
The mtype values are used to configure performance measurements on the CLI inter-
face of the LMT-RNC.
The Shortname values are used to configure performance measurements on the CLI
interface of the Radio Commander.
Measurement mtype Shortname Purpose
Measurements performed on RNC

Procedure related measurements
Number of attempted Radio 7 hsEstabAtt This measurement provides the number of attempted
Link Establishments for HS- HS-DSCH radio link Establishments for each HSDPA
DSCH cell.
The measurement is based on two events:
– Transmission of NBAP: RADIO LINK SETUP RE-
QUEST by the RNC to the Node B requesting to set up a
new HS-DSCH (FACH to HS-DSCH); and
– Transmission of NBAP: RADIO LINK RECONFIGURA-
TON PREPARE message by the RNC to the Node B re-
questing to set up a new HS-DSCH (DCH to HS-DSCH).
Only messages initiated from the CRNC are taken into
account.
Number of unsuccessful Ra- 101 hsEstabFail This measurement provides the number of unsuccessful
dio Link Establishments for HS-DSCH radio link Establishments for each cell. For
HS-DSCH per failure cause each failure cause a separate sub-counter is defined
The measurement is based on three events:
– Receipt of NBAP: RADIO LINK SETUP FAILURE sent
by the Node B in response to a RADIO LINK SETUP RE-
QUEST message requesting the setup of a new HS-
DSCH
– Receipt of NBAP: RADIO LINK RECONFIGURATION
FAILURE sent by the Node B in response to a RADIO
LINK RECONFIGURATION PREPARE message for set-
up of a new HS-DSCH
– Non-receipt of NBAP: RADIO LINK SETUP RE-
SPONSE or NBAP: RADIO LINK RECONFIGURATION
READY (expiration of the appropriate timer) in response
to a RADIO LINK SETUP REQUEST or RADIO LINK
RECONFIGURATION PREPARE sent from the RNC to
the Node B, indicating the attempt to establish a new HS-
DSCH.
Only trigger conditions related to the CRNC are consid-
ered. Failure causes are defined in 3GPP TS25.433.
Tab. 8.1 New Performance Management counters
155
Subsystem related measurements
HSPRLC / PRLC throughput 192 hsprlcThrou This measurement indicates the used channels/band-
rate ghputRate width on HSPRLC and PRLC, given as a percentage of
the maximum performance. Thus, it indicates the RNC
hardware utilization by HSDPA service. Several sub-
counters are defined for average and maximum values
for UL and DL direction.
HSDST throughput rate 193 hsdst- This measurement provides the HSDST throughput rate,
Throughpu- given as a percentage of the HSDST maximum perform-
tRate ance. Several sub-counters are defined for average and
max values for UL and DL direction.
Number of attempted 72 hsprlcAllo- This counter collects the number of Resource Allocation
HSPRLC allocations cAtt Requests of HSPRLC.
Number of successful 73 hsprlcAlloc- This counter collects the number of successful Resource
HSPRLC allocations Succ Allocation Requests of HSPRLC.
Number of attempted HSDST 74 hsdstAllo- This counter collects the number of Resource Allocation
allocations cAtt Requests of HSDST.
Number of successful 75 hsdstAlloc- This counter collects the number of successful Resource
HSDST allocations Succ Allocation Requests of HSDST.
RRC connection state management
Number of attempted transi- 135 hsTransto- This measurement provides the number of attempted
tions from HS-DSCH to FachAtt switches from HS-DSCH to the CELL_FACH state for
FACH each cell.
Number of unsuccessful tran- 136 hsTransto- This measurement provides the number of unsuccessful
sitions from HS-DSCH to FachFail switches from HS-DSCH to the CELL_FACH state for
FACH state per failure cause each cell per cause.
Number of attempted transi- 137 hsTrans- This measurement provides the number of attempted
tions from FACH to HS- FromFach- switches from CELL_FACH state to HS-DSCH for each
DSCH Att cell.
Number of unsuccessful tran- 138 hsTrans- This measurement provides the number of unsuccessful
sitions from FACH state to FromFach- switches from CELL_FACH state to HS-DSCH for each
HS-DSCH per failure cause Fail cell per cause.
RAB assignment
Number of unsuccessful Ra- 92 rbReconfFail This counter records the number of unsuccessful radio
dio Bearer Reconfigurations bearer reconfigurations.
per failure cause
Measurements performed on Node B

HSDPA Cell measurement functions
156
HS-PDSCH code usage ratio hsCodeUsageRatio This ratio indicates the number of HS-PDSCH codes of
one TTI, related to the total number of TTI and the maxi-
mum number of HS-PDSCH codes per cell. Only TTIs
where HS-PDSCH codes have been transmitted are con-
sidered. There is no difference if the codes are used as
QPSK or 16QAM codes. The usage ratio of HS-PDSCH
code is measured every 10 seconds. At the end of the
granularity period, the mean, minimum and maximum
values are provided.
HSDPA Cell Throughput hsCellThroughput The HSDPA cell throughput records the number of MAC-
hs PDU bits including MAC-hs header.
The cell throughput is measured every 10 seconds in
kbit/s. At the end of granularity period the mean, mini-
mum and maximum values are provided.
HARQ NACK ratio hsNackRatio This counter is provided for monitoring the system per-
formance and validation of HS-PDSCH/HS-SCCH power
control mechanism.
The measurements records the sum of all not acknowl-
edged data transmissions (including re-transmission)
and compares it to the number of all TX attempts. The
HARQ NACK ratio is measured every 10 second. At the
end of the granularity period the mean, minimum and
maximum values are provided.
BB usage ratio for HSDPA re- hsBBUsageRatio Provides the mean and maximum base band load for
sources HSDPA resources per cell during the complete granular-
ity period.
This counter provides additional information related to
HSDPA resources, in addition to the existing base band
(BB) usage ratio counters. The BB usage ratio considers
the utilized resources per Node B related to the licensed
resources, whereas the BB usage ratio for HSDPA is re-
lated to the UL resources per HSDPA capable CHC
cards not based on the license information. For all cells
configured on the same HSDPA capable CHC card the
same values are provided.
Measurement mtype Shortname Modification
UE quantity measurements
Mean number of bearer services per cell re- 152 bearService- HS-DSCH is added to the range of ob-
lated perCell jects considered by this counter.
This measurement provides the mean
number of bearer services per cell.
Tab. 8.2 Modified Performance Management counters
157
The existing PM counter ’Mean user data throughput (UL/DL) on Iu Interface per CS/PS’
(mtype=142) remains unchanged. By definition, it covers
• Non-HSDPA data of PRLC
• HSDPA and Non-HSDPA data of HSPRLC.
The existing PM counter ’Mean user data throughput (uplink/downlink) on dedicated
channels per Node B’ (mtype=140) remains unchanged. It covers
• both HSDPA and non-HSDPA call data on the uplink
• only non-HSDPA call data on the downlink.
The existing PM counters
• Number of successful bearer service establishments per cell related (mtype=155)
• Mean number of bearer services on lub (mtype=156)
are modified to take account of the new bearers
– PS Interactive/Background 64/0
– PS Interactive/Background 384/0
– PS Interactive/Background 64/0+HS-DSCH
– PS Interactive/Background 384/0+HS-DSCH.

PM counters operate in the network element. They are setup by the OMC or the LMT-
RNC / LMT-NB. The measurement result files can be uploaded to the LMT or OMC.
From there they can be transferred to the OTS for further processing.

The new performance counters are configured using the existing commands and GUI
windows on LMT-RNC or LMT-NB and OMC.

Not yet applicable.
158
9 Operating HSDPA
Not yet applicable.
159
10 Abbreviations
16QAM 16 Quadrature Amplitude Modulation
3GPP 3rd Generation Partnership Project
AAL2 Asynchronous Transfer Mode Adaptation Layer 2
AAL5 Asynchronous Transfer Mode Adaptation Layer 5
AC Admission Control
ACK Acknowledged (message)
AGC Automatic Gain Control
ALCAP Access Link Control Application Part
ALS Alarm State
AMR Adaptive Multi-Rate
AMREQ AMR Equivalents
ARQ Automatic Repeat Request
AST Administrative State
ATM Asynchronous Transfer Mode
AVS Availability Status
BB Baseband
BE Best Effort
BLSC Broaden Line Switch Controller
BMC Broadcast/Multicast Control
BRA Bit-Rate Adaptation
CAC Connection Admission Control
CAPEX Capital Expenditure
CAT Combined Amplifier and Transceiver
CC Core Controller
CCH Common Channel
CE Channel Element
CHC Channel Coding Card
CID Call Identifier
CIR Carrier- to Interference-Power Ratio
CLI Command Line Interface
CmCH-PI Common Transport Channel - Priority Indicator
CMP Composite/Decomposite
CMUX Cell Multiplexer
CN Core Network
CQE Channel Quality Estimation
CQI Channel Quality Information
CRC Cyclic Redundancy Check
cRNC Classical Radio Network Controller (based on UMR2.0 HW)
CRNC Controlling Radio Network Controller
CS Circuit-Switched
CTS Channel-Type Switching
DBMS Database Management System
DCCH Dedicated Control Channel
DCH Dedicated Channel
DHT Diversity Handover Trunk
160
DL Downlink
DLCC Downlink Common Channel
DPCCH Dedicated Physical Control Channel
DRIC Digital Radio Interface Card
DRNC Drift Radio Network Controller
DSCP Differentiated Services Code Point
DSL Digital Subscriber Line
DSP Digital Signal Processor
DTCH Dedicated Traffic Channel
DUAMCO Duplexer Amplifier Multicoupler
E1 European Plesiochronous Digital Hierarchy Signal Level 1
eRNC RNC with Enhanced Capacity and Connectivity
ETSI European Telecommunications Standards Institute
FACH Forward Access Channel
FP Frame Protocol
FW Firmware
GMUX GTP Multiplexer
GTP GPRS Tunneling Protocol
GPRS General Packet Radio Service
GUI Graphical User Interface
HARQ Hybrid Automatic Repeat Request
HCS Hierarchical Cell Structure
HMI Human-Machine Interface
HMO Hardware Managed Object
hs-CHC Highspeed Channel Coding Card
HSDPA Highspeed Downlink Packet Access
HS-DPCCH Highspeed Dedicated Physical Control Channel
HS-DSCH Highspeed Downlink Shared Channel
HS-DSCH FP Highspeed Downlink Shared Channel Frame Protocol
HSDST Highspeed Downlink Shared Channel Trunk
HS-PDSCH Highspeed Physical Downlink Shared Channel
HSPRLC Highspeed Packet Radio Link Controller
HS-SCCH Highspeed Shared Control Channel
HW Hardware
I/B Interactive/Background (radio access bearer)
ID Identifier
IDF Inventory Data File
IE Information Element
IMA Inverse Multiplexing for Asynchronous Transfer Mode
IP Internet Protocol
ISO International Standard Organization
ITU International Telecommunications Union
Iu Interface between an RNC and the Core Network
Iub Interface between an RNC and a Node B
Iur Interface between two RNCs
J1 Japanese Plesiochronous Digital Hierarchy Signal Level 1
L1 Layer 1
161
L2 Layer 2
L3 Layer 3
LI Length Indicator
LMT Local Maintenance Terminal
LPA Linear Power Amplifier
LSM Line Switch Module
MAC Medium Access Control
MAC-d Medium Access Control - Dedicated
MAC-hs Medium Access Control - High Speed
MMI Man-Machine Interface
MOI Managed Object Instance
MOC Managed Object Class
NACK Not Acknowledged (message)
NBAP Node B Application Part
OAM Operation and Maintenance
OC-3 Optical Carrier Level 3
OMC Operation and Maintenance Center
OSI Open System Interconnect
OST Operational State
OTS Operation and Maintenance Tool Set
P-CPICH Primary Common Pilot Channel
PDCP Packet Data Convergence Protocol
PDU Protocol Data Unit
PM Performance Measurement
PRLC Packet Radio Link Controller
PRM Packet Radio Link Control Module
PRS Procedural State
PS Packet-Switched
PSCR Physical Shared Channel Reconfiguration
QoS Quality of Service
QPSK Quadrature Phase Shift Keying
QRS Quality Requirement Specification
RAB Radio Access Bearer
RACH Random Access Channel
RAT Radio Access Technology
RB Radio Bearer
RC Radio Commander
Rel 4 3GPP Release 4
REP Repeater
RF Radio Frequency
RL Radio Link
RLC Radio Link Control
RNC Radio Network Controller
RNC-BE Radio Network Controller - Back End
RNC-FE Radio Network Controller - Front End
162
RNL Radio Network Layer
RNS Radio Network Subsystem
RNTI Radio Network Temporary Identify
RRC Radio Resource Control
RRH Remote Radio Head
RRM Radio Resource Management
RSI Resource Status Indication
RTWP Received Total Wideband Power
SBS Standby State
S-CPICH Secondary Common Pilot Channel
SDU Signaling Data Unit
SF Spreading Factor
SIR Signal to Interference Ratio
SN Switching Network
SRB Signaling Radio Bearer
SRB2 Signaling Radio Bearer 2
SRNC Serving Radio Network Controller
SRNS Serving Radio Network Subsystem
STM-1 Synchronous Transport Module Level 1
STTD Space Time Transmit Diversity
SW Software
SWP System-Wide Parameter
T1 North American Plesiochronous Digital Hierarchy Level 1
TB Transport Bearer
TINF Trunk Interface
TNL Transport Network Layer
TOS Type of Service
TRNC Target Radio Network Controller
TRX Transceiver (Transmitter/Receiver)
TTI Time Transmission Interval
UDP User Datagram Protocol
UE User Equipment
UL Uplink
UM Unacknowledged Mode
UMR UMTS Mobisphere Release
UMTS Universal Mobile Telecommunications System
UTOPIA Universal Test and Operations Physical Interface for ATM
UTRAN UMTS Terrestrial Radio Access Network
Uu Radio Interface between the UTRAN and the User Equipment
VC Virtual Channel
VCI Virtual Channel Identifier
VP Virtual Path
VPI Virtual Path Identifier
WCMP Wideband Composite/Decomposite
WLAN Wireless Local Area Network
WLSC Wideband CMP and Line Switch Controller
163

Hsdpa Technical Description

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Hsdpa Technical Description

Hochgeladen von

Copyright:

Verfügbare Formate

UTRAN

The same text in German:

Copyright (C) Siemens AG / NEC Corporation 2005.

Technical modifications possible.

All First issue for new release.

1 04/2005 First issue for new release.

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

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

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

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

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

8 HSDPA Performance Measurement Counters. . . . . . . . . . . . . . . . . . . . . . 155

9 Operating HSDPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Modifications in the RNC HW/SW Architecture

Modifications in the Node B HW/SW Architecture

Modifications within UTRAN OAM

Transport Network Layer (TNL) modifications

Air Interface (Uu) modifications

1.3 Interworking / Dependencies

2.1 Functional Description

2.1.1 HSDPA Protocol Stack in UTRAN

PDCP PDCP GTP-U

Fig. 2.1 Protocol stack of HSDPA for UTRAN

M2C PRLC HSPRLC

DTCH (DL) on HS-DSCH

Fig. 2.2 Cards and traffic routes for HSDPA

CMP/WCMP HSDST HSPRLC GMUX

PDCP GTP-U GTP-U GTP-U

2.1.3 New/Modified RNC Hardware

FAN FAN FAN FAN FAN

B-SIGM C-M2CM GTPM B-MHM C-DHTM

FAN FAN FAN FAN FAN

E-CCPM B-MHM C-CMPM A-PRM (Extended) E-CCPM C-GTPM B-PRM

D-CCPM D-CMPM D-CMPM A-PRM (Extended) D-CCPM A-DTIM

B-LSF C-TRKF A-PRF D-LSF H-TRKF

WLSC CMUC/CMUXE HSDST HSPRLC

Modified Firmware New Hardware

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

FAN FAN FAN

WCMP B-MHM C-DHTM B-MHM C-DHTM

SIGM M2CM A-HUBM

FAN FAN FAN

E-CCPM C-GTPM B-PRM B-PRM C-PRM

D-LSF H-TRKF H-TRKF

PDM PDM PDM

FAN FAN FAN

WCMP B-MHM C-DHTM B-MHM C-DHTM

SIGM M2CM A-HUBM

FAN FAN FAN

E-CCPM C-GTPM B-PRM

D-LSF H-TRKF H-TRKF

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

Item Value Remarks

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

Tab. 2.1 HSDST card specification

Mounting and limitations

Item Value Remark

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

Tab. 2.2 HSPRLC card specification

Mounting and limitations

2.1.3.3 Modified WLSC Firmware

2.1.3.4 Modified CMUX/CMUXE Firmware

2.1.4.2 HS-DSCH Frame Protocol