SF012249 Architecture Support of HSDPA

UTRAN
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
A50016-G5000-Z180-3-7618
ND-59083-180(E)-03
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
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
Gerte mssen die zutreffenden Sicherheitsbestimmungen erfllen.
In diesen Anlagen stehen die Netzversorgungsleitungen unter gefhrlicher Spannung. Einige Komponenten
knnen auch eine hohe Betriebstemperatur aufweisen.
Nichtbeachtung der Installations- und Sicherheitshinweise kann zu schweren Krperverletzungen oder
Sachschden fhren.
Deshalb darf nur geschultes und qualifiziertes Personal das System installieren und warten.
Caution:
This equipment has been tested and found to comply with EN 301489. Its class of conformity is defined in 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 accordance with the relevant standards referenced in the manual Guide to Documentation, may cause harmful interference to radio communications.
For system installations it is strictly required to choose all installation sites according to national and local requirements concerning construction rules and static load capacities of buildings and roofs.
For all sites, in particular in residential areas it is mandatory to observe all respectively applicable electromagnetic
field / force (EMF) limits. Otherwise harmful personal interference is possible.
Trademarks:
All designations used in this document can be trademarks, the use of which by third parties for their own purposes
could violate the rights of their owners.
Copyright (C) Siemens AG / NEC Corporation 2005.
Issued by:
Siemens AG, Communications, Hofmannstrasse 51, 81359 Mnchen, Germany and
NEC Corporation, 7-1, Shiba 5-chome, Minato-ku, Tokyo, Japan
Technical modifications possible.
Technical specifications and features are binding only insofar as they are specifically and expressly agreed upon in a written contract.
Siemens AG:
NEC Corporation:
A50016-G5000-Z180-3-7618
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
Reason for Update

Summary:
Mounting limitation taken into account: HSPRLC and PRLC can not be colocated in the
PRM module.
Details:
Chapter/Section
Reason for Update
2.1.3.2
Chapter New HSPRLC Card.

Mounting limitation changed to: HSPRLC and
PRLC can not be colocated in the PRM module.
Issue History
Issue
Date of issue
Reason for Update
04/2005
First issue for new release.
08/2005
HSDPA cell configurations for NB-580 have been
Number
added. The power reduction for 16QAM is no longer

required to achieve 3GPP-compliancy. HSDPA UE
Differentiation and Restriction Control for PS
Bearers are no longer part of this feature but separate features (FD012254 and FD012255, respectively). eqp, bldp d2, and atrk HMI commands
added to section Modified CLI Commands (RNC).
Editorial changes.
3
08/2005
Mounting limitation taken into account: HSPRLC and

PRLC can not be colocated in the PRM module.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
This document consists of 165 pages. All pages are issue 3.
Contents
1
1.1
1.2
1.3
1.4
Short Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
In General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Customer Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Interworking / Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2
2.1
2.1.1
2.1.2
2.1.3
2.1.3.1
2.1.3.2
2.1.3.3
2.1.3.4
2.1.4
2.1.4.1
2.1.4.2
2.1.4.3
2.1.4.4
2.1.4.5
2.1.4.6
2.1.5
2.1.5.1
2.1.5.2
2.1.5.3
2.1.5.4
2.2
2.3
2.4
Modifications in the RNC Hardware and Software Architecture . . . . . . . . .

Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HSDPA Protocol Stack in UTRAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HSDPA Traffic Within the RNC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
New/Modified RNC Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
New HSDST Card. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
New HSPRLC Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modified WLSC Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modified CMUX/CMUXE Firmware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HSDST Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MAC-d. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HS-DSCH Frame Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HS-DSCH DATA FRAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HS-DSCH CONTROL FRAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Handling of the Initial Capacity Allocation IE . . . . . . . . . . . . . . . . . . . . . . .
Internal FP (HSDPA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HSPRLC Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP/UDP/GTP-U . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Packet Data Convergence Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Radio Link Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Internal FP and Internal FP (HSDPA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Functional Split . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Man-Machine Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operating the Feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
13
13
14
15
20
21
21
21
22
22
22
22
23
24
24
25
25
25
25
26
26
26
26
3
3.1
3.1.1
3.1.1.1
3.1.1.2
3.1.2
3.1.3
3.1.4
Modifications in the Node B Hardware and Software Architecture . . . . . . .

Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifications of the Node Bs Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . .
CHC96 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
hs-CHC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifications of Radio Frequency (RF) Issues . . . . . . . . . . . . . . . . . . . . . .
Modifications of Call Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifications of the Transport on the Iub Interface and the Priority Queue
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interworking Between RNC and Node B. . . . . . . . . . . . . . . . . . . . . . . . . . .
UTOPIA Connection Handling on the CC-BB Interface . . . . . . . . . . . . . . .
The MAC-hs Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Handling of Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
31
33
34
34
35
35
3.1.4.1
3.1.4.2
3.1.5
3.1.5.1
3.1.5.2
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
37
37
37
38
38
38
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
3.1.5.3
3.1.5.4
3.1.5.5
3.1.5.6
3.1.6
3.1.6.1
3.1.6.2
3.1.7
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.3
3.3.1
3.3.2
3.3.3
3.4
Transmission Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
HARQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Channel Quality Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Measurements and Performance Measurement (PM) Counters . . . . . . . . . 40
Modifications of Signal Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Downlink Signal Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Uplink Signal Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Modifications of Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Functional Split . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Core Controller (CC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Channel Coding Card (CHC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Repeater (REP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Transceiver (TRX) or Digital Radio Interface Card (DRIC) . . . . . . . . . . . . . 43
Man-Machine Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Front Panel Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Front Panel Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Manual Intervention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Operating the Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4
4.1
4.1.1
4.1.1.1
4.1.1.2
4.1.1.3
4.1.1.4
4.1.1.5
4.1.1.6
4.1.1.7
4.1.1.8
4.1.1.9
4.1.1.10
4.1.1.11
4.1.1.12
4.1.1.13
4.1.1.14
4.1.1.15
4.1.1.16
4.1.1.17
4.1.1.18
4.1.1.19
4.1.1.20
4.1.1.21
4.1.2
4.1.2.1
4.1.2.2
4.1.2.3
4.1.2.4
HSDPA Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
HSDPA RAB Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
UE Support of HSDPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
RAB Eligibility for HSDPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Radio Bearer Combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
RAB Multiplexing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Impacts on the Radio Bearer Translation. . . . . . . . . . . . . . . . . . . . . . . . . . . 49
RRC Connection State Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Traffic Monitoring and Channel-Type Switching . . . . . . . . . . . . . . . . . . . . . 55
Power Control and Measurement Feedback Parameters . . . . . . . . . . . . . . 55
RAB Setup Procedure from DCH to HS-DSCH . . . . . . . . . . . . . . . . . . . . . . 56
RAB Setup Procedure from FACH to HS-DSCH . . . . . . . . . . . . . . . . . . . . . 60
Channel-Type Switching from FACH to HS-DSCH . . . . . . . . . . . . . . . . . . . 63
Channel-Type Switching from HS-DSCH to FACH . . . . . . . . . . . . . . . . . . . 64
RAB Setup Procedure from HS-DSCH to DCH . . . . . . . . . . . . . . . . . . . . . . 66
RAB Release Procedure from HS-DSCH to DCH . . . . . . . . . . . . . . . . . . . . 68
RAB Release Procedure from Multicall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
RRC Connection Reestablishment Procedure. . . . . . . . . . . . . . . . . . . . . . . 71
Radio Bearer Reconfiguration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 71
SRNS Relocation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
RAB Setup Procedure from CCH to DCH and DCH to DCH . . . . . . . . . . . . 72
Pre-emption and Interaction with Admission Control . . . . . . . . . . . . . . . . . . 73
Allocation of H-RNTI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
HSDPA Mobility Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Scenarios for Mobility Handling of HS-DSCH . . . . . . . . . . . . . . . . . . . . . . . 76
MAC-hs Reset and Loss of Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Measurement Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
HS-DSCH Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
4.1.2.5
4.1.2.6
4.1.2.7
4.1.2.8
4.1.2.9
4.1.2.10
4.1.3
4.1.3.1
4.1.3.2
4.1.3.3
4.1.3.4
4.1.3.5
4.1.3.6
4.1.3.7
4.1.4
4.1.4.1
4.1.4.2
4.1.4.3
4.1.4.4
4.2
4.2.1
4.2.2
4.2.3
4.2.4
4.3
4.3.1
4.3.2
4.3.3
4.3.4
4.4
Inward Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Change of the Serving HS-DSCH Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Outward Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
DRNC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Error Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
UE Differentiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
HSDPA Admission Control and Congestion Control. . . . . . . . . . . . . . . . . 102
Radio Resource Management (RRM) Issues . . . . . . . . . . . . . . . . . . . . . . 102
Load, Power, and Code Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Admission Control in the CRNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Restriction Control in the CRNC for HSDPA. . . . . . . . . . . . . . . . . . . . . . . 107
Admission Control in the Node B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Congestion Control Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Integration of the Admission Control Algorithm for HSDPA . . . . . . . . . . . 109
HSDPA Code and Power Allocation and Redimensioning . . . . . . . . . . . . 110
State Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Common Measurements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Code and Power Allocation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Modification and Deletion of HSDPA Resources . . . . . . . . . . . . . . . . . . . 120
Functional Split . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
HSDPA RAB Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
HSDPA Mobility Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Man-Machine Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
HSDPA RAB Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
HSDPA Mobility Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Operating the Feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5
5.1
5.1.1
5.1.1.1
5.1.1.2
5.1.1.3
5.1.1.4
5.1.2
5.1.2.1
5.1.2.2
5.1.2.3
5.1.2.4
5.2
5.3
5.3.1
5.3.2
5.3.2.1
Modifications within UTRAN Operation and Maintenance . . . . . . . . . . . .

Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Equipment Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transport Network Layer Management . . . . . . . . . . . . . . . . . . . . . . . . . .
Radio Network Layer Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optional Feature Handling Within the RNC . . . . . . . . . . . . . . . . . . . . . . .
Node B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Equipment Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transport Network Layer Management . . . . . . . . . . . . . . . . . . . . . . . . . .
Radio Network Layer Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optional Feature Handling Within the Node B . . . . . . . . . . . . . . . . . . . . .
Functional Split . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Man-Machine Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Impacts on the RC GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Impacts on the LMT-RNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
New CLI Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
126
126
126
126
128
128
131
132
132
134
134
134
135
136
136
137
137
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
5.3.2.2
5.3.2.3
5.3.2.4
5.3.3
5.3.4
5.3.4.1
5.3.4.2
5.3.4.3
5.3.4.4
5.4
Modified CLI Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

New Output Messages at the LMT-RNC . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Modified Output Messages at the LMT-RNC . . . . . . . . . . . . . . . . . . . . . . . 142
Impacts on the LMT-Node B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
OAM Tool Set (OTS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Extensions for South-Bound Import Operations and OTS Core . . . . . . . . 144
Extensions for South-Bound Export Operations . . . . . . . . . . . . . . . . . . . . 145
Consistency Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Extensions for North-Bound Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Operating the Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
6
6.1
6.1.1
6.1.1.1
6.1.2
6.2
6.3
6.4
Transport Network Layer (TNL) Modifications . . . . . . . . . . . . . . . . . . . . . . 147

Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Priority Queue Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
QoS Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
7
7.1
7.1.1
7.1.2
7.1.3
7.1.3.1
7.1.3.2
7.1.3.3
7.1.3.4
7.2
7.3
7.4
Air Interface (Uu) Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Changes on the Uu Interface Layer 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Impacts on the Radio Resource Control (RRC) Protocol. . . . . . . . . . . . . . 152
Identification of a UEs 3GPP Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Impacts of 3GPP Rel 5 on Previously Supported Features . . . . . . . . . . . . 155
RRC Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
8
8.1
8.2
8.3
8.4
HSDPA Performance Measurement Counters. . . . . . . . . . . . . . . . . . . . . . 157

Operating HSDPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
10
Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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 HSDSCH. 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 information 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 capability 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 HSDSCH of one cell and can receive DCHs of multiple cells.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
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)
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/Intersystem 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 perform 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 HSDSCH, 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 requires 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 or
the installation of the new hs-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.
10
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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.
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 Management, 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 HSDPA with additional enhancements to the Radio Commander, LMTs, and OTS.
New HMI commands are supplied in order to configure the new HSDST- and HSPRLCcards. 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 measurements 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 requirements 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
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
11
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
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 management of data queues for each UE are some of the new air interface functionalities of
the Node B.
1.2
Customer Benefits
With UMR5.0 making use of HSDPA services, the mobile phone subscriber will experience an improvement of QoS compared to Release 99 UMTS services. The improvements 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 capacity. The Node Bs increased capacity leads to more users and, consequently,
more data throughput per square kilometer.
Higher benchmarking of UMR5.0 operators compared to Rel 99 and existing 2.5G
Operators, which already offer data rates up to 384 kbit/s today.
Enabling of new billing categories, such as mobile flat rates combined with high peak
rates in order to compete with fixed network services like DSL.
Competition with WLAN operators via outdoor coverage, security advantage, and
mobility rather than indoor competition.
Higher performance (factor 3) than CDMA2000 systems (especially important for
Asian and US Markets).
1.3
Interworking / Dependencies
The introduction of HSDPA has a design impact on all UTRAN network elements. Network 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 experience 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
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
2 Modifications in the RNC Hardware and Software 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 current Rel 99 services. The PRLC and DHT cards of the current RNC HW do not have sufficient 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 account 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 GTP-U
PDCP
RLC
RLC
MAC-d
MAC-d
HS-DSCH
FP
MAC-hs
Phy.
Fig. 2.1
AAL2
AAL5
ATM
ATM
ATM
Phy.
Phy.
Phy.
Node B
Uu
IP
HS-DSCH
FP
MAC-hs AAL2
Phy.
UE
UDP
RNC
Iub
Iu
Protocol stack of HSDPA for UTRAN
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
13
Support of HSDPA
FD012249 - UMR5.0
2.1.2
Feature Description
Radio Subsystem
HSDPA Traffic Within the RNC

Fig. 2.2 summarizes the HSDPA traffic routed through different cards within the RNC.
Iu
CLP
GMUX
DCCH
M2C
DTCH(PS)
PRLC
HSPRLC
DHT
HSDST
DCCH on
FACH/RACH
MHC
DTCH on
FACH/RACH
DCCH on
DCH
DTCH
on DCH
CMP/
WCMP
To/From Iub Interface

Iub Interface
DTI/
MDTI
DTCH (DL)
on HS-DSCH
DTCH (UL)
on A-DCH
TINF
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
14
Cards and traffic routes for HSDPA

Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
NOTE
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
HSPRLC
GMUX
PDCP GTP-U
GTP-U GTP-U
HSDST
RLC
AAL2 AAL2-d
ATM
ATM
UDP
UDP
IP
IP
IP
AAL5
AAL5
ATM
ATM
Internal
FP
HS-DSCH
(HSDPA)
FP
Internal
FP
(HSDPA)
AAL2-d AAL2-d
AAL2-d AAL5
ATM
ATM
ATM
RNC
Iub
Fig. 2.3
UDP
MAC-d
ATM
Iu
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
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
15
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
Fuse
Fuse
Fuse
PDM
PDM
FAN
FAN
FAN
FAN
FAN
B-SIGM
C-M2CM
C-DHTM
C-DHTM
GTPM
B-LSM
C-DHTM
B-SIGM
C-M2CM
C-LSM
A-PRM (Basic)
FAN
FAN
C-CMPM
A-PRM (Extended)
E-CCPM
D-CCPM
D-CMPM D-CMPM
A-PRM (Extended)
D-CCPM
A-DTIM
B-LSF
C-TRKF
A-PRF
D-LSF
H-TRKF
FAN
E-CCPM
FAN
B-MHM
cRNC/eRNC
WLSC
FAN
C-GTPM
B-PRM
eRNC
CMUX/CMUXE
Modified Firmware
Fig. 2.4
B-MHM
HSDST
HSPRLC
New Hardware
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
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
PDM
PDM
PDM
FAN
FAN
FAN
WCMP
B-MHM
C-DHTM
B-MHM
C-DHTM
SIGM
M2CM
A-HUBM
C-LSM
FAN
FAN
E-CCPM
C-GTPM
FAN
B-PRM
D-CCPM
A-DTIM
D-LSF
H-TRKF
B-PRM
C-PRM
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
SIGM
M2CM
A-HUBM
C-DHTM
C-LSM
FAN
FAN
E-CCPM
C-GTPM
FAN
B-PRM
D-CCPM
A-DTIM
D-LSF
H-TRKF
H-TRKF
New delivery of equipment: 2 x HSDST + 4 x HSPRLC

HSDST
Fig. 2.5
HSPRLC
Frame layout of RNC (example) with new HW for update and new delivery
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
17
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
In addition to the new hardware modified FW is necessary:

Modified WLSC FW for controlling HSDST cards (see Fig. 2.6)
Modified CMUX/CMUXE FW for controlling HSPRLC cards (see Fig. 2.7)
Fig. 2.6
18
blank #24
blank #25
blank #26
blank #27
WCMP #28
WCMP #29
WCMP #30
WCMP #31
TINF #08
TINF #09
TINF #10
TINF #11
TINF #12
TINF #13
blank #14
blank #15
WCMP #23
TINF #07
CLKD #1
WCMP #22
TINF #06
CLKD #0
#0
CLKD
blank #21
TINF #05
LSW #1
blank #20
TINF #04
WLSC
LSW #0
HSDST #19
blank #03
WLSC #1
HSDST #18
TINF #02
WLSC #0
blank #16
blank #17
TINF #01
HUBIU #1
TINF #00
HUBIU #0
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
C-LSM face layout of eRNC (example) with new HW and FW-update
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
Blank
Blank
Blank
Blank
Blank
Blank
Blank
Blank
Blank
Blank
Blank
Blank
Blank
CMUXE #1
Reinforcing Plate
CMUXE #0
Blank
Blank
Blank
Blank
Blank
Blank
HSPRLC 1
HSPRLC 0
C1HWM #1
C1HWM #0
HUBIU #1
HUBIU #0
Blank
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
A-PRM (Extended)
Blank
Blank
Blank
Blank
Blank
Blank
HSPRLC 1
HSPRLC 0
C1HWM 01
C1HWM 00
C-PRM
B-PRM
CMUX/CMUXE
Fig. 2.7
CMUX #1
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16
CMUX #0
Blank
Blank
Blank
Blank
HSPRLC 1
HSPRLC 0
HUBIU 1
HUBIU 0
C1HWM 01
C1HWM 00
CMUX #1
CMUX #0
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16
HSPRLC
A-PRM/B-PRM/C-PRM face layout (examples) with new HW and FW-update
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
19
Support of HSDPA
FD012249 - UMR5.0
2.1.3.1
Feature Description
Radio Subsystem
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
channels
4000 ch/card
Redundancy
Single(0/1)
Size
294x324 mm (HxW),
1 slot
Target Power
consumption
30 W
Tab. 2.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.
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
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
2.1.3.2
Support of HSDPA
FD012249 - UMR5.0
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
channels
2016 ch/card
Redundancy
Single
Size
294x324 mm (HxW),
2 slots
Target power consumption
50 W
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 not be colocated in the PRM module.
HSPRLC cards can be mounted in the locations shown in Fig. 2.7, using the PRLC
slots. It is, however, not advisable to fully populate a PRM with HSPRLC cards, as
their combined throughput will exceed the capacity of the CMUX/CMUXE (approximately 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 replaced 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.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
21
Support of HSDPA
FD012249 - UMR5.0
2.1.4
Feature Description
Radio Subsystem
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 following 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
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
IE
Value
Comment
Header CRC
0..127
Refer to 3GPP TS 25.435.
Frame Type
0 = data frame
CmCH-PI
0..15
Priority of HS-DSCH DATA FRAME.
MAC-d PDU
Length
13
336, 656
[bits]
RLC PDU size is 336 bits or 656 bits.

If multiplexing MAC-d is used, the
MAC-d header which is C/T field (4bits)
is added.
NumOfPDU
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
Dont care Is to be ignored by Node B.
Spare Bit
Always set to 0.
Padding
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
2.1.4.4
Field
length
[bit]
HS-DSCH DATA FRAME Header IE
HS-DSCH CONTROL FRAME

Handling of CAPACITY ALLOCATION message
The transmitting rate of HS-DSCH DATA FRAME is determined from the value of Maximum 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
[bit]
Value
Spare Bit
Don't care
CmCH-PI
0..15
Maximum MAC-d
PDU Length
13
0..5000
[bits]
HS-DSCH Credits
11
0..2047
HS-DSCH Interval
0..255
[10ms]
Tab. 2.4
Comment
0 = stop transmission, 2047 = unlimited. The number of MAC-d PDU

during one HS-DSCH Interval.
CAPACITY ALLOCATION message
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
23
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
IE
Field length
[bit]
HS-DSCH Repetition Period
Tab. 2.4
Value
Comment
Don't care
0 = unlimited repetition period.

RNC always sets it to 0 in the first
release.
CAPACITY ALLOCATION message
Handling of the CAPACITY REQUEST message

The CAPACITY REQUEST message is sent to the Node B by the RNC when CAPACITY 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.
IE
Value
Spare Bit
Don't care
CmCH-PI
0..15
User Buffer Size
16
0..65535
[octets]
Tab. 2.5
2.1.4.5
Field length
[bit]
Comment
The amount of data pending for the

respective MAC-d flow for the
CmCH-PI level.
CAPACITY REQUEST message
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 CAPACITY 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 control is performed between the HSDST and the HSPRLC, and this FP complies with the
HS-DSCH FP flow control.
24
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
2.1.5
Support of HSDPA
FD012249 - UMR5.0
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 HSPRLCs PDCP has the following functions:
Data transfer
Header Compression
RFC-2507 IP Header Compression is supported
2.1.5.3
Radio Link Control

The HSPRLCs RLC has the following functions:
Segmentation/Reassembly
Concatenation
Pe-adding
Data transfer
Error correction
In-sequence delivery of upper-layer PDUs
Duplicate detection
Flow control
Protocol error detection / restoration
Ciphering
Acknowledged Mode / Unacknowledged Mode
In addition to the same function as PRLC of Rel 99, the following new functions are supported 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.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
25
Support of HSDPA
FD012249 - UMR5.0
2.1.5.4
Feature Description
Radio Subsystem
Internal FP and Internal FP (HSDPA)

The HSPRLC deals with the Internal FP which is a protocol for transmitting data for dedicated PS traffic between HSPRLC and DHT or MHC in contrast to the Internal FP (HSDPA). 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
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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 referred 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
type(s)
NB-4203
NB-44x
Variant
TRX-LPA
TRX-LPA
Cell
HSDPA
configuration configuration
Power/
cell [W]
1/0/0
1/0/0
20
1/1/0
1/1/0
20
1/1/1
1/1/1
20
1/0/0
1/0/0
20
1/1/0
1/1/0
20
1/1/1
1/1/1
20
2/0/04
1/0/0
20
1/1/0
20
2/2/24
1/1/1
20
1/0/0
1/0/0
20
1/1/0
1/1/0
20
1/1/1
1/1/1
20
1/0/0
1/0/0
40
1/1/0
1/1/0
40
2/2/0
NB-860
DRIC-CAT20
DRIC-CAT40
1/1/1
Tab. 3.1
TRX
LPA
CAT1
RRH2
1/1/1
40
1/0/0
20
2/2/04
1/1/0
20
2/2/24
1/1/1
20
1/0/0
1/0/0
12.5
1/1/0
1/1/0
12.5
1/1/1
1/1/1
12.5
2/0/04
1/0/0
6.25
2/2/04
1/1/0
6.25
2/2/24
1/1/1
6.25
2/0/0
DRIC-RRH
Number of RF modules
Possible HSDPA cell configurations in UMR5.0
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
27
Support of HSDPA
FD012249 - UMR5.0
Node B
type(s)
NB-88x
Variant
DRIC-CAT20
Feature Description
Radio Subsystem
Cell
HSDPA
Power/
cell [W]
1/0/0
1/0/0
20
1/1/0
1/1/0
20
1/1/1
1/0/0
20
2/2/04
1/1/0
20
1/1/1
20
1/0/0
1/0/0
40
1/1/0
1/1/0
40
RRH2
1/1/1
40
1/0/0
20
2/2/04
1/1/0
20
1/1/1
20
2/0/04
1/0/0
40
1/1/0
40
2/2/24
1/1/1
40
1/0/0
1/0/0
12.5
1/1/0
1/1/0
12.5
1/1/1
1/1/1
12.5
2/0/04
1/0/0
6.25
1/1/0
6.25
2/2/24
1/1/1
6.25
1/1/1/1/0/0
1/1/1/1/0/0
12.5
DRIC-CAT-RRH 1/0/0, 1/0/0
1/0/0, 1/0/0
20, 12.5
1/1/0, 1/1/0
1/1/0, 1/1/0
20, 12.5
1/1/1, 1/1/1
1/1/1, 1/1/1
20, 12.5
1/0/0, 1/0/0
1/0/0, 1/0/0
40, 12.5
1/1/0, 1/1/0
1/1/0, 1/1/0
40, 12.5
1/1/1, 1/1/1
1/1/1, 1/1/1
40, 12.5
2/0/04, 2/0/04
2/0/0, 2/0/0
20, 6.25
15/26
with Booster
1/0/0
1/0/0
10
without Booster
1/0/0
1/0/0
0.5
2/0/0
2/2/2
2/2/0
DRIC-RRH
2/2/0
28
CAT1
20
1/1/1
Tab. 3.1
LPA
1/1/1
2/2/2
NB-341
TRX
2/0/0
DRIC-CAT40
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Node B
type(s)
RS-880
Variant
DRIC-RRH
Support of HSDPA
FD012249 - UMR5.0
Cell
HSDPA
Power/
cell [W]
1/0/0
1/0/0
12.5
1/1/0
1/1/0
12.5
1/1/1
Tab. 3.1
LPA
CAT1
RRH2
1/1/1
12.5
1/0/0
6.25
2/2/04
1/1/0
6.25
1/1/1
6.25
1/1/1/1/0/0
1/1/1/1/0/0
12.5
1/0/0
1/0/0
12.5
1/1/0
1/1/0
12.5
1/1/1
1/1/1
12.5
2/0/04
1/0/0
6.25
2/2/2
DRIC-RRH
TRX
2/0/0
RS-381
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
29
Support of HSDPA
FD012249 - UMR5.0
Node B
type(s)
NB-580
Tab. 3.1
Feature Description
Radio Subsystem
Variant
DRIC-CAT
Cell
HSDPA
Power/
cell [W]
0/0/0 : 1/0/07
0/0/0 : 1/0/07
0 : 407
0 : 18
0/0/0 : 1/1/07
0/0/0 : 1/1/07
0 : 407
0 : 18
0/0/0 : 1/1/17
0/0/0 : 1/1/17
0 : 407
0 : 18
0/0/0 : 2/0/07
0/0/0 : 2/0/07
0 : 207
0 : 18
0/0/0 : 2/2/07
0/0/0 : 2/2/07
0 : 207
0 : 28
0/0/0 : 2/2/27
0/0/0 : 2/2/27
0 : 207
0 : 38
0/0/0 : 2/0/07
0/0/0 : 2/0/07
0 : 407
0 : 28
0/0/0 : 2/2/07
0/0/0 : 2/2/07
0 : 407
0 : 48
0/0/0 : 2/2/27
0/0/0 : 2/2/27
0 : 407
0 : 68
1/0/0 : 0/0/07
1/0/0 : 0/0/07
40 : 07
1 : 08
1/0/0 : 1/0/07
1/0/0 : 1/0/07
40 : 407
1 : 18
1/1/0 : 0/0/07
1/1/0 : 0/0/07
40 : 07
2 : 08
1/1/0 : 1/1/07
1/1/0 : 1/1/07
40 : 407
2 : 28
1/1/1 : 0/0/07
1/1/1 : 0/0/07
40 : 07
3 : 08
1/1/1 : 1/1/17
1/1/1 : 1/1/17
40 : 407
3 : 38
2/0/0 : 0/0/07
2/0/0 : 0/0/07
20 : 07
1 : 08
2/0/0 : 2/0/07
2/0/0 : 2/0/07
20 : 207
1 : 18
2/2/0 : 0/0/07
2/2/0 : 0/0/07
20 : 07
2 : 08
2/2/2 : 0/0/07
2/2/2 : 0/0/07
20 : 07
3 : 08
2/0/0 : 0/0/07
2/0/0 : 0/0/07
40 : 07
2 : 08
2/0/0 : 2/0/07
2/0/0 : 2/0/07
40 : 407
2 : 28
2/2/0 : 0/0/07
2/2/0 : 0/0/07
40 : 07
4 : 08
2/2/2 : 0/0/07
2/2/2 : 0/0/07
40 : 407
6 : 08
TRX
CAT1
LPA
RRH2

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
CAT40, providing 40 W output power per cell, for FDD UMTS1900 MHz
CAT40, providing 40 W output power per cell, for FDD UMTS850 MHz
Each of these CATs can be used in combination with DRIC12-12 or DRC24-24OE.
30
Remote Radio Heads (RRHs) can only be used with DRIC24-24OE.
If the NB-420 and NB-44x are upgraded to DRIC-CAT configuration, the same configurations can be applied as for the NB-860 and NB-88x, respectively.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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 Bs other sectors.
Applies for CAT40.
Applies for CAT20.
The value in front of the colon (:) applies for cells in the FDD UMTS1900 MHz band
whereas the value behind the colon applies for cells in the FDD UMTS850 MHz band.
The value in front of the colon (:) applies for CAT40 for FDD UMTS1900 MHz whereas the value behind the colon applies for CAT40 for FDD UMTS850 MHz.
The cells which provide HSDPA service are distributed in a round-robin manner on the
available HSDPA-capable CHCs, thus resulting in an even distribution of the cells on the
appropriate CHCs. Tab. 3.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-capable CHC in HSDPA mode serves exactly one HSDPA cell
multi
Indicates that the CHC operates in HSDPA multi-cell mode, i.e. one HSDPA-capable CHC in HSDPA mode serves two or three HSDPA cells
off
Indicates that the CHC does not operate in HSDPA mode (Rel 99 traffic only)
Cell configuration
1 HSDPA-capable CHC
installed
2 HSDPA-capable CHCs
installed
3 HSDPA-capable CHCs
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
3.1
With UMR5.0 supporting HSDPA in the Node B, changes have been made to the
Node Bs hardware (HW) and software (SW) architecture. The following functional entities have been extended or newly created in the Node B to support HSDPA:
Flow control
The flow control mechanism dynamically assigns capacity to the HS-DSCH on the
Iub interface. The relevant capacity is allocated in accordance with the available
buffer space for priority queues and the current air interface capacity, for example.
HS-DSCH frame protocol (FP)
The HS-DSCH FP is responsible for
Extracting HS-DSCH capacity requests and forwarding them to the flow control
unit
Signaling flow control credits to the SRNC (serving RNC)
Controlling incoming user traffic. In other words, the Node B can potentially discard incoming user traffic if the RNC exceeds the assigned credit limits.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
31
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
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 rather than in the RNC where the scheduler for Rel 99 traffic is situated. This implementation allows for lower latency.
In general, this functional entity of the Node B is responsible for
Selecting the UEs to be served in a specific time transmission interval (TTI)
Assigning the HS-PDSCH resources to UEs
Selecting the appropriate priority queues which are to be served
Managing the HSDPA air interface resources
Selecting HARQ (hybrid automatic repeat request) processes, redundancy versions, modulation schemes, transport block sizes, and the HSDPA transmit signal
power
Priority queues
The Node Bs priority queues are buffers for the HSDPA user traffic data. By means
of the priority queues, the total amount of pending user data in the priority queues 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 status indications. On the other hand, this functional unit manages the states of these
UEs HARQ processes.
Transport block assembly
The transport block assembly unit prepares each transport block for further physical
layer processing. Preparing the transport blocks is done upon request of the scheduler. Among other things, this preparation must take into account whether the scheduler demands either initial transmission or retransmission.
Furthermore, the transport block assembly is responsible for managing both the priority queues and the retransmission buffer. This functionality, however, is implementation-dependent.
Another functionality the transport block assembly provides is cleaning up the retransmission buffer. The buffer is cleaned up if the protocol data units (PDUs) are
either successfully transmitted or dropped due to reaching the relevant time-outs.
Channel quality estimation (CQE)
The CQE combines channel quality information (CQI) and downlink (DL) transmit
power commands.
These functional entities impact on the Node Bs core controller (CC), channel coding
card (CHC), and transceiver (TRX) or DUAMCO (duplexer amplifier multicoupler), or
digital radio interface card (DRIC). The majority of the above-mentioned functional units,
however, is located in the CHC. Therefore, a new HSDPA-capable CHC must be installed in the Node B if HSDPA is to be supported. Thus, one of the following two possible 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)
32
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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 HSPDSCH 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-capable CHCs.
However, multiple radio cells can be processed on one HSDPA-capable CHC.
With this release, complete HSDPA signal processing for all radio links of a Node B
must be performed by one single type of CHC. Thus, simultaneous operation of
HSDPA on both a CHC96 and an hs-CHC is not supported.
If at least one hs-CHC is mounted in a Node B, the HSDPA processing will only be
performed on the hs-CHC(s).
Those CHCs performing HSDPA support only the normal or the large cell mode.
3.1.1
Modifications of the Node Bs Hardware

HSDPA requires a new type of CHC capable of handling both 3GPP Rel 99 traffic on
DCH and 3GPP Rel 5 HSDPA traffic on HS-DSCH. This new CHC may either be an existing 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 provide HSDPA service for up to three cells.
If both types of HSDPA-capable CHCs are installed in the same Node B, HSDPA operation will only be possible on one type, i.e. either on the hs-CHC or on the CHC96. Additionally, 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 furthermore 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) resources on TRX/DRIC stay allocated without any change.
The following general rules must therefore be applied for a Node B which is to offer
HSDPA service:
The NB-44xs and NB-88xs B-shelf provides 10 slots allowing the installation of up
to 10 CHCs. At least 1 CHC must be installed. The recommendation, however, requests the installation of at least 2 CHCs.
Any mixed operation of the CHC48, the CHC96, and the hs-CHC is supported for
the Node Bs non-HSDPA mode.
When providing HSDPA functionality to a specific radio cell, only one type of HSDPA-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.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
33
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
In UMR5.0, the HSDPA-capable CHCs support UEs of the classes 1 to 6, 11, and 12.
Additionally, HSDPA calls for UEs of categories 7, 8, 9, and 10 are set up on the HSDSCH with a performance equal to or better than that of UE category 6. For details
about UE classes, please refer to "UE Support of HSDPA" on page 46.
In this context, Tab. 3.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 possible HSDPA UEs
8 kbit/s
96
32 kbit/s
72
64 kbit/s
36
128 kbit/s
18
384 kbit/s
16
Tab. 3.3
3.1.1.1
Maximum number of HSDPA users depending on the UL RAB rate
CHC96
The existing CHC96 has already been HW-prepared for HSDPA in product releases
prior to UMR5.0. Its SW, however, is updated in order to handle HSDPA traffic in an appropriate way.
The CC OAM SW configures the CHC96 to operate in non-HSDPA mode or in HSDPA
mode. In non-HSDPA mode, no HSDPA-specific channels and functions are supported.
When operating in this mode, the CHC96s maximum performance is equal to
96 channel elements (CEs) and 144 adaptive multi-rate (AMR) equivalents (AMREQs).
These characteristics are the same as in the product release prior to UMR5.0.
When working in HSDPA mode, the CHC96 supports both normal channels (3GPP
Rel 99) and HSDPA-specific channels and functions simultaneously. Compared to the
non-HSDPA mode, no restrictions apply with regard to the maximum number of channel
elements and AMR equivalents.
The applicable baseband (BB) resources are communicated from the CHC to the CC
using the defined BB resource management procedures in each mode of operation.
3.1.1.2
hs-CHC
The newly developed hs-CHC offers the same functionality as a Rel 99-compliant CHC.
Furthermore, functionality for the support of HSDPA is provided.
Unlike the CHC96, the hs-CHC operates in only one mode supporting the processing of
both DCH bearers (Rel 99) and HSDPA. In other words, the hs-CHC simultaneously
supports HSDPA-specific channels and functions as well as normal channels. The
hs-CHCs maximum performance is equal to 96 CEs and an AMREQ of 144.
34
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
3.1.2
Support of HSDPA
FD012249 - UMR5.0
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 introduced 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, including distortions arising from non-linearities in the power amplifier (PA). Therefore, in
accordance with 3GPP standardization, the acceptable error vector magnitude for
16QAM operation is reduced to 12.5%, whereas in QPSK this value is set to 17.5%.
Compliance to the 3GPP standards is achieved with the existing RF components.
3.1.3
Modifications of Call Processing

Compared to the existing CHCs (CHC48 and CHC96 without support of HSDPA) mode
of operation, the resources are used in a different way inside the Node B. The 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 functionality 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. Additionally, 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 indicated 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.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
35
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
Resource Status Indication procedure and Audit Response procedure

These procedures functionalities are extended for HSDPA. Trigger conditions are added 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 according to the current status of HSDPA operation in the relevant cell.
As a precondition, the HSDPA-capable CHC must be HW-prepared to perform audit
procedures on HSDPA resources.
Common measurements
With regard to common measurements, an HSDPA-capable Node B supports all measurements already used in product releases prior to UMR5.0 plus the measurements
used for HSDPA. Thus, the NBAP: Common Measurement Initiation, Common Measurement 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 parameters 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
36
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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 parameters, i.e. parameters for CQI and ACK/NACK reporting as well as the number of channelization codes for both HS-PDSCH and HS-SCCH.
RL Deletion procedure
No IEs of the NBAP: RL Deletion procedure are modified for supporting HSDPA. Additional functionality, however, is provided for triggering the release of the HSDPA resources occupied for the relevant UE.
3.1.4
Modifications of the Transport on the Iub Interface and the Priority

Queue Management
This section deals with the following:
Interworking Between RNC and Node B
UTOPIA Connection Handling on the CC-BB Interface
3.1.4.1
Interworking Between RNC and Node B

HSDPA affects the interworking between RNC and Node B with respect to the control
plane, the user plane, and the transport network layer (TNL).
The feature impacts on the Iub interface control planes NBAP procedures, described in
"Modifications of Call Processing" on page 35.
The user plane of the Iub interface is responsible for transferring MAC-d protocol data
units (PDUs) from the SRNC to the Node B by means of the HS-DSCH frame protocol.
Further details about both the Iub interface user plane and the TNL are described in
"Transport Network Layer (TNL) Modifications" on page 147.
3.1.4.2
UTOPIA Connection Handling on the CC-BB Interface

In the Node B, UTOPIAs (universal test and operations physical interface for ATM) Iub
user plane provides AAL2 (ATM adaptation layer 2) connections from the RNC via the
CC to the CHCs carrying user traffic data. Both HSDPA and non-HSDPA traffic are
transferred in parallel. In comparison to previous releases, non-HSDPA traffic processing 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 message over the supervision bus to the CC if possible. The CHC will then perform an autonomous reset because no redundant HSDPA-capable CHC is available to take over
the functions necessary to maintain ongoing HSDPA calls.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
37
Support of HSDPA
FD012249 - UMR5.0
3.1.5
Feature Description
Radio Subsystem
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 subscribers.
In UMR5.0, the MAC-hs supports both interactive and background services. Furthermore, the Node Bs HW is prepared to support streaming services in future releases.
Generally, the MAC-hs provides functionalities for the following:
Handling of Parameters
Flow Control
Transmission Control
HARQ
Channel Quality Estimation
Measurements and Performance Measurement (PM) Counters
3.1.5.1
Handling of Parameters
The MAC-hs handles HSDPA-related IEs received from the RNC or sent to the RNC via
NBAP signaling. Furthermore, the MAC-hs supervises the maximum number of HARQ
retransmissions which is a vendor-settable OAM parameter for each radio cell. Adjusting 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 outdoor scenario a high value is favorable in order to serve UEs at the border of the relevant
macro cell.
Furthermore, the MAC-hs is responsible for OAM with regard to the HSDPA scheduler
type. The operator can select either a Maximum CIR (carrier- to interference-power ratio) or a Proportional Fair scheduler. For more details about the Proportional Fair
scheduler, refer to the FD012251 - Proportional Fair Scheduler for HSDPA. For information about the scheduler-related parameter in the Node Bs software, refer to "Impacts
on the LMT-Node B" on page 143.
3.1.5.2
Flow Control
The Node Bs flow control protects the priority queues from an overflow situation and
supplies the Node B with user traffic data in such a way that the throughput at the Uu
interface is maximized under the given QoS constraints.
Further details about the flow control mechanism are described in the section "Flow
Control" on page 147.
3.1.5.3
Transmission Control
The transmission control function manages the HSDPA Uu interface resources in terms
of transmission time, channelization codes, and transmit power. With regard to the
transmit power for HS-PDSCHs, on the other hand, all HS-PDSCHs of the same UE
have to be transmitted with the same power. When assigning the transmit power to the
HS-PDSCHs, the transmission control functional entity must make sure that it does not
exceed either the maximum HSDPA transmit power configured via NBAP signaling or
the transmit power available for HSDPA. Furthermore, if the scheduler decides to apply
38
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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 principle: at each time transmission interval (TTI), it selects the UE(s) for transmission in decreasing 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 throughput. Each UE reports its current CIR contained in the channel quality information (CQI)
at every TTI via the HS-DPCCH. Refer to "Channel Quality Estimation" on page 40.
The Proportional Fair scheduler, on the other hand, provides a fairer distribution of transmission bandwidth among the HSDPA users within a radio cell. Thus, the Proportional
Fair scheduler assures that all HSDPA users within this cell will benefit from the 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.
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 redundancy 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 erroneous packet.
The HARQ functionality is based on an N-channel stop and wait automatic repeat request (ARQ). The HARQ supports both chase combining and incremental redundancy.
The number of retransmission attempts is limited to a maximum value given by the corresponding 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
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
39
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
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 advance. Adding further redundant information increases the chances of error-free transmissions or retransmissions with enough errors removed to allow error correction by
means of chase combining with previous packets.
3.1.5.5

The channel quality estimation (CQE) functional unit provides an estimate of the channel 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 appropriately.
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 configuration 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 variables for PM counters. The chapter "HSDPA Performance Measurement Counters" on
page 157 provides a description of the new and modified PM counters for the support of
HSDPA.
3.1.6
Modifications of Signal Processing

With the introduction of HSDPA, signal processing in the base band, which is in general
performed by the CHC, and both DL and UL signal processing are adapted for a proper
operation of the feature.
3.1.6.1
Downlink Signal Processing

DL spreading and modulation is performed on the TRX or DRIC card which provide the
necessary functionality for DL signal processing. The CHC, on the other hand, performs
symbol rate processing and slot formatting for the DL channels. For HSDPA, the interface 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 supports 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 physical channel is the HS-PDSCH.
40
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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-DSCHs 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
channelization 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
illustrates this:
Cell mode
16QAM/QPSK modulation
QPSK-only modulation
1-cell mode
15
15
2-cell mode
15
3-cell mode
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 supported simultaneously. Independent of whether the HSDPA-capable CHC (CHC96 with
SW upgrade or hs-CHC) serves a cell in which HSDPA is enabled or not, the DPCH
symbol rate processing capacity guarantees simultaneous processing of up to
144 AMREQs on the DL.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
41
Support of HSDPA
FD012249 - UMR5.0
3.1.6.2
Feature Description
Radio Subsystem
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. Independent of
whether the HSDPA-capable CHC serves a cell in which HSDPA is enabled or not,,
each CHCs DPCH symbol rate processing capacity guarantees the simultaneous
processing of up to 144 AMREQs on the UL.
HS-DPCCH
For each UL DPCH, the HSDPA-capable CHC is capable of simultaneously
processing 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.
42
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
3.2
Support of HSDPA
FD012249 - UMR5.0
Functional Split
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 HSDSCH terminated in Node Bs MAC-hs layer is the only UTRAN transport channel not
terminated in the RNC. Using the HS-DSCH enables several users to be time-multiplexed, 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 Bs power amplifiers provide a higher linearity for 16QAM.
The main functionalities of HSDPA are concentrated on the Node Bs 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. Furthermore, 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 management. 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) Issues" on page 35, the currently installed HW can be reused for 16QAM.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
43
Support of HSDPA
FD012249 - UMR5.0
3.3
Feature Description
Radio Subsystem
With regard to operation, administration, and maintenance (OAM) of the Node B, modifications have been applied to the man-machine interface (MMI) for both the new hardware (hs-CHC) and the new software.
As regards the hardware, the front panel of the new hs-CHC serves as a direct manmachine interface for the operator by offering the following:
Front Panel Indicators
Front Panel Connectors
Manual Intervention
For details about changes in the Node Bs software, refer to "Impacts on the LMTNode B" on page 143.
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. Furthermore, the hs-CHC physically and logically controls the functionality of HSDPA upon establishment 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-CHCs 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.
3.4

Not yet applicable.
44
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
4 HSDPA Mobility
4.1
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 channeltype 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)
Interfrequency, intra-SRNC, intra-Node B handover (at channel-type-switching
from FACH to HS-DSCH)
Change of the serving HS-DSCH cell
Intrafrequency, inter-RNC (SRNC) relocation
Interfrequency/Intersystem
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
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
45
Support of HSDPA
FD012249 - UMR5.0
4.1.1.1
Feature Description
Radio Subsystem
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, interRAT 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 defined for all HS-DSCH categories. Additionally, HSDPA calls for UEs of categories 7, 8,
9, and 10 are set up on the HS-DSCH with a performance equal to or better than that of
UE category 6.
Parameter
Usage
Maximum number of HS-DSCH codes

received
To determine the number of HS-PDSCH

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

size
3GPP TS 25.306 UE Radio Access

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 49.
Tab. 4.1
46
Information defined for all HS-DSCH categories
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
4.1.1.2
Support of HSDPA
FD012249 - UMR5.0
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
DCCH
Transport channels
supported
Notes
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 +
PS BE
Tab. 4.2
DCH
Radio bearer combinations
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
47
Support of HSDPA
FD012249 - UMR5.0
4.1.1.4
Feature Description
Radio Subsystem
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 HSDPAenabled 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. Furthermore, the multiplexing option DCH + HS-DSCH is defined in 25.331 but it is not supported by early HSDPA UEs.
The multiplexing options are assigned upon RAB setup for all RABs that are HSDPAeligible if the UE supports HSDPA. The multiplexing options are not reconfigured when
the UEs 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 148.
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.
48
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
Traffic class
Interactive
Background
Tab. 4.3
4.1.1.5
Traffic handling priority
Scheduling priority indicator
1 (highest)
15
...
...
15 (lowest)
N/A
RAB parameters in the RAB ASSIGNMENT REQUEST message
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.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
49
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
M1
RAB
Establishment
RAB
RRC
Connection
Establishment
RB Type
RAB Release
207, 209
212-219
208, 210
RAB
Combination +
UE Capability
Class
AAL2/5
RLC/RB Info
M5
291, 292
Combination
Allowed/
Not Allowed
Max UE Supported
Rate for PS BE
M2
RAB Type + Rate (PS BE)

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

XXX
HS-DSCH Info
DCH
Combination
220, 221
TFCS Type
New
optional
step for
HSDPA
M3
278, 279
TFSC
DCH
Combination + Rate
M4
220, 221
DPCH Type
Fig. 4.1
202, 203
Physical CH Par
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.
50
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
DL
UL
DCCH
DTCH
DCH
DCH
HS-DSCH
DPCH
Fig. 4.2
DCCH
DTCH
DCH
DCH
DPCH
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.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
51
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
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:
di =
( x1 xi ) + ( y1 yi )
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 interface
may be much larger than 384 kbit/s. The maximum rate is limited by the UE capability
class. The maximum rate also depends on the RLC window sizes, which in turn depend
on the UEs available memory.
52
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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 default values of the TX and RX Window Size is changed from 128 to
32 for RLC Type DCCH AM. This reduces UE memory consumption by the SRBs from
12 kbit/s to 3 kbit/s, allowing more memory and hence larger window sizes for the DL
HS-DSCH.
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 occurs, the UL window size remains the same. However, a large UL window that is permanently 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.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
53
Support of HSDPA
FD012249 - UMR5.0
4.1.1.6
Feature Description
Radio Subsystem
RRC Connection State Model

Fig. 4.3 shows the RRC connection state model for HSDPA. PS streaming/conversational + 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/conversational 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
Cell_DCH +
HS-DSCH
Mobility in and
out of HSDPA
coverage area
CS RAB setup
CTS triggers
HSDPA cell
unavailable
CTS triggers
HSDPA cell
available
Cell_FACH
CS RAB setup
or release
DCH_INACTIVE
Cell_PCH
Fig. 4.3
54
UE state model for HSDPA
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
4.1.1.7
Support of HSDPA
FD012249 - UMR5.0
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 measurements are not configured. In the UL, bit rate adaptation is possible and UE measurements 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 introduction 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 measurements 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,

20, 40, 80, 160)
Period of repetition of a CQI

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
Factor
Ack-Nack repetition factor
Integer (1..4)
Number of repetitions of
ACK/NACK reports
Tab. 4.5
Power control and measurement feedback parameters (SRNC)
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
55
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
NBAP/RNSAP name
RRC name
Range
Purpose
CQI Power Offset
CQI
Integer (0..8)
Power offset used in the UL

between the HS-DPCCH
slots carrying CQI information and the associated
DPCCH
ACK Power Offset
ACK
Integer (0..8)

slot carrying HARQ ACK information and the associated DPCCH
NACK Power Offset
NACK
Integer (0..8)

slot carrying HARQ NACK
information and the associated 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.
NBAP/RNSAP name
RRC name
Measurement Power Offset POhsdsch
Tab. 4.6
Range
-6..13 dB
Purpose
Default Power offset between HSPDSCH and P-CPICH/S-CPICH.
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.
2.
3.
4.
The radio bearer combination currently contains only DCCH.

The UE supports HSDPA.
The UE is in Cell_DCH state.
At the time when the RAB assignment request is received, the UE does not have
measurements 2A, 2B, 3A or 3A active (with or without compressed mode).
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 60.
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 76. Afterward, the radio bearer translation algorithm is
called, see "Impacts on the Radio Bearer Translation" on page 49. This produces the
56
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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 55. 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 102. 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 75. Additionally, the CRNC allocates the Measurement Power Offset parameter, see "Power Control and Measurement Feedback Parameters" on page 55. 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
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
57
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
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 48
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 73.
Fig. 4.4 shows the message sequence chart for RAB setup (DCH to HS-DSCH).
58
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
UE
Support of HSDPA
FD012249 - UMR5.0
Node 1
Node B2
SRNC
Decision to establish RAB

RLs already exist
HSDPA Cell Selection
Allocate HS-DSCH RNTI
DCH to add (UL DTCH)

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

DCH Information Response
HS-DSCH FDD Information Response
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

RRC: RADIO BEARER SETUP
RRC: RADIO BEARER SETUP COMPLETE
Fig. 4.4
New H-RNTI
Downlink HS-PDSCH Iinformation
RB mapping info ->
DL HS-DSCH MAC-d flow id
Added/reconfigured DL TrCH information ->
HS-DSCH
Message sequence chart for RAB setup (DCH to HS-DSCH)
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
59
Support of HSDPA
FD012249 - UMR5.0
4.1.1.10
Feature Description
Radio Subsystem
RAB Setup Procedure from FACH to HS-DSCH

The RAB setup from FACH to HS-DSCH is triggered upon reception of a RAB assignment 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 76.
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 frequency. 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 49. 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 55. 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. Furthermore, the Node B configures the MAC-hs entity, the HARQ processes, and the
scheduler with the information received.
60
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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:
H-RNTI (from CRNC)
Within the RB mapping info IE:
Multiplexing options, see "RAB Multiplexing Options" on page 48
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).
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
61
Support of HSDPA
FD012249 - UMR5.0
UE
Feature Description
Radio Subsystem
Node B
SRNC
Decision to establish RAB on HS-DSCH

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

HS-DSCH to add (DL DTCH)
HS-DSCH RNTI
HS-PDSCH RL ID

- HS-SCCH Code Information
ALCAP Iub Transport Setup (HS-DSCH)
ALCAP Iub Transport Setup (UL DTCH)
ALCAP Iub Transport Setup (SRB)
Fig. 4.5
62
New H-RNTI
RB mapping info ->
DL HS-DSCH MAC-d flow id
HS-DSCH
Message sequence chart for RAB setup (FACH to HS-DSCH)
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
4.1.1.11
Support of HSDPA
FD012249 - UMR5.0
Channel-Type Switching from FACH to HS-DSCH

The procedure is initiated by PS RAB buffer overflow on UL or DL, see "Traffic Monitoring and Channel-Type Switching" on page 55. With channel-type switching from FACH
to HS-DSCH, an HSDPA-enabled cell is selected, see "HSDPA Mobility Handling" on
page 76. 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 Switching from FACH to HS-DSCH" on page 63. The RRC procedure, however, is the transport channel reconfiguration procedure instead of the radio bearer setup procedure.
The TRANSPORT CHANNEL RECONFIGURATION message contains the following
information:
H-RNTI (from CRNC)
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.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
63
Support of HSDPA
FD012249 - UMR5.0
UE
Feature Description
Radio Subsystem
Node B
RNC
Decision to switch PS RAB

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

HS-DSCH to add (DL DTCH)
HS-DSCH RNTI
HS-PDSCH RL ID

- 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
RRC: TRANSPORT CHANNEL RECONFIGURATION COMPLETE
Fig. 4.6
New H-RNTI
HS-DSCH
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 Monitoring and Channel-Type Switching" on page 55.
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
64
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
65
Support of HSDPA
FD012249 - UMR5.0
4.1.1.13
Feature Description
Radio Subsystem
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 49.
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 49. The SRNC
then initiates the RB reconfiguration procedure, see "Radio Bearer Reconfiguration Procedure" on page 71.
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 71.
66
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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
1
OPT
Performed if new
RAB uses RLC AM
Radio Bearer Reconfiguration

1
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

Added/reconfigured DL TrCH information
Added/reconfigured UL TrCH information
- if no mac multiplexing
- add UL/DL DCH for new DTCH
- 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)
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
67
Support of HSDPA
FD012249 - UMR5.0
4.1.1.14
Feature Description
Radio Subsystem
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).
68
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
UE
Support of HSDPA
FD012249 - UMR5.0
Node B1
Node B2
RNC
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: RADIO BEARER RELEASE COMPLETE
RRC State Indicator = DCH

Deleted DL TrCH Information (DCH)
Deleted DL TrCH Information (HS-DSCH)
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)
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
69
Support of HSDPA
FD012249 - UMR5.0
4.1.1.15
Feature Description
Radio Subsystem
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 49.
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.
UE
Node B1
Node B2
RNC
Trigger to release a RAB when

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

PS BE RAB remains and RAB
to be released was AM RLC

1
Fig. 4.10
70
Message sequence chart for RAB release from multicall
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
4.1.1.16
Support of HSDPA
FD012249 - UMR5.0
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 UEs 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 UEs 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 56 and "RAB
Release Procedure from Multicall" on page 70.
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
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
71
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
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 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.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 48 and the RLC
window size according to "Impacts on the Radio Bearer Translation" on page 49. 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 before
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 49.
72
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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
- existing RAB combination
includes only one AM RLC RAB
- 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.
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 preemption 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.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
73
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
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 processing 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 successful 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 retry 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.
74
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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.
H-RNTI duplication handling for the Node B
Available H-RNTI data in the Node B and RNC become inconsistant if NBAP messages
from the Node B/RNC do not reach their destination RNC/Node B.
Therefore, the Node B checks if a H-RNTI is a unique ID in the cell when it is requested
to setup a radio link. If the Node B detects a H-RNTI ID duplication, it rejects the setup
and sends a RADIO LINK FAILURE message to the RNC that contains all radio links of
the associated DPCH for the duplicated communication context. After that, all resources
for this communication context are removed by a subsequent radio link deletion request
and an ALCAP release from the RNC.
If the Node B does not receive a RADIO LINK DELETION REQUEST message, the
Node B sends an NBAP: RESET REQUEST message to the RNC that contains the
communication context and starts a timer. The Node B releases the call if the RNC
sends an NBAP RESET RESPONSE message or the timer expires.
In the event that no ALCAP is released after Radio Link Deletion or during Reset Procedure, the Node B sends an ALCAP REL message to the RNC. If the ALCAP RLC timer
expired, the Node B releases the ALCAP resource with RES.
Fig. 4.13 shows the the message sequence for a radio link setup. A radio link reconfiguration is handled similar.
Node B
RNC
RadioLinkRequest (H-RNTI=1)
H-RNTI=1 already
exists in the Node B
RadioLinkSetupFailure (Cause=DL radio resource not available)
RadioLinkFailure (Cause=RL already activated/allocated)

for a NBCC which has the same H-RNTI
RadioLinkDeletionRequest timer expired
ResetRequest (CommunicationContextId)
for the NBCC which has the same H-RNTIE
ResetResponse
for the NBCC which has the same H-RNTI)
Fig. 4.13
Message sequence chart for H-RNTI duplication handling
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
75
Support of HSDPA
FD012249 - UMR5.0
4.1.2
Feature Description
Radio Subsystem
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-HSDPAcapable 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 45.
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 110. 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 unchanged during the call. For more information on these parameters, for example the
Scheduling Priority Indicator IE, see "HSDPA RAB Handling" on page 45.
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:
Interfrequency, intra-SRNC, intra-Node B handover
The SRNC tries to establish HS-DSCH if the active set of the UE includes HSDPAcapable cells (Cell_DCH state) or the UE has an RRC connection to a cell where
HSDPA is supported (Cell_FACH state). Fig. 4.14 shows the related intrafrequency,
intra-SRNC, intra-Node B handover scenario.
76
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
HSDPA cell
UE
Frequency#1
UE
Serving HS-DSCH cell
Frequency#1
Node B
Fig. 4.14
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 channeltype 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 establishes HS-DSCH on that cell. Fig. 4.15 shows the related interfrequency,
intra-SRNC, intra-Node B handover scenario.
Non HSDPA cell
UE
Frequency#1
Frequency#2
HSDPA cell
UE
Frequency#1
Frequency#2
Node B
Fig. 4.15
HS-DSCH establishment if the UE is in Cell_FACH state
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
77
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem

The scenario supported upon inward mobility (DCH -> HS-DSCH) is:
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 84 is met.
Fig. 4.16 shows the related intrafrequency, intra-RNC, inter-Node B handover
scenario.
UE
Non HSDPA cell
HSDPA cell
Frequency#1
Active set
UE
Frequency#1
Active set
Fig. 4.16
Inward mobility

The scenarios supported upon HS-DSCH cell change are:
A change of the serving HS-DSCH cell is performed if the UE enters a new HSDPAcapable cell because of an active-set change and the condition described in section
"Change of the Serving HS-DSCH Cell" on page 87 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.17 and Fig. 4.18 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.
78
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
UE
HSDPA cell
Frequency#1
Active set
UE
Frequency#1
Active set
Node B
Fig. 4.17
Change of the serving HS-DSCH cell within a Node B
UE
HSDPA cell
Frequency#1
Active set
UE
Frequency#1
Active set
Node B1
Fig. 4.18
Node B2
Change of the serving HS-DSCH cell between two Node Bs
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
79
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem

The scenarios supported upon outward mobility (HS-DSCH -> DCH) are:
Intrafrequency, inter-RNC (SRNC) relocation
Interfrequency/Intersystem
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 96. Fig. 4.19 shows the related intrafrequency, intra-SRNC, inter Node B handover scenario.
UE
HSDPA cell

Non HSDPA cell
Frequency#1
Active set
UE
Frequency#1
Active set
Node B1
Fig. 4.19
Node B2
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 96
because HS-DSCH via the Iur interface is not supported. Fig. 4.20 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.
80
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
UE
HSDPA cell
Frequency#1
Active set
UE
Frequency#1
Active set
DRNC
SRNC
Fig. 4.20
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.21 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.
UE
HSDPA cell
Frequency#1
Active set
UE
Frequency#1
Active set
SRNC
Fig. 4.21
Outward mobility between two RNCs (SRNC relocation)
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
81
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
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.22 shows the related interfrequency/intersystem handover scenario.
Interfrequency handover is initiated if measurement 1A or 1C report that a cell is reserved or the setup/addition of a radio link via the DRNC is rejected because the cell is
reserved. If the UE uses HS-DSCH, channel-type switching from HS-DSCH to DCH is
performed before initiating the interfrequency handover.
UE
Non HSDPA cell
Frequency#1
Frequency#2
HSDPA cell
UE
UE
Frequency#1
Frequency#2
Node B1
Fig. 4.22
4.1.2.2
Node B2 or GSM area
Outward mobility between different frequencies/systems
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 RECONFIGURATION 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.
82
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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.
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 87. 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. PS RAB establishment while no other RAB is active
2. Channel-type switching from FACH to HS-DSCH
In UMR5.0, an HS-DSCH is not established if the UE has measurements 2A, 2B, 3A, or
3A active with or without compressed mode. HS-DSCH shall not be established since
simultaneous activation of compressed mode and HS-DSCH is not supported. Therefore, compressed mode is deactivated before the HS-DSCH is established. If the SRNC
receives event 2D/2D/2D, channel-type switching from HS-DSCH to DCH is performed
and compressed mode is activated again.
The system behavior can be improved by the optional feature UE Differentiation. The
purpose of the UE Differentiation feature is to assign power resources to HSDPA UEs
as much as possible. When establishing a PS RAB, the RNC distinguishes Release 99
UEs and Release 5 UEs. For more information see FD012254 UE Differentiation.
PS RAB establishment
In Cell_FACH state, 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.
In Idle mode and in Cell_DCH state, the load control mechanism is performed that is
known from former releases.
For information on the message sequence charts see "Message sequence chart for
RAB setup (DCH to HS-DSCH)" on page 59 and "Message sequence chart for RAB setup (FACH to HS-DSCH)" on page 62.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
83
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
Channel-type switching from FACH to HS-DSCH

If the RNC receives a traffic report that indicates an increasing traffic volume in UL or
DL, the following mechanism applies:
1. Check whether or not HSDPA is supported:
HSDPA is supported: Move to 2.
Otherwise: Load control is performed.
2. Check whether or not adjacent HSDPA cells are available and/or the current cell is
an HSDPA cell:
Adjacent HSDPA cells are available and/or the current cell is an HSDPA cell:
Move to 3.
Otherwise: Load control is performed.
3. Check whether or not UE differentiation is enabled:
UE differentiation is enabled: See FD012254 UE Differentiation.
Otherwise: Move to 4.
4. The load control algorithm is performed. Furthermore, it is checked whether or not
the selected_cell is an HSDPA cell and the UE is HSDPA-capable:
The selected_cell is an HSDPA cell and the UE is HSDPA-capable: The radio
bearer translation is called to provide a data rate for HSDPA.
Otherwise: The radio bearer translation is called to provide an initial rate.
Afterward, the cell selection mechanism is performed for UE differentiation.
For information on the message sequence charts see "Channel-Type Switching from
FACH to HS-DSCH" on page 63.
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 the UE has measurements 2A, 2B, 3A or 3A active (with or without compressed mode).
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 difference 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 the UE has measurements
2A, 2B, 3A or 3A active (with or without compressed mode).
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 difference 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
84
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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.23 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
Node B1
SRNC
Node B2
UE
Fig. 4.23
Node B1
Node B2
UE
Inward mobility
The SRNC includes all HSDPA-related parameters in the RADIO LINK RECONFIGURATION PREPARE and the TRANSPORT CHANNEL RECONFIGURATION messages since this is the first establishment of HS-DSCH and the UE and the Node B do not
have these parameters.
Fig. 4.24 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 45.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
85
Support of HSDPA
FD012249 - UMR5.0
UE
Feature Description
Radio Subsystem
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
Existing measurement related procedure

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.24
86
Message sequence chart for inward mobility
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
4.1.2.6
Support of HSDPA
FD012249 - UMR5.0
Change of the Serving HS-DSCH Cell

A change of the serving HS-DSCH cell occurs if the UE uses HS-DSCH and moves within 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 report 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 96.
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.25 shows how the serving HS-DSCH cell is moved from one radio link to another
under the control of the same Node B.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
87
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
SRNC
Node B1
Node B2
UE
Fig. 4.25
SRNC
Node B1
Node B2
UE
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.25. 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.26 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.
88
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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 thegiven activation time
Deallocate H-RNTI
(for source cell)
Fig. 4.26
Message sequence chart for an intra-Node B change of the serving HS-DSCH cell (event 1D)
Fig. 4.27 shows how the serving HS-DSCH cell is moved from one radio link to another
radio link between two different Node Bs.
SRNC
Node B1
SRNC
Node B2
Node B1
UE
Fig. 4.27
Node B2
UE
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.27. The RADIO LINK
RECONFIGURATION PREPARE message sent to the Node B which releases
HS-DSCH, that is Node B1 in Fig. 4.27, 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.27, includes all HSDPA-related
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
89
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
parameters since this is the first HS-DSCH establishment for that Node B. The HSDPArelated parameters are the same as the parameters used to configure HS-DSCH. The
TRANSPORT CHANNEL RECONFIGURATION message includes only the cellspecific 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.28 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 before the serving HS-DSCH cell was changed.
UE
Node B1
Node B2
SRNC
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)


HS-DSCH at the specified activation time
Deallocate H-RNTI
(for source cell)
Fig. 4.28
90
Message sequence chart for inter-Node B serving cell change (event 1D)
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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 consequence, 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 controlled 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 measurement 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.29 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.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
91
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
SRNC
Node B1
SRNC
Node B2
Node B1
UE
Fig. 4.29
Node B2
UE
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.30 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.
92
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
UE
Node B1
Node B2
SRNC
MEASUREMENT REPORT (Event 1A)

RADIO LINK ADDITION REQUEST
Active Set Update
RADIO LINK ADDITION RESPONSE

ACTIVE SET UPDATE

Allocate H-RNTI
(for target cell)
Serving HS-DSCH Cell Charge
RADIO LINK RECONFIGURATION PREPARE (Deletion of HS-DSCH)



HS-DSCH at the given activation time
Deallocate H-RNTI
(for source cell)
Fig. 4.30
Message sequence chart for the change of the serving HS-DSCH cell (event 1A)
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
93
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
Fig. 4.31 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
Node B1
SRNC
Node B2
Node B1
UE
Fig. 4.31
Node B2
UE
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.31, if the active set update procedure is complete.
The RADIO LINK RECONFIGURATION PREPARE message includes all HSDPArelated 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.32 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)
94
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
UE
Support of HSDPA
FD012249 - UMR5.0
Node B1
Node B2
SRNC
MEASUREMENT REPORT (Event 1C)

Active Set Update

ACTIVE SET UPDATE
RADIO LINK DELETION REQUEST
RADIO LINK DELETION RESPONSE
Deallocate H-RNTI
(for source cell)
Allocate H-RNTI
(for target cell)
HS-DSCH Reestablishment

HS-DSCH at the specified activation time
Fig. 4.32
Message sequence chart for the change of the serving HS-DSCH cell (Event 1C)
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
95
Support of HSDPA
FD012249 - UMR5.0
4.1.2.7
Feature Description
Radio Subsystem
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.
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 nonHSDPA 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/2D) 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.
If, while the UE is using HS-DSCH, measurement report 1A or 1C reports that a cell is
restricted or a RL setup/addition via the DRNC is rejected with the reason cell reserved, channel-type switching from HS-DSCH to DCH is performed before an interfrequency handover is initiated.
Fig. 4.33 shows how a new radio link is established via a new Node B while this Node B
does not support HSDPA.
96
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
SRNC
Node B1
SRNC
Node B2
UE
Fig. 4.33
Node B1
Node B2
UE
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 channeltype 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.34 shows the message sequence chart for outward mobility. For more information on the handling of the transport bearer for DTCH see "HSDPA RAB Handling" on
page 45.
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.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
97
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
UE
Node B1
Node B2
SRNC
MEASUREMENT REPORT (Event 1B/1C)
Decision to perform CTS (HS-DSCH -> DCH)

Active Set Update

ACTIVE SET UPDATE
RADIO LINK DELETION REQUEST
RADIO LINK DELETION RESPONSE
Deallocate H-RNTI
ALCAP Iub Transport Bearer Release (DCCH + DTCH)
HS-DSCH -> DCH (CTS)
RADIO LINK RECONFIGURATION PREPARE (Modification of UL/DL DTCH)
ALCAP Iub Transport Bearer Setup (UL/DL-DTCH)
RADIO BEARER RECONFIGURATION
UE can start listening to the DCH

at the specified activation time
RADIO BEARER RECONFIGURATION COMPLETE
MEASUREMENT CONTROL (Event 1D) (Release)
Fig. 4.34
98
Outward mobility (message sequence chart)
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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 another 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 45.
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 available. 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.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
99
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
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.
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.
100
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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
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 optional UE Differentiation feature is to assign power resources to
HSDPA UEs as much as possible. For more information see FD012254 HSDPA UE Differentiation.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
101
Support of HSDPA
FD012249 - UMR5.0
4.1.3
Feature Description
Radio Subsystem
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.35 illustrates those RRM
functionalities that are located in the CRNC. HSDPA admission control affects the highlighted functionalities.
Resource
Allocation
Load Control
Congestion
Control
Node B Measurem.
Control
Power Control
Admission
Control
Interfrequency
Load Control
Congestion
Control
Measurement
Reporting Control
Initial Values for

Power Control
Code Allocation,
Release
Preprocessing
Control
Restriction
Control
Fig. 4.35
Affected by HSDPA
Admission Control
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 controls 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
102
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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 regardless of whether or not waiting data exists
The decision of admission control about whether or not to admit a UE on a channel depends 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-layer-filtering (floating average) over a certain time frame.
Fig. 4.36 illustrates the interactions between admission control and code allocation including the protocols and measurements, call processing, and OAM databases in the
event of allocating or deallocating resources.
CRNC: Congestion Indication
NBAP: Common Measurement Report
CRNC
Measurement
Database
CRNC
Dynamic
Database
OAM
Database
Resource Allocation
RNSAP: Radio Link Addition Request
RNSAP: Radio Link Reconfiguration

Prepare
RNSAP: Radio Link Deletion Request

Commit
Cancel
Fig. 4.36
Deallocate Resources
Allocate Resources
RNSAP: Radio Link Setup Request
Admission
Control
Yes
RNSAP: Radio Link Setup Response
No
RNSAP: Radio Link Setup Failure
Yes
RNSAP: Radio Link Addition Response
No
RNSAP: Radio Link Addition Failure
Yes
RNSAP: Radio Link Reconfiguration Ready
No
RNSAP: Radio Link Reconfiguration Failure
RNSAP: Radio Link Deletion Response

DL Scrambling
and
Channelization
Code
Allocation/Release
Interactions between admission control and code allocation
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
103
Support of HSDPA
FD012249 - UMR5.0
4.1.3.2
Feature Description
Radio Subsystem
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 links 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, however, 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 established.
The transmitted-carrier power measurements will only be set up if HSDPA has been disabled or the Node B does not support non-HSDPA power measurements due to an upgrade 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 associated 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 situation. For details, please refer to "Congestion Control Algorithm" on page 108.
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 relevant 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 Allocation" on page 114.
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 nonHSDPA mode. "State Management" on page 110 describes the specific handling of the
measurement setup and the related error handling in more detail.
104
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
4.1.3.3
Support of HSDPA
FD012249 - UMR5.0
Admission Control in the CRNC

This section describes the handling of radio link setups, reconfigurations, and handovers 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 reestablishment 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 performed, 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
cells HSDPA channel to be located on the new cells 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 available.
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.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
105
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
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 cells capability of providing HSDPA service must be determined as described in "Code and Power Allocation"
on page 114.
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-associated 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 proceed if this IEs value is FALSE. If this condition is not fulfilled, however, admission
control rejects the setup on the HSDPA channel.
NOTE
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 apply, too.
Admission control uses several load thresholds for the different DPCHs which are required 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/background 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 applicable 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.
106
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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 during 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
HSDPA restriction control is an optional feature and, therefore, only enabled if the feature is part of the contract.
Within an HSDPA enabled network, it is expected that PS radio bearers will be established on HS-PDSCH instead of making use of the DCH.
However, the following situations lead to the preferred choice to set up a PS bearer on
the DCH:
HSDPA is not supported by the UE
The requested multicall/bearer combination is not supported by HSDPA standards
The Node B is out of resources on the CH-Card, but a retry on DCH state might be
possible
Restriction control in the CRNC thus offers the following benefits to operators:
The network operator can limit the risk that R99-capable-only-UEs or HSDPA-capable UEs not allowed on HSDPA, consume the cell capacity and thus degrade
HSDPA performance due to the lack of available resources.
Note: HSDPA can only make use of the remaining power after DPCH bearers have
been served.
Operators will also benefit that the performance for DCH users is not affected during
low HSDPA traffic periods.
For more information about this feature, refer to the feature description FD012255 Restriction Control for PS Bearers.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
107
Support of HSDPA
FD012249 - UMR5.0
4.1.3.5
Feature Description
Radio Subsystem
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 Bs admission control algorithm for dedicated channels. In UMR5.0, this admission 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 HSDPAcapable UEs as long as both the predefined thresholds for HSDPA services are not exceeded 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 nonHSDPA transmitted carrier power is used to decide about whether or not a congestion
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 resolution 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 whether 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 measurement 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
108
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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 associated 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) spreading 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 secondary 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.
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.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
109
Support of HSDPA
FD012249 - UMR5.0
4.1.4
Feature Description
Radio Subsystem
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 associated 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 is configured. This channel is configured in the
database of the RNCs backend via the hsdpa HMI command. 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 mismatch, i.e. if the Node B is not capable of HSDPA although the configuration data requires 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 resources. The current status is indicated by means of the HS-DSCH resource information. Fig. 4.37 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 HSDPA channel.
110
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
Node B
CRNC
HSDPA operational state = enabled
HSDPA channels configured,

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
HSDPA operational state = disabled
Non-HSDPA measurements
will be continued (Node B will
use its transmitted carrier
power measurements and
map these onto the nonHSDPA power measurement
report)
NBAP: Radio Link Deletion
For all affected HSDPA

channels associated with the
degraded cell
Resolution of the HSDPA

failure in the Node B
Resource status indication
operational state: enabled
Cell operational state: enabled
Fig. 4.37
Handling of resource status indications

Upon receipt 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 HSDPA channel (HS-DSCH) to disabled
Informing the operation and maintenance center (OMC) about the deactivated status of the HSDPA channel including the objects 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 procedures 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 Unrecoverable Error, new radio resources are set up on a forward access channel (FACH).
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
111
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
Otherwise, if further radio links are still active for the specific UE, the RNC initiates
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 HSDPA channel to enabled
Informing the OMC about the reactivated status of the HSDPA channel including the
its availability status
Tab. 4.7 provides an overview of the states supported by the HSDPA channel HSDSCH) and the corresponding trigger events.
HS-DSCH state/status
OST
Trigger event(s) for the relevant state combination
AVS
disabled
offline
disabled
not installed The local UTRAN cell is not available.
enabled
empty set
disabled
dependency The AVS of the related cell is failed.
disabled
failed
Tab. 4.7
This is the initial state combination. Furthermore, this

state combination is set in the event of one of the following:
- Creation of HS-DSCH object
- Deactivation of related UTRAN cell object
This state combination is set in the event of one of the

following:
- Completion of Physical Shared Channel Reconfiguration Request (PSCRR) procedure for HS-DSCH establishment
- Reception of RSI with cause HSDPA available
- Reception of audit message with cause HSDPA
available
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 unavailable
- Completion of the PSCRR (code = 0) procedure for
HS-DSCH deletion triggered by non-HSDPA power
measurement failure
Possible states of the HS-DSCH (HSDPA channel)
Furthermore, a dependency exists between the state of the HSDPA channel and the associated UTRAN cell. The state relations between these two objects are shown in
Tab. 4.8.
112
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
OST/AVS
Cell state/status
HS-DSCH
state/status
enabled/
empty set
enabled/
empty set
Both the UTRAN cell and the HS-DSCH are

available.
disabled/
failed
disabled/
dependency
The HS-DSCH depends on the UTRAN

cells availability. The UTRAN cell, in turn, is
faulty.
Note that under normal circumstances, this
state combination will not occur.
enabled/
degraded
disabled/
failed
The UTRAN cell is available, whereas a fault

occurred on the HS-DSCH. The HS-DSCHs
failure impacts on the cells state.
enabled/
degraded
enabled/
empty set
The cause which led to the cells degradation does not impact on the HS-DSCHs
state.
disabled/
offline
disabled/
offline
The cell is not available or removed and the

HS-DSCHs state depends on the cells
state! Possible trigger events are:
- Local cell not activated
- Local deactivated after previous activation
disabled/
not installed
disabled/
not installed
The HS-DSCHs state depends on the cells

state! Possible trigger events are:
- Local cell not available
- Local cell removed
- Interface failure on Iub interface
enabled/
empty set
disabled/
offline
This state combination may only occur in the

following situation:
The RNC optional feature handling indicated
the support of HSDPA and creating the
HSDPA objects was accepted.
At cell activation, however, the HSDPA support has been withdrawn.
Tab. 4.8
4.1.4.2
Trigger event(s) for the respective state

combination(s)
Dependencies between cell states and HS-DSCH states
Common Measurements
The HSDPA feature requires the introduction of new common measurements whose intention is to measure the transmitted carrier power of all codes not used for the transmission of HS-PDSCHs and HS-SCCHs. These measurements are called the NonHSDPA Transmit Power measurement. The Non-HSDPA Transmit Power measurement includes both periodic and event-triggered measurements which are initiated independently. 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
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
113
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
Transmit Power measurement, however, applies the same characteristics as the previous 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 implementation 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 channelization codes. The channelization codes spreading factors (SFs) for HS-PDSCHs and HSSCCHs 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 scrambling 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 cells primary scrambling code.
A UTRAN cells 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 HSSCCHs, is not possible if the paging channel (PCH) is mapped onto a dedicated secondary common control physical channel (S-CCPCH) in conjunction with the current allocation 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.38 provides an overview of the mapping of transport channels to their corresponding physical channels.
114
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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)

Primary Common Control
Physical Channel (P-CCPCH)
Broadcast Channel (BCH)

Forward Access Channel (FACH)
Secondary Common Control

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

Channel (HS-DSCH)
Highspeed Physical Downlink

Shared Channel (HS-PDSCH)
HS-DSCH-related Shared Control
Channel (HS-SCCH)
Dedicated Physical Control Channel (UL)
for HS-DSCH (HS-DPCCH)
Fig. 4.38
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.39 outlines this information.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
115
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
16
+ 15 * HS-PDSCH
16
....
16
16
32
32
64
128
256
Fig. 4.39
128
256
64
64
256
128
256
256
Available Code (SF = X)
128
128
256
256
64
256
256
Used Code (SF = X)
128
256
256
128
256
256
128
256
256
256
Unavailable Code (SF = X)
Basic code allocation strategy (code tree)
NOTE
Before starting the initial code allocation for the HS-PDSCH, the RNC confirms that the
HSDPA feature is enabled. This check is only performed during the setup of the cell. If
the cell has already been active when enabling the HSDPA feature, the change will only
take effect at the next cell setup procedure.
If the HSDPA feature is disabled, 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 HSPDSCH and the HS-SCCH, using the code tree (see Fig. 4.39). Furthermore, the
CRNC marks the descendant and ascendant codes of the specified codes as unavailable. To make sure that none of the code trees codes is assigned to any user, reserving
and marking is done simultaneously with the assignment of the common channel channelization codes in the code tree.
Fig. 4.40 and Fig. 4.41 show the UMR5.0 cell setup sequence. In UMR5.0, the cell setup procedure has been modified in comparison to the product release prior to UMR5.0.
116
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
Node B
RNC
- NBAP cell setup
- SysInfoUpdate SIB1,
2, 3, 11
Cell setup
Physical shared channel
reconfiguration request
alt

reconfiguration response
par
If the TPSCR expires

without any positive or
negative response, the
PSCR request will be
repeated a predefined
number (N) of times. If
the N retries expire, the
NBAP cell deletion will
be started.
2
As in UMR4.0, including
SIB5 and SIB7
Common transport channel setup

2
Common measurements setup for RTWP
Common measurement
initiation request (cell, nonHSDPA power, periodic)
alt
Common measurement
initiation response (cell, nonHSDPA power, periodic)
Common measurement
initiation request (cell, nonHSDPA power, event-triggered)
par
opt
Common measurement
initiation failure (non-HSDPA
power, periodic, cause IE)
Resource status indication (RSI)

operational state: disabled
A failure in the setup of

an event-triggered
measurement does not
have any impact on the
further procedure.
Congestion control will
then rely on periodic
measurements
4
The RSI can be
received or not
4
reconfiguration request
(number of both PDSCH
and SCCH codes = 0)
alt

reconfiguration response

Common measurements setup for transmitted carrier power
4
Fig. 4.40
If the TPSCR expires

without any positive or
negative response, the
PSCR request will be
repeated for N times. If
the N retries expire, the
NBAP cell deletion will
be started.
Periodic and eventtriggered as in UMR4.0
Setup of the HS-DSCH (part 1)
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
117
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
Node B
RNC
Common measurements setup for transmitted carrier power

4
reconfiguration failure
(cause IE)
NBAP cell deletion

4
3
2
1
reconfiguration failure
(cause IE)
par
2
Common transport channel setup
2
Common measurements setup for received total wideband power

2
Common measurements setup for transmitted-carrier power

2
1
NBAP cell deletion

2
Fig. 4.41
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 measurement can only be set up upon completion of the Physical Shared Channel Reconfiguration (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.
118
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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 HSSCCH-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 necessary resources. If establishing the Node Bs HSDPA resources fails, however, the
Node B sends an NBAP: PHYSICAL SHARED CHANNEL RECONFIGURATION FAILURE message with a cause corresponding to the failure type which occurred. Tab. 4.9
provides information about the mapping of failure types and cause values.
NOTE
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
licenses is not sufficient.
CauseRadioNetwork:
Number Of Downlink Codes Not Supported
The total amount of internal Node B

resources is not sufficient.
CauseRadioNetwork:
Node B Resources Unavailable
Tab. 4.9
Mapping of failure types and cause values
If the RNC receives neither an NBAP: PHYSICAL SHARED CHANNEL RECONFIGURATION FAILURE message nor an NBAP: PHYSICAL SHARED CHANNEL RECONFIGURATION 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 expire, 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 failures 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
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
119
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
Initiating the Non-HSDPA Transmit Power measurement (see "Common Measurements" on page 113)
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 measurement. 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 assigned 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-HSDPA 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 MOCs 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 RNCs 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 cells operational state is disabled, the operator can modify the HSDPArelated parameters or delete the MOC HSDPA to prevent HSDPA initialization at the
next cell activation. For details, refer to "Operating the Feature" on page 125.
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 obsolete 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.
120
NOTE
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!
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
4.2
Support of HSDPA
FD012249 - UMR5.0
Functional Split
This chapter describes the functional split of mobility topics with respect to HSDPA. The
following items are covered:
HSDPA RAB Handling
4.2.1
HSDPA RAB Handling

Not applicable.
4.2.2

Not applicable.
4.2.3

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.
4.2.4

Not applicable.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
121
Support of HSDPA
FD012249 - UMR5.0
4.3
Feature Description
Radio Subsystem
The introduction of HSDPA in UMR5.0 requires new parameters to configure the systems mobility part with respect to the following:
HSDPA RAB Handling
4.3.1
HSDPA RAB Handling

An additional parameter has been added to the Radio Bearer Control object for controlling channel-type switching from HS-DSCH to FACH, see Tab. 4.10.
Name
LMT-Name
Timer for the switch

from HS-DSCH to
FACH
thsdsch_fach
Tab. 4.10
Range
0 .. 65535 s
Default
Value
30 s
Description/Remarks
Period of uplink and downlink inactivity before
the PS I/B RAB is switched from HS-DSCH to
FACH0 means that inactivity is not monitored
and the connection is not switched to FACH
New parameter for the Radio Bearer Control object

A new parameter, see Tab. 4.11, has been added to the High Speed Downlink Packet
Access Channel object (MOC HSDPA) introduced in "HSDPA Code and Power Allocation and Redimensioning" on page 110.
Name
HS-DSCH Power
Offset
Tab. 4.11
LMT-Name
po_dsch
Range
-6 ..13 dB
step 0.5
Default
Value
3 dB
Description/Remarks
Default Power offset between HS-PDSCH and
P-CPICH/S-CPICH.
Note: This parameter must be set to the same
value for all cells within the same Node B.
New parameter for the High Speed Downlink Packet Access Channel object
Tab. 4.12 shows the parameters related to HSDPA measurement information. Multiple
instances are supported per RNC [0 .. 12].
Name
LMT-Name
Range
Default
Value
Description/Remarks
UE HS-DSCH Phys- ue_cate

ical Layer Category
1 ..64
UE category for HSDPA, part of UE capabilities.
CQI Feedback
Cycle k
cqi_cyclek
0, 2, 4, 8, 10,
20, 40, 80,
160 ms
4 ms
Period of repetition of a CQI measurement report
CQI Repetition Factor
cqi_rep
1 .. 4
Number of repetitions of a CQI report. Not necessary if CQI Feedback Cycle k = 0.
Tab. 4.12
122
Parameters for the HSDPA measurement information object

Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Name
Support of HSDPA
FD012249 - UMR5.0
LMT-Name
Range
Default
Value
Description/Remarks
ACK-NACK Repetition Factor
ack_nack_rep 1 .. 4
Number of repetitions of ACK/NACK reports
CQI Power Offset
cqi_po
0 .. 8
Power offset used in the UL between the HSDPCCH slots carrying CQI information and the
associated DPCCH
ACK Power Offset
ack_po
0 .. 8
Power offset used in the UL between the HSDPCCH slot carrying HARQ ACK information
and the associated DPCCH
NACK Power Offset
nack_po
0 .. 8
Power offset used in the UL between the HSDPCCH slot carrying HARQ NACK information
and the associated DPCCH
HS-SCCH Power
Offset
hsscch_po
-32 .. +31.75
dB
0 dB
Power offset of HS-SCCH relative to the pilot

bits on the DL DPCCH
Tab. 4.12
Parameters for the HSDPA measurement information object
4.3.2

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.
Name
LMT-Name
Range
Default
Value
Hysteresis
hyst1d
0 .. 7.5 dB
2 dB
by step of 0.5
Time to trigger
tmtrg1d
0, 10, 20, 40,

60, 80, 100,
120, 160,
200, 240,
320, 640,
1280, 2560,
5000 ms
Tab. 4.13
640 ms
Description/Remarks
Determines the hysteresis value
Indicates the period of time between the timing
of event detection and the timing of sending the
measurement report.
Parameter for event 1D

The Hysteresis IE is used to avoid frequent measurement reports of event 1D. Therefore, frequent change of the serving HS-DSCH cell or channel-type switching between
HS-DSCH and DCH can be avoided as well.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
123
Support of HSDPA
FD012249 - UMR5.0
4.3.3
Feature Description
Radio Subsystem

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.14 has been modified with respect to
HSDPA admission control.
Name
Reporting period for
transmitted carrier
power
Tab. 4.14
LMT-Name
mmti_tcp
Range
0.01, 0.02 ..
60, 120, 180
.. 3600 s
Default
value
10
Description
Reporting period for admission control
This parameter indicates the interval in which
periodic reports of either the non-HSDPA
transmitted carrier power (if the cell is HSDPAcapable) or the transmitted carrier power (if the
cell does not provide HSDPA service) is issued.
Admission control parameter at the LMT-RNC modified due to HSDPA

In addition, Tab. 4.15 lists the two new cell-specific parameters which are configurable
by the operator at the LMT-RNC/OMC-R to handle HSDPA admission control.
Name
Minimum SF available for PS interactive/background on
DCH in HSDPA cell
LMT-Name
minsf_hsdpa
Range
8, 16, 32
Default
value
8
Description
The minimum SF available in a specific HSDPA cell for the PS interactive/background RAB
if at least the predefined number (X) of UEs
transmit on the HSDPA channel.
NOTE:
A similar parameter (Minimum SF available)
already exists. This parameter is still used because admission control determines the maximum of both parameters if the HSDPA
condition applies. Please refer to "Restriction
Control in the CRNC for HSDPA" on page 107.
Threshold for activating rate restriction for PS

interactive/background on DCH in
HSDPA cell
Tab. 4.15
124
actrc_hsdpa
0 .. 256 UEs
If the current number of UEs on the HSDPA

channel exceeds this value in the relevant
HSDPA cell, the CRNC will apply rate restriction for the PS interactive/background RAB on
the DPCH in this cell.
If this parameters value is set to 0, one HSDPA-capable UE on the HSDPA channel suffices to start the rate restriction.
New HSDPA admission control parameters at the LMT-RNC
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
Performance measurement counters

New counters are introduced with this release to measure the following performance indicators. 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 "HSDPA Performance Measurement Counters" on page 157.
4.3.4

Each UTRAN cell can have the new High Speed Downlink Packet Access Channel object (MOC HSDPA). Multiple instances (0...1) of this object are supported per UTRAN
cell. Tab. 4.16 provides a list of those attributes featured by the MOC HSDPA with respect to code and power allocation and redimensioning.
Name
LMT-Name
Range
Default
value
Description
Number of HS-PDSCH codes
no_pdsch
1 .. 15
Available number of channelization codes for

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

Not yet applicable.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
125
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
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 RNCs and
the Node Bs 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.
5.1
With regard to UTRAN operation and maintenance, the functional descriptions are subsequently provided for
"RNC" on page 126 and
"Node B" on page 132
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
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 configuration 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 inventory data file (IDF).
126
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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. Furthermore, 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 objects 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.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
127
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
As regards the HSPRLCs 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 occurrence of a failure in the equipment subordinated to the CMUX and the failures recovery,
respectively.
In addition to these output messages, the following two existing HMI alarms are enhanced 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 congestion.
1348013 trunk_card_congestion_recovered
If the specific cards 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

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 adaptation 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; however, 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 Equipment 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 information about the HSDST and HSPRLC cards is added to the following HMI output messages:
1348004 card_block_complete
1348005 card_unblock_complete
1348006 trunk_card_to_be_blocked
5.1.1.3

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
128
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
The first two items refer to cells. All new attributes are embedded in one new MOC representing 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 provides 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.
2.
3.
4.
Creation of the cell

Creation of the highspeed downlink shared channel (HS-DSCH) in a cell
Modification of OAM parameters via RC/LMT
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 125.
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 disabled/offline. Otherwise, if the HS-DSCH is set up in the Node B by means of the
NBAP: Physical Shared Channel Reconfiguration procedure, the MOCs 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 110 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 RECONFIGURATION 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.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
129
Support of HSDPA
FD012249 - UMR5.0
Previous OST/AVS
Feature Description
Radio Subsystem
Current OST/AVS
RNC-FE alarm
MOC
Remark
Alarm content
disabled/offline
Cell
No alarm
Upon creation of the cell/HSDSCH, the OST/AVS values

are set to the initial values.
disabled/offline
disabled/not installed
Cell
66537 - ranLocalCellNotAvailable
Either the local cell is not announced or the interface to

the Node B is interrupted.
disabled/offline
Cell
Local cell available The cell alarm is cleared.
disabled/offline
disabled/failed
Cell
66536 - ranCellNotOperational
Cell activation failed.
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

alarm is output.
enabled/empty_set
disabled/failed
Cell
66536 - ranCellNotOperational
A cell failure occurred.
enabled/empty_set
enabled/degraded
Cell
No alarm
This transition is only possible if the HS-DSCH fails.

Thus, an HS-DSCH alarm exists.
disabled/offline
HS-DSCH
No alarm
Upon creation of the HSDSCH, the OST/AVS values

are set to the initial values.
disabled/offline
HS-DSCH
No alarm
The HS-DSCHs state depends on the cells state/status. Therefore, a cell alarm is
sufficient.
disabled/offline
HS-DSCH
No alarm
The HS-DSCHs state depends on the cells state/status. Therefore, a cell alarm is
sufficient.
disabled/offline
disabled/failed
HS-DSCH
HS-DSCH inopera- This alarm is output if the HSble

DSCH setup in the Node B
fails.
disabled/failed
disabled/offline
HS-DSCH
No alarm

alarm is output.
disabled/failed
enabled/empty_set
HS-DSCH
HS-DSCH operable
The existing alarm is cleared.
enabled/empty_set
disabled/offline
HS-DSCH
No alarm

alarm is output.
Tab. 5.2
130
State transitions and generated alarms during normal operation (RNC-FE)
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Previous OST/AVS
Support of HSDPA
FD012249 - UMR5.0
Current OST/AVS
RNC-FE alarm
MOC
Remark
Alarm content
enabled/empty_set
disabled/failed
HS-DSCH
HS-DSCH inopera- An HS-DSCH failure ocble

curred.
enabled/empty_set
disabled/dependency
HS-DSCH
No alarm
disabled/dependency
disabled/offline
HS-DSCH
No alarm
disabled/dependency
enabled/empty_set
HS-DSCH
No alarm
Tab. 5.2
This transition is only possible if the cell fails. Thus a cell

alarm already exists.
The cell changes from disabled/failed to enabled/

empty_set. Therefore, the
cell alarm is cleared.
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
MOC
disabled/offline
Cell
Remark
Alarm content
No alarm
disabled/not installed Cell
66537 - ranLocalCellNotAvailable
disabled/failed
Cell
66536 - ranCellNotOperational The cell had reported inoperability

before.
enabled/empty_set
Cell
No alarm
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 inoperability before.
enabled/empty_set
HS-DSCH
No alarm
This is the default state.
disabled/dependency HS-DSCH
No alarm
This state/status combination depends on a cell failure where a cell

alarm exists.
Tab. 5.3
This is the default state.
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 SWs point of view. This HSDPA flag, however, can only be switched (from HSDPA disabled to HSDPA enabled and vice versa)
by Siemens AG/NEC service staff.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
131
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
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 modifications in terms of:
Optional Feature Handling Within the Node B
5.1.2.1
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 Bs remote inventory management, the
new hs-CHC represents an ob-RIU object.
The Node Bs initial trigger to set up HSDPA operation is the configuration of the localCellE managed object instances (MOIs) in the database, thus either enabling or disabling HSDPA for a particular UTRAN cell. At system start-up, the Node B then evaluates
each instances current configuration and triggers the setup of an HSDPA-capable CHC
in HSDPA mode according to the rules listed below. This implementation avoids timeconsuming 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 installed.
2. If no such hs-CHC is installed but 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
132
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
SHARED CHANNEL RECONFIGURATION FAILURE message containing the appropriate probable cause information.
NOTE
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 functionality is currently implemented for Rel 99 cells, as well. An example is provided in
table 3.2 on page 31.
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 extended 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 CHCs 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 providing 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 3GPPs point of view, call context migration is not supported.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
133
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
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 Indication (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-DSCHs combination of operational state/availability status
(OST/AVS) being set to disabled/failed. The affected cells 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

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

The Node Bs call processing functionality is extended for the support of HSDPA. Furthermore, 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 LMTNode B" on page 143.
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 principle of pay-as-you-grow is applied.
HSDPA data throughput license
The HSDPA data throughput license specifies the peak data throughput of HSDPA traffic which may be processed by one Node B. One license corresponds to a peak data
throughput of 2.4 Mbit/s (per cell). The total number of licenses (N) defines a Node Bs
total peak data throughput peakDataThroughputNodeB as a multiple of 2.4 Mbit/s. In other words, peakDataThroughputNodeB = N * 2.4 Mbit/s, where N may be in the range
from 0 to 60.
A maximum of six HSDPA data throughput licenses can be applied to a particular cell,
thus allowing a maximum capacity of 14.4 Mbit/s per cell.
The licenses have to be distributed equally to all HSDPA-capable localCellE managed
objects of one Node B. The following gives an example for a 1/0/0 and a 1/1/1 configuration, assuming three (3) licenses have been purchased:
1/0/0 configuration
All licenses are applied to only one cell (one localCellE). The peak data throughput
in this single cell therefore is 7.2 Mbit/s.
134
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
1/1/1 configuration
Each of the three localCellE MOs has to be equipped with exactly one HSDPA data
throughput license. Therefore, the peak data throughput in each cell is 2.4 Mbit/s.
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 procedure. The calculation is performed according to the following algorithm:
peakDataThrough
=
putNodeB
numberOf
Codes ( i )
i=1
modulation
0.48 Mbit s
Scheme ( i )
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 factors 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 throughput, i.e. if peakDataThroughputNodeB > peakDataThroughputNodeB, the Node B will reject 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 becomes effective after a license update of one of the CCs.
5.2
Functional Split
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
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
135
Support of HSDPA
FD012249 - UMR5.0
5.3
i
Feature Description
Radio Subsystem
NOTE
The command lines, GUI windows, and MOC names provided below are only assumptions, as their syntax is subject to change.
Both the RC and the LMTs support the changes in the network elements (NEs) information 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 graphical 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 attributes, 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 releases.
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 handled 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
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 143) and N2LocalCellE (see "LocalCellE" on
page 144) have been modified.
136
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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 157, 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 corresponding operations.
HMI
command
hsdpa
hsrrm
hsrc
Tab. 5.4
Operation
Sub-item
Description
cre
Creates a new instance
del
Deletes an existing instance
mod
Modifies an existing instance
view
Displays the instances settings
view
st
Displays the state information of

an HSDPA channel instance
cre
del
mod
Modifies an existing instance
view
Displays the instances settings
cre
del
view
Displays an instances settings
New CLI commands
hsdpa
The new CLI hsdpa command has been introduced to set, modify, and control the parameters 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.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
137
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
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
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 Channel 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
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. Additionally, HSDPA calls for
UEs of categories 7, 8, 9, and 10 are set up on the HS-DSCH with a performance equal
to or better than that of UE category 6.
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.
Parameter name
ue_cate
not applicable
UE HS-DSCH physical layer category

All UE category types, i.e. 1 to 12, are supported.
cqi_cyclek
Channel quality information (CQI) feedback

cycle k
cqi_rep
CQI repetition factor
ack_nack_rep
ACK-NACK repetition factor
cqi_po
CQI power offset
ack_po
ACK power offset
nack_po
NACK power offset
Tab. 5.6
138
Default value
Parameters for the hsrrm command
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
Parameter name
hsscch_po
Tab. 5.6
Default value
3
HS-SCCH power offset
Parameters for the hsrrm command
hsrc
The new hsrc command controls the RAB combination control data. Tab. 5.7 lists the
hsrc-related parameters, which are all new.
Parameter name
Default value
rab1
psib
Radio access bearer #1
ul_rate1
64 kbit/s,
384 kbit/s
Uplink rate for radio access bearer #1
Tab. 5.7
Parameters for the hsrc 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
command.
5.3.2.2
Modified CLI Commands

In addition to the new CLI commands, existing RNC-BE CLI commands have been modified 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 commands:
ifmrms
rbc
dlcc
cell adc
eqp
bldp d2
atrk
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.8.
Parameter name
Default value
hyst1d
Hysteresis for event 1D
tmtrg1d
640
Time to trigger for event 1D
Tab. 5.8
New parameters for the ifmrms command
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
139
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
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.9.
Parameter name
thsdsch_fach
Tab. 5.9
Default value
30
Timer for the switch from HS-DSCH to FACH
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.
With regard to configuration alignment, this command is not influenced because no parameter is changed. The relevant configuration data is therefore included in the configuration 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 cells admission control for HSDPA
calls. Tab. 5.10 provides the relevant information.
Parameter name
Default value
minsf_hsdpa
Minimum available spreading factor for the

PS Interactive/Background RAB on a DCH in
an HSDPA cell
actrc_hsdpa
Threshold to activate the rate restriction for

the PS Interactive/Background RAB on a
DCH in an HSDPA cell
Tab. 5.10
New parameters for the cell adc command
eqp
With regard to the new hardware (HSDST and HSPRLC), new parameters have been
added to the eqp command to configure both cards.
140
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
The following operations of the eqp command have been enhanced with parameters for
HSDST and HSPRLC:
cre eqp (Eqiupment)
del eqp (Equipment)
dgt eqp (Diagnosis)
rst eqp (SP Reset)
dload eqp (Firmware Downlaod)
view eqp (Firmware Download)
ulock eqp (Administrative State Control)
lock eqp (Administrative State Control)
Tab. 5.11 provides the parameters related to the new hardware.
Parameter name
hsdpsijkl
This parameter specifies HSDST cards, with

ij: switch port number (00; fixed)
kl: line slot number of the Line Switch Module LSM (00 to 31)
hprlcijklm
This parameter specifies HSPRLC cards, with

ij: cell multiplexer (CMUX) group number (00 to 93)
k: CMUX number within CMUX group (0 to 3)
lm: logical card number (00 to 11)
Tab. 5.11
New parameters for the eqp command
bldp d2
added to the bldp d2 command to configure both cards physical location data (D2 data).
Parameter name
hsdpsijkl

hprlcijklm

Tab. 5.12
New parameters for the bldp d2 command
atrk
added to the atrk command to handle the traffic the RNC automatically configures on
these cards.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
141
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
Parameter name
hsdpsijkl

hprlcijklm

Tab. 5.13
5.3.2.3
New parameters for the bldp d2 command
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:
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 fault occurred due to a fault report by the firmware.
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:
Lock the defective card.
Diagnose the defective card. If the result of the diagnosis is OK, reset the equipment and place it in service by unlocking it.
Otherwise, if the diagnosis result is NG, replace the defective card.
After having inserted a new card, plug&play has to be executed automatically by
the software.
Unlock the card, thus placing it in service again.
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.14 lists the modified output messages in relation to the affected
objects:
HMI output message
Affected object
Hsdps
0053268 cmuxbl_fault
0053269 cmuxbl_fault_recovery
Tab. 5.14
142
Hprlc
Hsdpa
Modified output messages at the LMT-RNC
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
HMI output message
Affected object
Hsdps
Hprlc
1152001 state_of_device_changed
1293001 ast_changed_notifcation
Hsdpa
1329100 nbap_failure
1348004 card_block_complete
1348005 card_unblock_complete
1348006 card_reserved_to_be_blocked
Tab. 5.14
5.3.3
Modified output messages at the LMT-RNC
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) required for a particular local cell.
NOTE
The following attribute names are mere proposals but not yet fixed!
Ch
Tab. 5.15 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
assignedHsdpaCells
not applicable
This new attribute indicates the IDs of those

UTRAN cells which are served by an HSDPAcapable CHC.
chType
[0;2]
Granularity: 1
This attribute specifies the type of CHC which

is used. The attributes values indicate the following:
- 0: CHC48
- 1: CHC96
- 2: hs-CHC
The attribute value for the hs-CHC has been
added in UMR5.0.
Tab. 5.15
New and modified attributes related to the Ch object in the Node B
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
143
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
LocalCellE
Tab. 5.16 lists the new attributes related to the LocalCellE MOC. These attributes can
be configured by the operator.
Attribute name
Attribute description
hsdpaCapable
[0;1]
Granularity: 1
This attribute enables HSDPA processing for

a specific UTRAN cell. The attributes values
indicate the following:
- 0: HSDPA processing disabled
- 1: HSDPA processing enabled
hsdpaModulation
[0;1]
Granularity: 1
This attribute specifies the modulation

scheme to be applied in a specific cell. This
parameter becomes relevant only if HSDPA
support has been enabled for this cell. The attributes values indicate the following:
- 0: QPSK is exclusively applied
- 1: 16QAM and QPSK are applied
All HSDPA-capable LocalCellE managed object instances (MOIs) of one Node B have to
apply the same modulation scheme.
hsdpaScheduler
[0;1]
Granularity: 1
This parameter specifies which type of scheduler is to be used in a given HSDPA-capable

cell. The values indicate the following:
- 0: User-throughput-optimized scheduler
(Proportional Fair scheduler)
- 1: Cell-throughput-optimized scheduler
(Maximum CIR scheduler)
All HSDPA-capable LocalCellE managed object instances (MOIs) of one Node B have to
use the same scheduler type.
Tab. 5.16
5.3.4
Value range
New attributes related to the LocalCellE object in the Node B
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 corresponding model of the OTS core is updated. In accordance with this update, the database 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 introduced 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.
144
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
5.3.4.2
Support of HSDPA
FD012249 - UMR5.0
Extensions for South-Bound Export Operations

The bulk generation of the RNCs and the Node Bs 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 Bs bulk mode exclusively supports setting the HSDPA-support
flag and the modulation scheme of the LocalCellE object. Managing the HSDPA-support 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 consistent.
It is unavoidable to accept this complication because the Node Bs hardware must know
the number of cells supporting HSDPA at startup. Therefore, 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-consuming. 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 Bs 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 support (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.
5.3.4.4
Extensions for North-Bound Interfaces

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
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
145
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
interfaces are equivalent to those for the south-bound export operations mentioned
above.
5.4
NOTE
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

Not yet applicable.
146
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
6 Transport Network Layer (TNL) Modifications

6.1
HSDPA provides for higher data throughput per UE and per cell. In comparison to Release 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 interfere 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 comparison to conventional Release 99 networks. However, because of the increased bandwidth 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 carries 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 (ADCH), DCCH, and HS-DSCH. Thus, HSDPA support adds the requirement for 1 additional 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 interface, 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 requests 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.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
147
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
Refilling the priority queues is subject to the availability of bandwidth on the Iub interface:
if conventional traffic does not leave enough bandwidth, HSDPA buffers may temporarily 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, Interval, 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 transport 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 symbol 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 priorities are:
highest
low
lowest
UDI, PS Streaming, AMR voice

PS best-effort traffic on DCH
HS-DSCH
These assignments make sure that HSDPA traffic has least priority.
148
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
6.2
Support of HSDPA
FD012249 - UMR5.0
Functional Split
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 37.
6.3
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 resources. This command has been expanded to also offer parameters related to the traffic that is automatically assigned to HSDST and HSPRLC cards.
The new hardware also introduces the following new HMI output messages:
0053299 hsdps_fault
The existing alarms
0053268 cmuxbl_fault
0053269 cmuxbl_fault_recovery
are modified to also cover faults in the HSPRLC hardware. For details see "Fault management".
6.4

Not yet applicable.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
149
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
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
7.1
The UMTS air interface (i.e. Uu interface) is the radio interface between the UMTS terrestrial 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 layer.
Fig. 7.1 provides an overview of the Uu interfaces protocol architecture. Service access
points are marked as ellipses.
150
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
C-plane signaling
U-plane information
GC
Nt
DC
Duplication avoidance
GC
Nt
DC
UuS boundary
control
L3
PDCP
control
control
control
control
RRC
PDCP
L2/PDCP
BMC
RLC
RLC
RLC
RLC
RLC
RLC
RLC
L2/BMC
RLC
L2/RLC
Logical Channels
MAC
L2/MAC
Transport Channels
PHY
Fig. 7.1
L1
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 measuring 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 RLs SIR in the RL set. If Rx diversity is used, the RLs SIR must be the linear
summation of each Rx antennas 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.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
151
Support of HSDPA
FD012249 - UMR5.0
7.1.2
Feature Description
Radio Subsystem

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/multicast control, the packet data convergence protocol, and the media access control remain 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 unacknowledged mode (UM). Both LI values are utilized to inform the UE that the RLC signaling 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 5compliant UMR5.0, whereas in Rel 99, both LIs were forbidden on the UL. Possible interworking 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.
7.1.3

The following functionalities of the Uu L3 are affected by this Rel 5-compliant Uu modification:
Radio resource control protocol
Identification of a UEs 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
152
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
(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 extension. Both parts are release-specific.
Critical extensions
When receiving a message including a critical extension which is not comprehended, the receiver will entirely reject this message and inform the sender about the rejection. 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 extensions, enhanced functionalities are required for the RNCs Rel 5 RRC decoder and encoder:
Rel 5 RRC decoder
The Rel 5 decoder is able to comprehend Rel 99, Rel 4, and Rel 5 UL messages including all non-critical extensions introduced up to Rel 5. The decoded messages
will then be sent to the RNC application.
Rel 5 RRC encoder
RNCs Rel 5 RRC encoder must take care of the UEs release in order to use the
appropriate message structure and include only those critical and non-critical extensions supported by the relevant release. Thus, the inclusion of protocol extensions
from releases later than the UEs 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
MEASUREMENT CONTROL (Rel 4 structure with Rel 5 non-critical extensions)
7.1.3.2
Identification of a UEs 3GPP Release

The Rel 5 RNC obtains the UEs supported protocol version upon one of the three
events listed below. In each of these cases, the relevant messages include the new Access 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 CAPABILITY INFORMATION. This information always includes Rel 99 capabilities and optionally Rel 4 and/or Rel 5 capabilities, depending on the UEs release.
The RNC then stores this information for the duration of the call.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
153
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
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 capabilities 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: RELOCATION 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 transferred 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 received, or, alternatively, whether the Access Stratum Release Indicator IE is absent, 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 release 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 relocation 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 interactive/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
154
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
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
Setup or release of a second PS BE RAB
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 supported 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 COMMAND 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 inform 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-
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
155
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
tive RLs in non-diversity cells (individual RL mode NONE) in Rel 99, this change simply
means a clarification of the UEs behavior.
i
7.1.3.4
NOTE
In UMR5.0, Node Bs are not capable of providing Tx diversity for HSDPA cells.
RRC Error Handling

The RNCs RRC handling of unknown, unforeseen, and erroneous protocol data is compliant to 3GPP TS 25.331, section 9. The RNCs 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.
7.2
Functional Split
Not applicable.
7.3
Not applicable.
7.4

Not applicable.
156
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
8 HSDPA Performance Measurement Counters

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

Procedure related measurements
Number of attempted Radio
Link Establishments for HSDSCH
hsEstabAtt
This measurement provides the number of attempted

HS-DSCH radio link establishments for each HSDPA
cell.
The measurement is based on two events:
Transmission of NBAP: RADIO LINK SETUP REQUEST by the RNC to the Node B, in order to set up a
new HS-DSCH (FACH to HS-DSCH), and
Transmission of NBAP: RADIO LINK RECONFIGURATON PREPARE message by the RNC to the Node B, in
order to set up a new HS-DSCH (DCH to HS-DSCH).
Only messages initiated from the CRNC are taken into
account.
Number of unsuccessful Radio Link Establishments for

HS-DSCH per failure cause
101
hsEstabFail
This measurement provides the number of unsuccessful

HS-DSCH radio link establishments for each cell. For
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 REQUEST message which requests setup of a new HSDSCH
Receipt of NBAP: RADIO LINK RECONFIGURATION
FAILURE sent by the Node B in response to a RADIO
LINK RECONFIGURATION PREPARE message in order to set up a new HS-DSCH
Non-receipt of NBAP: RADIO LINK SETUP RESPONSE or NBAP: RADIO LINK RECONFIGURATION
READY (expiration of the appropriate timer) in response
to a RADIO LINK SETUP REQUEST or RADIO LINK
RECONFIGURATION PREPARE which is sent from the
RNC to the Node B, and indicates an attempt to establish
a new HS-DSCH.
Only trigger conditions related to the CRNC are considered. Failure causes are defined in 3GPP TS25.433.
Tab. 8.1
New Performance Management counters
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
157
Support of HSDPA
FD012249 - UMR5.0
Measurement
Feature Description
Radio Subsystem
mtype
Shortname
Purpose
Subsystem related measurements

Number of attempted
HSPRLC allocations
72
hsprlcAllocAtt
This counter collects the number of Resource Allocation

Requests of HSPRLC.
Number of successful
HSPRLC allocations
73
hsprlcAllocSucc
This counter collects the number of successful Resource

Allocation Requests of HSPRLC.
Number of attempted HSDST 74

allocations
hsdstAllocAtt
This counter collects the number of Resource Allocation

Requests of HSDST.
Number of successful
HSDST allocations
75
hsdstAllocSucc
This counter collects the number of successful Resource

Allocation Requests of HSDST.
HSPRLC / PRLC throughput

rate
192
hsprlcThrou
ghputRate
This measurement indicates the used channels/bandwidth on HSPRLC and PRLC, given as a percentage of
the maximum performance. Thus, it indicates the RNC
hardware utilization by HSDPA service. Several subcounters are defined for average and maximum values
for UL and DL direction.
HSDST throughput rate
193
hsdstThroughputRate
This measurement provides the HSDST throughput rate,

given as a percentage of the HSDST maximum performance. Several sub-counters are defined for average and
max values for UL and DL direction.
135
hsTranstoFachAtt

switches from HS-DSCH to the CELL_FACH state for
each cell.
Number of unsuccessful tran- 136

sitions from HS-DSCH to
CELL_FACH state per failure
cause
hsTranstoFachFail

switches from HS-DSCH to the CELL_FACH state for
each cell per cause.
Number of attempted transitions from CELL_FACH state

to HS-DSCH
137
hsTransFromFachAtt

switches from CELL_FACH state to HS-DSCH for each
cell.
Number of unsuccessful tran- 138

sitions from CELL_FACH
state to HS-DSCH per failure
cause
hsTransFromFachFail

switches from CELL_FACH state to HS-DSCH for each
cell per cause.
RRC connection state management

Number of attempted transitions from HS-DSCH to
CELL_FACH state
RAB assignment
Number of unsuccessful radio bearer reconfigurations
per failure cause
92
rbReconfFail This counter records the number of unsuccessful radio

bearer reconfigurations.
Measurements performed on Node B

HSDPA Cell measurement functions
Tab. 8.1
158
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Measurement
Support of HSDPA
FD012249 - UMR5.0
mtype
Shortname
Purpose
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 maximum number of HS-PDSCH codes per cell. Only TTIs
where HS-PDSCH codes have been transmitted are considered. 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 MAChs PDU bits including MAC-hs header.
The cell throughput is measured every 10 seconds in
kbit/s. At the end of the granularity period, the mean, minimum, and maximum values are provided.
HARQ NACK ratio
hsNackRatio
This counter serves for monitoring the system performance and validation of HS-PDSCH/HS-SCCH power control mechanism.
The measurements records contain the sum of all not acknowledged data transmissions (including re-transmission). These are compared 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

sources
Tab. 8.1
Shows the mean and maximum base band load for HSDPA resources per cell during the complete granularity period.
This counter informs about HSDPA resources, in addition
to the existing base band (BB) usage ratio counters. The
BB usage ratio reflects the utilized resources per NodeB
with regard to the licensed resources, whereas the BB
usage ratio for HSDPA is related 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
99
uuTransmCarrierPwr
Modification
UE quantity measurements
Transmitted carrier power
Tab. 8.2
Besides TCP the Non HSDPA TCP is

available for HSDPA cells. Thus, power
consumption of HSDPA users and nonHSDPA users can be separately determined.
Modified Performance Management counters
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
159
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
Measurement
Mean number of bearer services per cell related
Tab. 8.2
mtype
Shortname
Modification
152
bearService- HS-DSCH is added to the range of obperCell

jects considered by this counter.
This measurement provides the mean
number of bearer services per cell.
Modified Performance Management counters

Additionally, the existing PM counters
Number of success bearer service establishments per cell related (mtype=155)
Mean number of bearer services on lub (mtype=156)
are modified to take 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
into account. By means of the PM counters
Number of unsuccessful RAB establishments per RAB (per failure clause)
(mtype=118)
Number of UTRAN initiated RAB releases per RAB (per release clause)
(mtype=125)
Number of CN initiated RAB releases per RAB (per release clause) (mtype=126)
further RAB types can now be measured.
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.
8.2
Functional Split
PM counters operate in the network element. They are set up by the OMC or the LMTRNC / LMT-NB. The measurement result files can be uploaded to the LMT or the OMC.
From there, they can be transferred to the OTS for further processing.
8.3
The new performance counters are configured using the existing commands and GUI
windows on the LMT-RNC or the LMT-NB and the OMC.
8.4

Not yet applicable.
160
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
9 Operating HSDPA
Not yet applicable.
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
161
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
10 Abbreviations
16QAM
3GPP
AAL2
AAL5
AC
ACK
AGC
ALCAP
ALS
AMR
AMREQ
ARQ
AST
ATM
AVS
BB
BE
BLSC
BMC
BRA
CAC
CAPEX
CAT
CC
CCH
CE
CHC
CID
CIR
CLI
CmCH-PI
CMP
CMUX
CN
CQE
CQI
CRC
cRNC
CRNC
CS
CTS
DBMS
DCCH
DCH
DHT
162
16 Quadrature Amplitude Modulation

3rd Generation Partnership Project
Asynchronous Transfer Mode Adaptation Layer 2
Asynchronous Transfer Mode Adaptation Layer 5
Admission Control
Acknowledged (message)
Automatic Gain Control
Access Link Control Application Part
Alarm State
Adaptive Multi-Rate
AMR Equivalents
Automatic Repeat Request
Administrative State
Asynchronous Transfer Mode
Availability Status
Baseband
Best Effort
Broaden Line Switch Controller
Broadcast/Multicast Control
Bit-Rate Adaptation
Connection Admission Control
Capital Expenditure
Combined Amplifier and Transceiver
Core Controller
Common Channel
Channel Element
Channel Coding Card
Call Identifier
Carrier- to Interference-Power Ratio
Command Line Interface
Common Transport Channel - Priority Indicator
Composite/Decomposite
Cell Multiplexer
Core Network
Channel Quality Information
Cyclic Redundancy Check
Classical Radio Network Controller (based on UMR2.0 HW)
Controlling Radio Network Controller
Circuit-Switched
Channel-Type Switching
Database Management System
Dedicated Control Channel
Dedicated Channel
Diversity Handover Trunk
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
DL
DLCC
DPCCH
DRIC
DRNC
DSCP
DSL
DSP
DTCH
DUAMCO
E1
eRNC
ETSI
FACH
FP
FW
GMUX
GTP
GPRS
GUI
HARQ
HCS
HMI
HMO
hs-CHC
HSDPA
HS-DPCCH
HS-DSCH
HS-DSCH FP
HSDST
HS-PDSCH
HSPRLC
HS-SCCH
HW
I/B
ID
IDF
IE
IMA
IP
ISO
ITU
Iu
Iub
Iur
J1
L1
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Downlink
Downlink Common Channel
Dedicated Physical Control Channel
Digital Radio Interface Card
Drift Radio Network Controller
Differentiated Services Code Point
Digital Subscriber Line
Digital Signal Processor
Dedicated Traffic Channel
Duplexer Amplifier Multicoupler
European Plesiochronous Digital Hierarchy Signal Level 1
RNC with Enhanced Capacity and Connectivity
European Telecommunications Standards Institute
Forward Access Channel
Frame Protocol
Firmware
GTP Multiplexer
GPRS Tunneling Protocol
General Packet Radio Service
Graphical User Interface
Hybrid Automatic Repeat Request
Hierarchical Cell Structure
Human-Machine Interface
Hardware Managed Object
Highspeed Channel Coding Card
Highspeed Downlink Packet Access
Highspeed Dedicated Physical Control Channel
Highspeed Downlink Shared Channel
Highspeed Downlink Shared Channel Frame Protocol
Highspeed Downlink Shared Channel Trunk
Highspeed Physical Downlink Shared Channel
Highspeed Packet Radio Link Controller
Highspeed Shared Control Channel
Hardware
Interactive/Background (radio access bearer)
Identifier
Inventory Data File
Information Element
Inverse Multiplexing for Asynchronous Transfer Mode
Internet Protocol
International Standard Organization
International Telecommunications Union
Interface between an RNC and the Core Network
Interface between an RNC and a Node B
Interface between two RNCs
Japanese Plesiochronous Digital Hierarchy Signal Level 1
Layer 1
163
Support of HSDPA
FD012249 - UMR5.0
Feature Description
Radio Subsystem
L2
L3
LI
LMT
LPA
LSM
MAC
MAC-d
MAC-hs
MMI
MOI
MOC
NACK
NBAP
OAM
OC-3
OMC
OSI
OST
OTS
P-CPICH
PDCP
PDU
PM
PRLC
PRM
PRS
PS
PSCR
QoS
QPSK
QRS
RAB
RACH
RAT
RB
RC
Rel 4
Rel 5
Rel 99
REP
RF
RL
RLC
RNC
RNC-BE
RNC-FE
164
Layer 2
Layer 3
Length Indicator
Local Maintenance Terminal
Linear Power Amplifier
Line Switch Module
Medium Access Control
Medium Access Control - Dedicated
Medium Access Control - High Speed
Managed Object Instance
Managed Object Class
Not Acknowledged (message)
Node B Application Part
Operation and Maintenance
Optical Carrier Level 3
Operation and Maintenance Center
Open System Interconnect
Operational State
Operation and Maintenance Tool Set
Primary Common Pilot Channel
Packet Data Convergence Protocol
Protocol Data Unit
Performance Measurement
Packet Radio Link Controller
Packet Radio Link Control Module
Procedural State
Packet-Switched
Physical Shared Channel Reconfiguration
Quality of Service
Quadrature Phase Shift Keying
Quality Requirement Specification
Radio Access Bearer
Random Access Channel
Radio Access Technology
Radio Bearer
Radio Commander
3GPP Release 4
3GPP Release 5
3GPP Release 99
Repeater
Radio Frequency
Radio Link
Radio Link Control
Radio Network Controller
Radio Network Controller - Back End
Radio Network Controller - Front End
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Feature Description
Radio Subsystem
Support of HSDPA
FD012249 - UMR5.0
RNL
RNS
RNTI
RRC
RRH
RRM
RSI
RTWP
SBS
S-CPICH
SDU
SF
SIR
SN
SRB
SRB2
SRNC
SRNS
STM-1
STTD
SW
T1
TB
TINF
TNL
TOS
TRNC
TRX
TTI
UDP
UE
UL
UM
UMR
UMTS
UTOPIA
UTRAN
Uu
VC
VCI
VP
VPI
WCMP
WLAN
WLSC
Siemens AG:
A50016-G5000-Z180-3-7618
NEC Corporation:
ND-59083-180(E)-03
Radio Network Layer

Radio Network Subsystem
Radio Network Temporary Identify
Radio Resource Control
Remote Radio Head
Radio Resource Management
Resource Status Indication
Received Total Wideband Power
Standby State
Secondary Common Pilot Channel
Signaling Data Unit
Spreading Factor
Signal to Interference Ratio
Switching Network
Signaling Radio Bearer
Signaling Radio Bearer 2
Serving Radio Network Controller
Serving Radio Network Subsystem
Synchronous Transport Module Level 1
Space Time Transmit Diversity
Software
North American Plesiochronous Digital Hierarchy Level 1
Transport Bearer
Trunk Interface
Transport Network Layer
Type of Service
Target Radio Network Controller
Transceiver (Transmitter/Receiver)
Time Transmission Interval
User Datagram Protocol
User Equipment
Uplink
Unacknowledged Mode
UMTS Mobisphere Release
Universal Mobile Telecommunications System
Universal Test and Operations Physical Interface for ATM
UMTS Terrestrial Radio Access Network
Radio Interface between the UTRAN and the User Equipment
Virtual Channel
Virtual Channel Identifier
Virtual Path
Virtual Path Identifier
Wideband Composite/Decomposite
Wireless Local Area Network
Wideband CMP and Line Switch Controller
165

SF012249 Architecture Support of HSDPA

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SF012249 Architecture Support of HSDPA

Uploaded by

Copyright:

Available Formats

UTRAN

Important Notice on Product Safety

The same text in German:

Copyright (C) Siemens AG / NEC Corporation 2005.

Reason for Update

Reason for Update

Chapter New HSPRLC Card.

Reason for Update

First issue for new release.

HSDPA cell configurations for NB-580 have been

added. The power reduction for 16QAM is no longer

Mounting limitation taken into account: HSPRLC and

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

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

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

Modifications within UTRAN Operation and Maintenance . . . . . . . . . . . .

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

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

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

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

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

The following UE mobility scenarios are supported within UMR5.0:

Modifications within UTRAN OAM

2 Modifications in the RNC Hardware and Software Architecture

HSDPA Protocol Stack in UTRAN

Protocol stack of HSDPA for UTRAN

HSDPA Traffic Within the RNC

To/From Iub Interface

Cards and traffic routes for HSDPA

Protocol stack within the RNC on HSDPA traffic route

New/Modified RNC Hardware

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

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

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

In addition to the new hardware modified FW is necessary:

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

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

New HSDST Card

RLC Layer (Total of UL and DL)

The RNC is always equipped with 2

HSDST card specification

New HSPRLC Card

RLC Layer (Total of UL and DL)

Target power consumption

HSPRLC card specification

Modified WLSC Firmware

Modified CMUX/CMUXE Firmware

HS-DSCH Frame Protocol

HS-DSCH DATA FRAME

Refer to 3GPP TS 25.435.

Priority of HS-DSCH DATA FRAME.

RLC PDU size is 336 bits or 656 bits.

83 is the maximum number of MAC-d

User Buffer Size

Dont care Is to be ignored by Node B.

This IE is optional and only present

Refer to 3GPP TS 25.435.

HS-DSCH DATA FRAME Header IE

HS-DSCH CONTROL FRAME

0 = stop transmission, 2047 = unlimited. The number of MAC-d PDU

CAPACITY ALLOCATION message

HS-DSCH Repetition Period

0 = unlimited repetition period.

CAPACITY ALLOCATION message