Hsdpa Technical Description

UTRAN

Technical Description

Radio Subsystem

HSDPA - UMR5.0

DRAFT

2

f Important Notice on Product Safety

DANGER - RISK OF ELECTRICAL SHOCK OR DEATH - FOLLOW ALL INSTALLATION INSTRUCTIONS.

The system complies with the standard EN 60950 / IEC 60950. All equipment connected to the system mustcomply with the applicable safety standards.Hazardous voltages are present at the AC power supply lines in this electrical equipment. Some components mayalso have high operating temperatures.Failure to observe and follow all installation and safety instructions can result in serious personal injuryor 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 angeschlossenenGeräte müssen die zutreffenden Sicherheitsbestimmungen erfüllen.In diesen Anlagen stehen die Netzversorgungsleitungen unter gefährlicher Spannung. Einige Komponentenkönnen auch eine hohe Betriebstemperatur aufweisen.Nichtbeachtung der Installations- und Sicherheitshinweise kann zu schweren Körperverletzungen oderSachschäden führen.Deshalb darf nur geschultes und qualifiziertes Personal das System installieren und warten.

Caution:This equipment has been tested and found to comply with EN 301489. Its class of conformity is defined in tableA30808-X3247-X910-*-7618, which is shipped with each product. This class also corresponds to the limits for aClass 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 isoperated in a commercial environment.This equipment generates, uses and can radiate radio frequency energy and, if not installed and used in accor-dance with the relevant standards referenced in the manual “Guide to Documentation”, may cause harmful inter-ference to radio communications.For system installations it is strictly required to choose all installation sites according to national and local require-ments concerning construction rules and static load capacities of buildings and roofs.For all sites, in particular in residential areas it is mandatory to observe all respectively applicable electromagneticfield / 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 purposescould violate the rights of their owners.

Copyright (C) Siemens AG / NEC Corporation 2005.

Issued by:Siemens AG, Communications, Hofmannstrasse 51, 81359 München, Germany andNEC 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.

3

Reason for UpdateSummary:First issue for new release.

Details:

Chapter/Section Reason for Update

All First issue for new release.

Issue HistoryIssue

Number

Date of issue Reason for Update

1 04/2005 First issue for new release.

4

5

This document consists of 163 pages. All pages are issue 1.

Contents

1 Short Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.1 In General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2 Customer Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3 Interworking / Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.4 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Modifications in the RNC Hardware and Software Architecture . . . . . . . . . 132.1 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.1 HSDPA Protocol Stack in UTRAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.2 HSDPA Traffic Within the RNC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.1.3 New/Modified RNC Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.1.3.1 New HSDST Card. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.1.3.2 New HSPRLC Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.1.3.3 Modified WLSC Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.1.3.4 Modified CMUX/CMUXE Firmware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.1.4 HSDST Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.1.4.1 MAC-d. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.1.4.2 HS-DSCH Frame Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.1.4.3 HS-DSCH DATA FRAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.1.4.4 HS-DSCH CONTROL FRAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.1.4.5 Handling of the Initial Capacity Allocation IE . . . . . . . . . . . . . . . . . . . . . . . 242.1.4.6 Internal FP (HSDPA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.1.5 HSPRLC Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.1.5.1 IP/UDP/GTP-U . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.1.5.2 Packet Data Convergence Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.1.5.3 Radio Link Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.1.5.4 Internal FP and Internal FP (HSDPA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2 Functional Split . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.3 Man-Machine Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.4 Operating the Feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3 Modifications in the Node B Hardware and Software Architecture . . . . . . . 273.1 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.1.1 Modifications of the Node B’s Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . 323.1.1.1 CHC96 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.1.1.2 hs-CHC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.1.2 Modifications of Radio Frequency (RF) Issues . . . . . . . . . . . . . . . . . . . . . . 333.1.3 Modifications of Call Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.1.4 Modifications of the Transport on the Iub Interface and the Priority Queue

Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.1.4.1 Interworking Between RNC and Node B. . . . . . . . . . . . . . . . . . . . . . . . . . . 353.1.4.2 UTOPIA Connection Handling on the CC-BB Interface . . . . . . . . . . . . . . . 363.1.5 The MAC-hs Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.1.5.1 Handling of Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.1.5.2 Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6

3.1.5.3 Transmission Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.1.5.4 HARQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.1.5.5 Channel Quality Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.1.5.6 Measurements and Performance Measurement (PM) Counters . . . . . . . . . 383.1.6 Modifications of Signal Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.1.6.1 Downlink Signal Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.1.6.2 Uplink Signal Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.1.7 Modifications of Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2 Functional Split. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2.1 Core Controller (CC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2.2 Channel Coding Card (CHC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2.3 Repeater (REP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2.4 Transceiver (TRX) or Digital Radio Interface Card (DRIC) . . . . . . . . . . . . . 413.3 Man-Machine Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.3.1 Front Panel Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.3.2 Front Panel Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.3.3 Manual Intervention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.4 Operating the Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4 HSDPA Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.1 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.1.1 HSDPA RAB Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.1.1.1 UE Support of HSDPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.1.1.2 RAB Eligibility for HSDPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.1.1.3 Radio Bearer Combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.1.1.4 RAB Multiplexing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.1.1.5 Impacts on the Radio Bearer Translation. . . . . . . . . . . . . . . . . . . . . . . . . . . 474.1.1.6 RRC Connection State Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.1.1.7 Traffic Monitoring and Channel-Type Switching . . . . . . . . . . . . . . . . . . . . . 534.1.1.8 Power Control and Measurement Feedback Parameters . . . . . . . . . . . . . . 534.1.1.9 RAB Setup Procedure from DCH to HS-DSCH . . . . . . . . . . . . . . . . . . . . . . 544.1.1.10 RAB Setup Procedure from FACH to HS-DSCH . . . . . . . . . . . . . . . . . . . . . 584.1.1.11 Channel-Type Switching from FACH to HS-DSCH . . . . . . . . . . . . . . . . . . . 614.1.1.12 Channel-Type Switching from HS-DSCH to FACH . . . . . . . . . . . . . . . . . . . 624.1.1.13 RAB Setup Procedure from HS-DSCH to DCH . . . . . . . . . . . . . . . . . . . . . . 644.1.1.14 RAB Release Procedure from HS-DSCH to DCH . . . . . . . . . . . . . . . . . . . . 664.1.1.15 RAB Release Procedure from Multicall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.1.1.16 RRC Connection Reestablishment Procedure. . . . . . . . . . . . . . . . . . . . . . . 694.1.1.17 Radio Bearer Reconfiguration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 694.1.1.18 SRNS Relocation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.1.1.19 RAB Setup Procedure from CCH to DCH and DCH to DCH . . . . . . . . . . . . 704.1.1.20 Pre-emption and Interaction with Admission Control . . . . . . . . . . . . . . . . . . 714.1.1.21 Allocation of H-RNTI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.1.2 HSDPA Mobility Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.1.2.1 Scenarios for Mobility Handling of HS-DSCH . . . . . . . . . . . . . . . . . . . . . . . 734.1.2.2 MAC-hs Reset and Loss of Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.1.2.3 Measurement Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.1.2.4 HS-DSCH Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

7

4.1.2.5 Inward Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.1.2.6 Change of the Serving HS-DSCH Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844.1.2.7 Outward Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934.1.2.8 DRNC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964.1.2.9 Error Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964.1.2.10 UE Differentiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 984.1.3 HSDPA Admission Control and Congestion Control. . . . . . . . . . . . . . . . . . 994.1.3.1 Radio Resource Management (RRM) Issues . . . . . . . . . . . . . . . . . . . . . . . 994.1.3.2 Load, Power, and Code Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014.1.3.3 Admission Control in the CRNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024.1.3.4 Restriction Control in the CRNC for HSDPA. . . . . . . . . . . . . . . . . . . . . . . 1044.1.3.5 Admission Control in the Node B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1064.1.3.6 Congestion Control Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1064.1.3.7 Integration of the Admission Control Algorithm for HSDPA . . . . . . . . . . . 1084.1.4 HSDPA Code and Power Allocation and Redimensioning . . . . . . . . . . . . 1084.1.4.1 State Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1084.1.4.2 Common Measurements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1114.1.4.3 Code and Power Allocation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1124.1.4.4 Modification and Deletion of HSDPA Resources . . . . . . . . . . . . . . . . . . . 1184.2 Functional Split . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1194.2.1 HSDPA RAB Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1194.2.2 HSDPA Mobility Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1194.2.3 HSDPA Admission Control and Congestion Control. . . . . . . . . . . . . . . . . 1194.2.4 HSDPA Code and Power Allocation and Redimensioning . . . . . . . . . . . . 1194.3 Man-Machine Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1204.3.1 HSDPA RAB Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1204.3.2 HSDPA Mobility Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1214.3.3 HSDPA Admission Control and Congestion Control. . . . . . . . . . . . . . . . . 1224.3.4 HSDPA Code and Power Allocation and Redimensioning . . . . . . . . . . . . 1234.4 Operating the Feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

5 Modifications within UTRAN Operation and Maintenance . . . . . . . . . . . . 1245.1 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1245.1.1 RNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1245.1.1.1 Equipment Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1245.1.1.2 Transport Network Layer Management . . . . . . . . . . . . . . . . . . . . . . . . . . 1265.1.1.3 Radio Network Layer Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1265.1.1.4 Optional Feature Handling Within the RNC . . . . . . . . . . . . . . . . . . . . . . . 1295.1.2 Node B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1305.1.2.1 Equipment Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1305.1.2.2 Transport Network Layer Management . . . . . . . . . . . . . . . . . . . . . . . . . . 1325.1.2.3 Radio Network Layer Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1325.1.2.4 Optional Feature Handling Within the Node B . . . . . . . . . . . . . . . . . . . . . 1325.2 Functional Split . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1345.3 Man-Machine Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1345.3.1 Impacts on the RC GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1345.3.2 Impacts on the LMT-RNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1355.3.2.1 New CLI Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

8

5.3.2.2 Modified CLI Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395.3.2.3 New Output Messages at the LMT-RNC . . . . . . . . . . . . . . . . . . . . . . . . . . 1405.3.2.4 Modified Output Messages at the LMT-RNC . . . . . . . . . . . . . . . . . . . . . . . 1405.3.3 Impacts on the LMT-Node B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1415.3.4 OAM Tool Set (OTS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1425.3.4.1 Extensions for South-Bound Import Operations and OTS Core . . . . . . . . 1425.3.4.2 Extensions for South-Bound Export Operations . . . . . . . . . . . . . . . . . . . . 1435.3.4.3 Consistency Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1435.3.4.4 Extensions for North-Bound Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 1445.4 Operating the Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

6 Transport Network Layer (TNL) Modifications . . . . . . . . . . . . . . . . . . . . . . 1456.1 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1456.1.1 Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1456.1.1.1 Priority Queue Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1466.1.2 QoS Mechanism. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1466.2 Functional Split. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1476.3 Man-Machine Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1476.4 Operating the Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

7 Air Interface (Uu) Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1487.1 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1487.1.1 Changes on the Uu Interface Layer 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1497.1.2 Changes on the Uu Interface Layer 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1507.1.3 Changes on the Uu Interface Layer 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1507.1.3.1 Impacts on the Radio Resource Control (RRC) Protocol. . . . . . . . . . . . . . 1507.1.3.2 Identification of a UE’s 3GPP Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1517.1.3.3 Impacts of 3GPP Rel 5 on Previously Supported Features . . . . . . . . . . . . 1537.1.3.4 RRC Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1547.2 Functional Split. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1547.3 Man-Machine Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1547.4 Operating the Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

8 HSDPA Performance Measurement Counters. . . . . . . . . . . . . . . . . . . . . . 1558.1 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1558.2 Functional Split. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1588.3 Man-Machine Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1588.4 Operating the Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

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

10 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

9

1 Short DescriptionThis chapter serves as short introduction to the High Speed Downlink Packet Access(HSDPA) feature. The chapter is subdivided into the following sections:• In General• Customer Benefits• Interworking / Dependencies• Prerequisites

1.1 In GeneralWithin UMTS, the acceptance of mobile data services strongly relies on high datathroughputs, high user peak rates with minimum delay. HSDPA (High Speed DownlinkPacket Access) is the breakthrough UMTS feature-set which satisfies highest capacitydemands thus providing the prerequisite for broadband services.

HSDPA is specified in the 3GPP Release 5 Standard. On the downlink, the HSDPAstandard implemented in UMR5.0 refers to a shared control channel (HS-SCCH) and ashared data-bearing channel (HS-DSCH). The data-bearing channel is known as “HS-DSCH”. Key characteristics of HSDPA are:• A downlink only service, the uplink service remains unchanged.• A packet data service. The network allocates resources for transmitting packets over

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

The HSDPA key principles are:• Scheduling in the time domain (2 ms) and code domain (15 parallel codes) . This

reduces latency and improves the peak rate.• Adaptive Modulation and Coding (QPSK and 16 QAM) which leads to higher data

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

HARQ (Hybrid Automatic Repeat Request) is an implicit link adaptation technique. InHARQ, link layer acknowledgements are used for retransmission decisions. ForHSDPA, 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 15HS-PDSCHs. The uplink channel is the HS-DPCCH which carries the feedback informa-tion from each HSDPA-capable UE in the active set.

HSDPA terminal capabilities extend from 0.9 Mbit/s up to 14 Mbit/s. The HSDPA capa-bility is independent of Rel 99-based capabilities. If the HS-DSCH has been configuredfor the terminal, however, the DCH capability in DL is limited to the value provided bythe terminal.

HSDPA Mobility

The High Speed Downlink Shared Channel (HS-DSCH) is a common transport channelthat is shared by several UEs in the same cell. The MAC-hs functionality of the Node Bperforms scheduling of UEs on a per cell basis. Therefore, the UE receives the HS-DSCH of one cell and can receive DCHs of multiple cells.

The following UE mobility scenarios are supported within UMR5.0:• HS-DSCH establishment (when the UE is in Cell_DCH or Cell_FACH state)

– Intrafrequency, intra-SRNC, intra-Node B handover

10

– Interfrequency, intra-SRNC, intra-Node B handover (at channel-type-switchingfrom 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– Intrafrequency, intra-RNC, inter-Node B handover

• Outward mobility (HS-DSCH -> DCH)– Intrafrequency, intra-SRNC, inter-Node B handover– Intrafrequency, inter-RNC handover– Intrafrequency, inter-RNC (SRNC relocation)– Interfrequency, intra-SRNC, inter-Node B handover

Modifications in the RNC HW/SW Architecture

By supporting HSDPA, the RNC must take care of flow control of the PS data stream.This function is performed in the HS-DSCH Frame Protocol. The higher data rates of PSdata traffic (compared to Rel 99 data rates) also require enhanced RNC data cards tocope with the throughput of high peak data rates. This has resulted in a new design oftwo additional RNC components:• HSPRLC

To terminate IP/UDP/GTP-U on the Iu side and RLC/PDCP on the Iub side. To per-form traffic monitoring, charging and ciphering.

• HSDSTTo terminate the HS-DSCH Frame Protocol and to perform flow control betweenRNC and Node B.

Modifications in the Node B HW/SW Architecture

Until now, all UTRAN Transport Channels have been terminated in the RNC. The HS-DSCH, however, is terminated by the MAC-hs layer in the Node B. This leads to a higherprocessing load within the Node B (flow control and scheduling mechanismRNC/Node B, handling of uplink feedback information). Higher traffic buffering also re-quires increased memory. Increased internal traffic and higher symbol-level processing(due to a higher data rate) must be considered. 16QAM is applied as new additionalmodulation scheme which does not require any new modulator etc. but is generated bythe already installed hardware. Power amplifiers must support a higher linearity for16QAM.

The main HSDPA functionalities are concentrated on the Node B Channel Card (CHC).Therefore, the new HSDPA support requires a SW change of the currently used CHC.For non-HSDPA usage the previous CHC version can be reused.

The current Core Controller (CC) is able to handle the higher Iub traffic, increasednumber of AAL2 connections, and higher demands for Call Processing resources. Thereis no HSDPA-specific functionality located on the CC.

Modifications within UTRAN OAM

The following HSDPA-specific items cause modifications of the UTRAN OAM area:• New cards supporting HSDPA.

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

• The packet scheduler for HSDPA data traffic is situated in the Node B, whereas thescheduler for Rel 99 data is still in the RNC.

11

• New transport channel HS-DSCH to carry user dataUsers are time-multiplexed and code-multiplexed on this channel to free resourcesduring silent periods.

• Control signaling on shared channel (HS-SCCH) that is common to a set of UEsmaking use of HSDPA. In the HSDPA-capable Node Bs, the number of HS-SCCHscan 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 withRNC-wide scope.

• Configuration of transport flow control, required for HSDPA

In order to fulfill complete Equipment Management, Transport Network Layer Manage-ment, and Radio Network Layer Management, additional Operations & Maintenancefeatures have been implemented for all UTRAN elements supporting HSDPA (eRNC,mixed configuration eRNC/cRNC, NB-420, NB-440, NB-441, NB-580, NB-860, NB-880,NB-881, NB-341, RS-880, RS-381).

The Info Models and the Databases of all network elements have been adapted to HSD-PA with additional enhancements to the Radio Commander, LMTs, and OTS.

New HMI commands are supplied in order to configure the new HSDST- and HSPRLC-cards. HSDST and HSPRLC cards can be associated with speech path equipment. NewHMI commands are therefore implemented to modify existing speech path equipmentwith regard to HSDST and HSPRLC configuration.

New performance measurements have been developed and existing Rel 99 measure-ments have been significantly enhanced.

HSDPA performance measurements will only be carried out in cells which are capableof providing HSDPA services. With UMR5.0, the HSDPA standard (3GPP Rel 5) will besupported for the first time. A new Managed Object Class is therefore introduced withUMR5.0, the HSDPA Cell.

Transport Network Layer (TNL) modifications

With HSDPA, the 3GPP principle of keeping Radio Network Layer (RNL) and TransportNetwork Layer (TNL) independent of each other is also valid. However, introducingHSDPA affects the TNL by the higher capacity demands of the air interface. The highersystem capacity with HSDPA also allows both higher data rates per user and many moreusers 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 forconversational traffic class which has stringent delay requirements. Real-time require-ments for the transport of the HS-DSCH over Iub interfaces may be lower than for thetransport of all other channels. Therefore 3GPP TS highly recommends a separation ofHSDPA traffic from other CS traffic. Because of the bursty nature of HSDPA traffic incombination with unknown traffic volume, the QoS of all traffic on the same AAL type 2path may decrease.

Air Interface (Uu) modifications

The Node B has implemented the HSDPA MAC-hs protocol, which is responsible forscheduling between terminals (UEs). Adaptive Modulation and Coding (AMC) and man-agement of data queues for each UE are some of the new air interface functionalities ofthe Node B.

12

1.2 Customer BenefitsWith UMR5.0 making use of HSDPA services, the mobile phone subscriber will experi-ence an improvement of QoS compared to Release 99 UMTS services. The improve-ments become apparent in terms of:• Peak data rate• Average data rate (i.e. packet call throughput)• Lower latency for interactive and background services• Higher availability of high data rate services

Network Operators will benefit from utilizing UMR5.0 with:• Lowest CAPEX for system capacity increase compared to other capacity-improving

technologies such as smart antennas or the installation of new Node Bs. WithUMR5.0, the Operator's costs per bit will be minimized.

• Higher system throughput, i.e. more throughput per cell due to a higher Node B ca-pacity. The Node B’s increased capacity leads to more users and, consequently,more data throughput per square kilometer.

• Higher benchmarking of UMR5.0 operators compared to Rel 99 and existing 2.5GOperators, which already offer data rates up to 384 kbit/s today.

• Enabling of new billing categories, such as mobile flat rates combined with high peakrates in order to compete with fixed network services like DSL.

• Competition with WLAN operators via outdoor coverage, security advantage, andmobility rather than indoor competition.

• Higher performance (factor 3) than CDMA2000 systems (especially important forAsian and US Markets).

1.3 Interworking / DependenciesThe introduction of HSDPA has a design impact on all UTRAN network elements. Net-work Management systems have to be adapted as well as terminals which have to bespecially designed for HSDPA purpose.

Dynamic allocation of AMR traffic and HSDPA traffic will coexist. Customers will not ex-perience significant degradations of conventional Rel 99 services by introducingHSDPA. Since Rel 99 users and HSDPA users share the channelization code tree, adegradation may occur if Rel 99 users run out of codes. The number of AMR users willnot be affected after UMR5.0 implementation.

1.4 PrerequisitesUEs have to be HSDPA-compliant. UE categories will specify the modulation schemesupported and its throughput more precisely.

13

2 Modifications in the RNC Hardware and Soft-ware Architecture

2.1 Functional DescriptionThe High Speed Downlink Packet Access (HSDPA) feature enables downlink packettransmission rates up to 14 Mbit/s on the radio interface, which may coexist with the cur-rent Rel 99 services. The PRLC and DHT cards of the current RNC HW do not have suf-ficient capacity to support the peak rate of HSDPA. Therefore, new hardware (HSDST,HSPRLC) and a new transport channel (HS-DSCH) have been introduced to enable thethroughput of higher peak data rates compared to Rel 99 data rates. The HSDST cardsupports the MAC-d entity and HS-DSCH frame protocol (FP), thus providing higherthroughput than the current DHT card (see 2.1.4 "HSDST Functionality" for details). TheHSPRLC card provides PRLC functionality with a higher throughput (see2.1.5 "HSPRLC Functionality" for details).

2.1.1 HSDPA Protocol Stack in UTRANThe protocol stack of HSDPA in UTRAN (see Fig. 2.1) introduces the HS-DSCH FP (asspecified in the 3GPP TS 25.435, ’Iub Interface User Plane Protocols for COMMONTRANSPORT CHANNEL Data Streams’) which performs the flow control taking into ac-count the throughput between the UE and the RNC. It controls transmission delay anddata discarding in UTRAN by adjusting the transmission rate at the Iub interface to thetransmission rate at the Uu interface. The HS-DSCH FP is used by the Node B to informthe RNC about the permitted transmission rate at the Uu interface. The RNC performsdata transfer at the transmission rate specified by Node B.

Fig. 2.1 Protocol stack of HSDPA for UTRAN

RLC

PDCP

ATM

AAL2MAC-hs

RLC

PDCP

MAC-hs

ATM

AAL2ATM

AAL5

GTP-U

UDP

UE Node B RNCUu Iub Iu

Phy. Phy.Phy.

HS-DSCHFP

Phy.Phy.

HS-DSCHFP

MAC-dIP

MAC-d

14

2.1.2 HSDPA Traffic Within the RNCFig. 2.2 summarizes the HSDPA traffic routed through different cards within the RNC.

Fig. 2.2 Cards and traffic routes for HSDPA

RNC

Iu

GMUX

M2C PRLC

MHC DHT HSDST

HSPRLC

DTI/MDTI

DCCH DTCH(PS)

DCCH onFACH/RACH

DTCH onFACH/RACH

DCCH onDCH

DTCHon DCH

To/From Iub Interface

Iub Interface

DTCH (UL)on A-DCH

DTCH (DL)on HS-DSCH

Iub

CMP/WCMP

CLP

E1-IMA

E1-IMA

E1E1E1

TINFfor Iub

STM-1/OC-3

DTCH (DL) on HS-DSCH

DTCH (UL) on A-DCH

DTCH on DCH (HS-DSCH to DCH)

DCCH on DCH

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

DCCH on FACH/RACH

15

In addition to Fig. 2.1, the protocol stack of each card on the HSDPA traffic route withinthe RNC is shown in Fig. 2.3.

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

2.1.3 New/Modified RNC HardwareHSDPA 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

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

ATM

AAL2

ATM

AAL2-d

Iub Iu

CMP/WCMP

RNC

GMUX

UDP

HSDST

ATM

AAL2-d

ATM

AAL2-d

HSPRLC

ATM

AAL5

IPMAC-dHS-DSCH

Internal

FP

FP(HSDPA)

ATM

AAL2-d

InternalFP

(HSDPA)

GTP-U

RLC

PDCP

UDP

ATM

AAL5

IP

GTP-U

UDP

ATM

AAL5

IP

GTP-U

16

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

Regarding the frame layout of a certain model unit two scenarios are supported(see Fig. 2.5):• Update of existing equipment• New delivery of equipment

cRNC/eRNC eRNC

E-CCPM

FAN

FAN

D-CCPM

Fuse

FAN

C-DHTM C-DHTM

FAN

Fuse

FAN

FAN

GTPM

Fuse

B-SIGM C-M2CM

B-MHM C-CMPM

D-CMPM

B-LSF C-TRKF A-PRF

D-CMPM A-PRM (Extended)

A-PRM (Extended)

FAN

B-SIGM C-M2CM

FAN

PDM

B-MHM C-DHTM

C-GTPM

H-TRKF

A-DTIM

E-CCPM

FAN

FAN

D-CCPM

PDM

D-LSF

WLSC CMUC/CMUXE HSPRLCHSDST

B-LSM C-LSM

A-PRM (Basic)

B-PRM

Modified Firmware New Hardware

17

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

FAN

SIGM M2CM

FAN

PDM

B-MHM C-DHTM

C-GTPM B-PRM

H-TRKF

A-DTIM

E-CCPM

FAN

FAN

C-LSM

D-CCPM

PDM

D-LSF

WCMP

FAN

A-HUBM

FAN

PDM

B-MHM C-DHTM

H-TRKF

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

FAN

SIGM M2CM

FAN

PDM

B-MHM C-DHTM

C-GTPM B-PRM

H-TRKF

A-DTIM

E-CCPM

FAN

FAN

C-LSM

D-CCPM

PDM

D-LSF

WCMP

FAN

A-HUBM

FAN

PDM

B-MHM C-DHTM

B-PRM

H-TRKF

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

C-PRM

HSPRLCHSDST

18

In addition to the new hardware modified FW is necessary:• Modified WLSC FW for controlling HSDST cards (see Fig. 2.6)• Modified CMUX/CMUXE FW for controlling HSPRLC cards (see Fig. 2.7)

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

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

HU

BIU

#0

TIN

F #

00

TIN

F #

01

TIN

F #

02

blan

k #0

3

TIN

F #

04

TIN

F #

05

TIN

F #

06

TIN

F #

07

TIN

F #

08

TIN

F #

10

TIN

F #

11

TIN

F #

12

TIN

F #

13

blan

k #1

4

blan

k #1

5

blan

k #1

6

blan

k #1

7

HS

DS

T #

18

blan

k #2

0

blan

k #2

1

WC

MP

#22

WC

MP

#23

blan

k #2

4

blan

k #2

5

blan

k #2

6

blan

k #2

7

WC

MP

#28

WC

MP

#29

WC

MP

#30

WC

MP

#31

HU

BIU

#1

CLK

D #

1C

LKD

#0

WLS

C #

1

LSW

#0

LSW

#1

HS

DS

T #

19

TIN

F #

09

CLK

D #

0

WLS

C #

0

WLSC HSDST

19

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

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

HU

BIU

#0

HU

BIU

#1

C1

HW

M #

0

C1

HW

M #

1

HS

PR

LC

0

HS

PR

LC

1

Bla

nk

Bla

nk

Bla

nk

Bla

nk

Bla

nk

Bla

nk

CM

UX

E #

0

Re

info

rcin

g P

late

Bla

nk

Bla

nk

10 33

Bla

nk

Bla

nk

CM

UX

E #

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

CM

UX

#0

HS

PR

LC

1

10

HU

BIU

0

CM

UX

#1

C1

HW

M 0

0

C1

HW

M 0

1

HU

BIU

1

HS

PR

LC

0

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

MU

X #

010

CM

UX

#1

C1

HW

M 0

0

C1

HW

M 0

1

A-PRM (Extended)

B-PRM C-PRM

Bla

nk

Bla

nk

Bla

nk

Bla

nk

Bla

nk

Bla

nk

Bla

nk

Bla

nk

Bla

nk

Bla

nk

Bla

nk

HS

PR

LC

1

HS

PR

LC

0

Bla

nk

Bla

nk

Bla

nk

Bla

nk

Bla

nk

Bla

nk

Bla

nk

Bla

nk

Bla

nk

CMUC/CMUXE HSPRLC

20

2.1.3.1 New 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.

Item Value Remarks

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

Peak rate 14 Mbit/s/ch RLC Layer

Maximum number ofchannels

4000 ch/card

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

Size 294x324 mm (HxW),1 slot

Target Powerconsumption

30 W

Tab. 2.1 HSDST card specification

21

2.1.3.2 New HSPRLC Card

Specification

RNC SW compatibility

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

Mounting and limitations

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

The following limitations must be considered:• HSPRLC and PRLC can be colocated in the PRM module.• HSPRLC cards can be mounted in the locations shown in Fig. 2.7, using the PRLC

slots. It is, however, not advisable to fully populate a PRM with HSPRLC cards, astheir combined throughput will exceed the capacity of the CMUX/CMUXE (approxi-mately 120 Mbit/s in RLC Layer).

2.1.3.3 Modified WLSC FirmwareWLSC cards are mounted in the C-LSM (eRNC) module (see Fig. 2.6). The modifiedWLSC FW for controlling HSDST cards can be downloaded from either LMT-RNC or RCusing HMI commands. As regards B-LSM modules (cRNC), BLSC cards must be re-placed by WLSC cards, resulting in a cRNC/eRNC mixed configuration.

2.1.3.4 Modified CMUX/CMUXE FirmwareThe 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 PRLCcards can be downloaded from either LMT-RNC or RC using HMI commands.

Item Value Remark

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

Peak rate 14 Mbit/s/ch RLC Layer

Maximum number ofchannels

2016 ch/card

Redundancy Single

Size 294x324 mm (HxW),2 slots

Target power con-sumption

50 W

Tab. 2.2 HSPRLC card specification

22

2.1.4 HSDST FunctionalityThe HSDST card only deals with HSDPA traffic. Unlike with the DHT card, DiversityHandover functionality is not provided as it is not specified in HSDPA. The HSDST cardprovides 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-dThe 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 fieldis then added. However, MAC-d multiplexing (C/T multiplexing) is not supported.

2.1.4.2 HS-DSCH Frame ProtocolThe 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 theRNC) and upon transmission of the CAPACITY REQUEST message (sent from theRNC to the Node B) the transmission rate is adjusted. The maximum transmission rateis determined by the CAPACITY given by the CAPACITY ALLOCATION message.

See 6 "Transport Network Layer (TNL) Modifications" for details about the HS-DSCH FPand the flow control mechanism.

2.1.4.3 HS-DSCH DATA FRAMEThe HS-DSCH DATA FRAME message is used to transmit MAC-d PDUs from the RNCto the Node B.

The transmitting interval of the HS-DSCH DATA FRAME message is defined by the fol-lowing IEs in CAPACITY provided by the Node B.• Maximum MAC-d PDU length• HS-DSCH Credits• HS-DSCH Interval

The minimum transmitting interval is about 2 ms. Tab. 2.3 shows the HS-DSCH DATAFRAME Header IE allowed by the HSDST.

23

2.1.4.4 HS-DSCH CONTROL FRAME

Handling of CAPACITY ALLOCATION message

The transmitting rate of HS-DSCH DATA FRAME is determined from the value of Maxi-mum MAC-d PDU Length, HS-DSCH Credits, and HS-DSCH Interval. These IEs arecontained in the CAPACITY ALLOCATION message.

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

IE Fieldlength

[bit]

Value Comment

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

Frame Type 1 0 0 = data frame

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

MAC-d PDULength

13 336, 656[bits]

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

NumOfPDU 8 1..83 83 is the maximum number of MAC-dPDUs using 336bits RLC PDU size.When using 656bits, the maximumnumber is 43.

User Buffer Size 16 Don’t care Is to be ignored by Node B.

Spare Bit 4 0 Always set to 0.

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

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

Tab. 2.3 HS-DSCH DATA FRAME Header IE

IE Field length[bit]

Value Comment

Spare Bit 4 Don't care

CmCH-PI 4 0..15

Maximum MAC-dPDU Length

13 0..5000[bits]

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

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

Tab. 2.4 CAPACITY ALLOCATION message

24

Handling of the CAPACITY REQUEST message

The CAPACITY REQUEST message is sent to the Node B by the RNC when CAPAC-ITY needs to be modified. This message is sent for each radio access bearer (RAB).Tab. 2.5 shows the CAPACITY REQUEST message set up by the HSDST card.

2.1.4.5 Handling of the Initial Capacity Allocation IEThe following two methods are available for assigning CAPACITY from the Node B tothe 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 thetransmission of the HS-DSCH DATA FRAME message. Instead, the RNC uses only CA-PACITY provided by the CAPACITY ALLOCATION message.

2.1.4.6 Internal FP (HSDPA)The Internal FP (HSDPA) is the particular frame protocol inside the RNC for HSDPAwhich transmits RLC PDUs between the HSDST and the HSPRLC. In this FP, flow con-trol is performed between the HSDST and the HSPRLC, and this FP complies with theHS-DSCH FP flow control.

HS-DSCH Repeti-tion Period

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


Value Comment

Tab. 2.4 CAPACITY ALLOCATION message


Value Comment

Spare Bit 4 Don't care

CmCH-PI 4 0..15

User Buffer Size 16 0..65535[octets]

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

Tab. 2.5 CAPACITY REQUEST message

25

2.1.5 HSPRLC FunctionalityThe new HSPRLC card has the same functionality as a PRLC except that it provides ahigher throughput and supports the internal FP for handling HSDPA traffic. This meansthat the HSPRLC is basically able to support both Rel 99 traffic and HSDPA trafficwhereas the PRLC cannot support HSDPA traffic.

The HSPRLC has the following functions:• U-Plane protocol handling:

– At the Iu interface: IP, UDP, GTP-U– At the Iub interface: PDCP, RLC, Internal FP, Internal FP (HSDPA)

• Traffic Monitoring– The information is used for Charging etc.

• QoS control– Performs marking of the DSCP (differentiated services code point) to the TOS

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

2.1.5.1 IP/UDP/GTP-URefer to the Iu interface specification 3GPP TS25.414 for the function of theIP/UDP/GTP-U in conjunction with the Iu interface.

2.1.5.2 Packet Data Convergence ProtocolThe HSPRLC’s PDCP has the following functions:• Data transfer• Header Compression

RFC-2507 IP Header Compression is supported

2.1.5.3 Radio Link ControlThe HSPRLC’s RLC has the following functions:• Segmentation/Reassembly• Concatenation• Pe-adding• Data transfer• Error correction• In-sequence delivery of upper-layer PDUs• Duplicate detection• Flow control• Protocol error detection / restoration• Ciphering• Acknowledged Mode / Unacknowledged Mode

In addition to the same function as PRLC of Rel 99, the following new functions are sup-ported by HSDPA:• 656 bit RLC-PDU size

If the RLC-PDU size is 336 bit, the peak rate of HSDPA (about 14 Mbit/s) cannot besupported because the number of MAC-d PDUs that can be included in a MAC-hsPDU is limited. Therefore, the RNC supports an RLC-PDU size of 656 bit.

SAY KIAT

Highlight

26

2.1.5.4 Internal FP and Internal FP (HSDPA)The HSPRLC deals with the Internal FP which is a protocol for transmitting data for ded-icated PS traffic between HSPRLC and DHT or MHC in contrast to the Internal FP (HSD-PA). The Internal FP as used in the HSPRLC provides the same functionality as used inthe PRLC card.

2.2 Functional Split

HSDST

Terminates HS-DSCH FP, MAC-d, and Internal FP (HSDPA).Performs traffic monitoring and flow control between RNC and Node B.

HSPRLC

Terminates IP, UDP, GTP-U on the Iu side and PDCP, RLC, Internal FP, InternalFP (HSDPA) on the Iub side. Performs traffic monitoring and QoS control.

2.3 Man-Machine InterfaceNot applicable (see chapter 5.3).

2.4 Operating the FeatureNot yet applicable.

27

3 Modifications in the Node B Hardware andSoftware ArchitectureThe 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 arecapable of processing HSDPA traffic. In the following, the NB-440 and NB-441 are re-ferred to as NB-44x. The NB-880 and NB-881 are referred to as NB-88x.

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

Node Btype(s)

Variant Cellconfiguration

HSDPAconfiguration

Power/cell [W]

Number of RF modules

TRX LPA CAT 1 RRH2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tab. 3.1 Possible HSDPA cell configurations in UMR5.0

28

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Node Btype(s)


HSDPAconfiguration

Power/cell [W]


TRX LPA CAT 1 RRH2


29

Notes:1 Available CAT modules are:• CAT20, providing 20 W output power per cell• CAT40, providing 40 W output power per cell• ngCAT, providing either 20 W or 40 W output power per cell

Each of these CATs can be used in combination with DRIC12-12 or DRC24-24OE.2 Remote Radio Heads (RRHs) can only be used with DRIC24-24OE.3 If the NB-420 and NB-44x are upgraded to DRIC-CAT configuration, the same config-

urations can be applied as for the NB-860 and NB-88x, respectively.4 Only one cell per sector supports HSDPA because UMR5.0 supports HSDPA only on

a single carrier frequency. Chosing the HSDPA cell therefore depends on the choicein the Node B’s other sectors.

5 Applies for CAT40.6 Applies for CAT20.

The cells which provide HSDPA service are distributed in a round-robin manner on theavailable HSDPA-capable CHCs, thus resulting in an even distribution of the cells on theappropriate CHCs. Tab. 3.2 provides an example of the dependencies between the• Cell configuration of HSDPA cells• Number of available HSDPA-capable CHCs• Cell mode operation of each HSDPA-capable CHC in the Node B, resulting from the

round-robin distribution, where– single

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

– multiIndicates that the CHC operates in HSDPA multi-cell mode, i.e. one HSDPA-ca-pable CHC in HSDPA mode serves two or three HSDPA cells

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

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

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

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

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

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

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

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

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

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

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

Node Btype(s)


HSDPAconfiguration

Power/cell [W]


TRX LPA CAT 1 RRH2


30

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

3.1 Functional DescriptionWith UMR5.0 supporting HSDPA in the Node B, changes have been made to theNode B’s hardware (HW) and software (SW) architecture. The following functional enti-ties have been extended or newly created in the Node B to support HSDPA:• Flow control

The flow control mechanism dynamically assigns capacity to the HS-DSCH on theIub interface. The relevant capacity is allocated in accordance with the available buff-er space for priority queues and the current air interface capacity, for example.

• HS-DSCH frame protocol (FP)The HS-DSCH FP is responsible for– Extracting HS-DSCH capacity requests and forwarding them to the flow control

unit– Signaling flow control credits to the SRNC (serving RNC)– Controlling incoming user traffic. In other words, the Node B can potentially dis-

card incoming user traffic if the RNC exceeds the assigned credit limits.– Extracting the incoming user data and putting the data into the priority queues

• SchedulerIn UMR5.0, the scheduler for HSDPA data traffic is implemented in the Node B rath-er than in the RNC where the scheduler for Rel 99 traffic is situated. This implemen-tation allows for lower latency.In general, this functional entity of the Node B is responsible for– Assigning the HS-PDSCH resources to UEs– Selecting the appropriate priority queues which are to be served– Selecting HARQ (hybrid automatic repeat request) processes, redundancy ver-

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

• Priority queuesThe Node B’s priority queues are buffers for the HSDPA user traffic data. By meansof the priority queues, the total amount of pending user data in the priority queues isvisible to the flow control unit and the scheduler.

• HS-SCCH symbol level processing unitThis functional entity performs signal processing for the HS-SCCH.

• HS-PDSCH symbol level processing unitThis functional entity performs signal processing for the HS-PDSCHs.

• HARQ controlOn the one hand, the HARQ control entity processes the connected UEs’ HARQ sta-tus indications. On the other hand, this functional unit manages the states of theseUEs’ HARQ processes.

Cell configuration 1 HSDPA-capable CHCinstalled

2 HSDPA-capable CHCsinstalled

3 HSDPA-capable CHCsinstalled

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

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

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

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

31

• Transport block assemblyThe transport block assembly unit prepares each transport block for further physicallayer processing. Preparing the transport blocks is done upon request of the sched-uler. Among other things, this preparation must take into account whether the sched-uler demands either initial transmission or retransmission.Furthermore, the transport block assembly is responsible for managing both the pri-ority queues and the retransmission buffer. This functionality, however, is implemen-tation-dependent.Another functionality the transport block assembly provides is cleaning up the re-transmission buffer. The buffer is cleaned up if the protocol data units (PDUs) areeither 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) transmitpower commands.

These functional entities impact on the Node B’s core controller (CC), channel codingcard (CHC), and transceiver (TRX) or DUAMCO (duplexer amplifier multicoupler), ordigital radio interface card (DRIC). The majority of the above-mentioned functional units,however, is located in the CHC. Therefore, a new HSDPA-capable CHC must be in-stalled in the Node B if HSDPA is to be supported. Thus, one of the following two pos-sible alternatives must be chosen for HSDPA support:• Firmware (FW) upgrade of the CHC96 (channel coding card-96)• Installation of the newly developed hs-CHC (high speed channel coding card)

General configuration rules

With respect to HSDPA as introduced in UMR5.0, the following general rules apply tothe configuration of the HSDPA-capable Node B types:• In UMR5.0, HSDPA operation is only possible on one carrier frequency per Node B.• This product release permits only symmetrical HSDPA configurations in all radio

cells on the same carrier frequency. In other words, the configured number of HS-PDSCH channelization codes and the number of HS-SCCH channelization codesmust be equal for all radio cells on a single carrier frequency.

• One single HSDPA-capable CHC performs complete HSDPA signal processing forone single radio cell. Signal processing cannot be split between several HSDPA-ca-pable CHCs.However, multiple radio cells can be processed on one HSDPA-capable CHC.

• With this release, complete HSDPA signal processing for all radio links of a Node Bmust be performed by one single type of CHC. Thus, simultaneous operation ofHSDPA 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 beperformed on the hs-CHC(s).

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

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

32

3.1.1 Modifications of the Node B’s HardwareHSDPA requires a new type of CHC capable of handling both 3GPP Rel 99 traffic onDCH and 3GPP Rel 5 HSDPA traffic on HS-DSCH. This new CHC may either be an ex-isting CHC96 whose FW is updated or a new hs-CHC.

Both types of HSDPA-capable CHCs are able to handle both HSDPA and non-HSDPAdedicated and common channels. In general, an HSDPA-capable CHC is able to pro-vide HSDPA service for up to three cells.

If both types of HSDPA-capable CHCs are installed in the same Node B, HSDPA oper-ation will only be possible on one type, i.e. either on the hs-CHC or on the CHC96. Ad-ditionally, HSDPA users of a particular cell for which HSDPA is enabled must not bedistributed on different HSDPA-capable CHCs. The HSDPA-capable CHCs are further-more currently operated in a non-redundant configuration. In other words, in the eventof a failure of the HSDPA-capable CHC, each SRNC either drops the HSDPA-relatedcall connections that are affected by the faulty CHC or switches them to DCHs by meansof channel-type switching (CTS). The Node B will then try to reconfigure the defectiveCHC for HSDPA service. In this case, however, the DL channel elements’ (CE) resourc-es on TRX/DRIC stay allocated without any change.

The following general rules must therefore be applied for a Node B which is to offerHSDPA service:• The NB-44x’s and NB-88x’s B-shelf provides 10 slots allowing the installation of up

to 10 CHCs. At least 1 CHC must be installed. The recommendation, however, re-quests the installation of at least 2 CHCs.

• Any mixed operation of the CHC48, the CHC96, and the hs-CHC is supported forthe Node B’s non-HSDPA mode.

• When providing HSDPA functionality to a specific radio cell, only one type of HSD-PA-capable CHC, i.e. either the CHC96 or the hs-CHC, is permitted. Mixed operationof both types of CHCs is not allowed in UMR5.0.

• One single HSDPA-capable CHC is able to handle up to three HSDPA cells.• For each HSDPA cell, a maximum of 1 HSDPA-capable CHC is permitted.• The total required number of CHCs depends on the traffic estimation.

In UMR5.0, the HSDPA-capable CHCs support UEs of the classes 1 to 6, 11, and 12.Additionally, these CHCs are hardware-prepared to support all classes of UEs. For de-tails about UE classes, please refer to "UE Support of HSDPA" on page 44.

In this context, Tab. 3.3 lists the maximum number of HSDPA users possible with theHSDPA-capable CHCs when a specific uplink radio access bearer is applied.

UL RAB rate AMR EQ Maximum number of HSDPA UEs possible with

CHC96 hs-CHC

8 kbit/s 1 96 96

32 kbit/s 2 48 72

64 kbit/s 4 24 36

128 kbit/s 8 12 18

384 kbit/s 16 6 9

Tab. 3.3 Maximum number of HSDPA users depending on the CHC type andUL RAB rate

33

3.1.1.1 CHC96The existing CHC96 has already been HW-prepared for HSDPA in releases prior toUMR5.0. Its SW, however, is updated in order to handle HSDPA traffic in an appropriateway.

The CHC96 is capable of working in two modes, HSDPA mode and non-HSDPA mode,where both modes are included in one SW load image. The CC OAM SW then config-ures the CHC96 to operate in the relevant mode. Changing the mode of operation re-quires a partial reset of the CHC96, i.e. only selected DSPs (digital signal processors)are reset. Since this partial reset is performed internally by the CHC96, the CC does nothave to act directly. It is therefore recommended to change the mode of operation onlywhen no calls are ongoing and no cells are set up on that CHC96. Otherwise, ongoingcalls will be lost.

In non-HSDPA mode, no HSDPA-specific channels and functions are supported. Whenoperating in this mode, the CHC96’s performance is equal to 96 channel elements(CEs) and 144 adaptive multi-rate (AMR) equivalents (AMREQs). These characteristicsare the same as in the product release prior to UMR5.0.

When working in HSDPA mode, the CHC96 supports both normal channels and HSD-PA-specific channels and functions simultaneously. As far as normal channels are con-cerned, the number of AMREQs, however, is reduced compared to non-HSDPA mode.Thus, with regard to normal channels the CHC96’s performance is equal to 96 CEs andan AMREQ of 96.

The applicable baseband (BB) resources are communicated from the CHC to the CCusing the defined BB resource management procedures in each mode of operation.

3.1.1.2 hs-CHCThe 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 ofboth DCH bearers and HSDPA. In other words, the hs-CHC simultaneously supportsHSDPA-specific channels and functions as well as normal channels. With regard to nor-mal channels the hs-CHC’s performance is equal to 96 CEs and an AMREQ of 144.

3.1.2 Modifications of Radio Frequency (RF) IssuesUntil now, the only modulation scheme used in UTRAN has been quadrature phase shiftkeying (QPSK). With UMR5.0, 16-quadrature amplidute modulation (16QAM) is intro-duced as a new modulation scheme allowing for a higher data rate. The realization of16QAM does not require any replacement or modification of the TRX or DRIC card.

Compared to QPSK, 16QAM is more sensitive to various kinds of signal distortion, in-cluding distortions arising from non-linearities in the power amplifier (PA). Therefore, inaccordance with 3GPP standardization, the acceptable error vector magnitude for16QAM operation is reduced to 12.5%, whereas in QPSK this value is set to 17.5%.Compliance to the 3GPP standards is achieved with the existing RF components by re-ducing the transmit signal power by approximately 0.7 dB. The MAC-hs scheduler con-trols the transmit power reduction. When the scheduler decides to use 16QAM, itsubstracts the necessary transmit power reduction value from the total HSDPA signalpower. The reduction of the transmit power is only applied if 16QAM is used on at leastone HS-PDSCH. The quality of DCHs does not suffer from using 16QAM.

SAY KIAT

Highlight

34

3.1.3 Modifications of Call ProcessingCompared to the existing CHC’s (CHC48 and CHC96 without support of HSDPA) modeof operation, the resources are used in a different way inside the Node B. The followingresources must therefore be distinguished with respect to UMR5.0 and HSDPA:• Resources for HSDPA downlink processing• Resources for DCH/RACH (random access channel) uplink processing• Resources for DCH/FACH (forward access channel) downlink processing

By introducing HSDPA, some NBAP (Node B application part) procedures have beenadded and others have been extended. These changes, however, do not affect the func-tionality provided in product releases prior to UMR5.0. The HSDPA feature affects thefollowing 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 invokedby the controlling RNC (CRNC) in order to configure/reconfigure/delete the resourcesprovided for HSDPA in a Node B. Optional parameters concerning both the scramblingcode (default: primary scrambling code) and channelization codes are thus provided forthe HS-PDSCH and the HS-SCCH.

The Node B starts HSDPA operation upon reception of the NBAP: PHYSICAL SHAREDCHANNEL RECONFIGURATION REQUEST message with consistent IEs. Additional-ly, an appropriate number of HSDPA licenses (see chapter 5.1.2.4 for details) must beavailable.

As regards the termination or temporary suspension of HSDPA operation, the Node Bdistinguishes between them. Terminating HSDPA operation, on the one hand, is indicat-ed by setting the number of channelization codes for both HS-PDSCH and HS-SCCH tozero. The temporary suspension of HSDPA operation, on the other hand, is indicatedwhenever the number of channeliazation codes for HS-PDSCH plus the number ofchannelization codes for HS-SCCH is greater than zero.

Resource Status Indication procedure and Audit Response procedure

These procedures’ functionalities are extended for HSDPA. Trigger conditions are add-ed to handle the same events in the context of HSDPA as defined for DCH in the lastproduct release prior to UMR5.0. The procedures’ implementation is thus extended inorder to handle the following information elements (IEs):• The “HSDPA Capability” IE reflects the result from checking the preconditions for

HSDPA operation.• The “Resource Operational State” IE and the “Availability Status” IE are set accord-

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

As a precondition, the HSDPA-capable CHC must be HW-prepared to perform auditprocedures on HSDPA resources.

35

Common measurements

With regard to common measurements, an HSDPA-capable Node B supports all meas-urements already used in product releases prior to UMR5.0 plus the measurementsused for HSDPA. Thus, the NBAP: Common Measurement Initiation, Common Meas-urement Reporting, Common Measurement Termination, and Common MeasurementFailure procedures are extended to decode additional IEs.

The transmitted carrier power is measured in the same way as for pre-HSDPA productreleases. The transfer of measurement values from the TRX/DRIC cards to the CC, inparticular, remains unchanged.

The Node B periodically measures the transmitted carrier power of all codes which arenot used for the HS-PDSCH. This measurement is performed per cell.

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

All existing functionality of these two existing NBAP procedures is also supported byUMR5.0. The implementation of these procedures is extended so that the Node B candecode the following IEs:• Parameters for Iub transport configuration of both MAC-d flows and scheduling pa-

rameters per priority queue• Radio network temporary identify (RNTI) of HS-DSCH and RL ID of HS-PDSCH• HSDPA-realated capabilities of UEs• Parameters for channel quality information (CQI) feedback and ACK/NACK• HS-SCCH power offset• Measurement power offset for CQI measurement

RL Parameter Update procedure

The NBAP: RL Parameter Update procedure is new with UMR5.0. The Node B uses thisprocedure in order to inform the RNC about the necessity to reconfigure radio parame-ters, i.e. parameters for CQI and ACK/NACK reporting as well as the number of chan-nelization codes for both HS-PDSCH and HS-SCCH.

RL Deletion procedure

No IEs of the NBAP: RL Deletion procedure are modified for supporting HSDPA. Addi-tional functionality, however, is provided for triggering the release of the HSDPA re-sources occupied for the relevant UE.

3.1.4 Modifications of the Transport on the Iub Interface and the PriorityQueue ManagementThis 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 BHSDPA affects the interworking between RNC and Node B with respect to the controlplane, the user plane, and the transport network layer (TNL).

The feature impacts on the Iub interface control plane’s NBAP procedures, described in"Modifications of Call Processing" on page 34.

36

The user plane of the Iub interface is responsible for transferring MAC-d protocol dataunits (PDUs) from the SRNC to the Node B by means of the HS-DSCH frame protocol.

Further details about both the Iub interface user plane and the TNL are described in"Transport Network Layer (TNL) Modifications" on page 145.

3.1.4.2 UTOPIA Connection Handling on the CC-BB InterfaceIn the Node B, UTOPIA’s (universal test and operations physical interface for ATM) Iubuser plane provides AAL2 (ATM adaptation layer 2) connections from the RNC via theCC to the CHCs carrying user traffic data. Both HSDPA and non-HSDPA traffic aretransferred in parallel. In comparison to previous releases, non-HSDPA traffic process-ing remains unchanged. For HSDPA traffic, each MAC-d flow is mapped onto a singleAAL2 connection. Furthermore, both the addressing scheme and the conversion fromAAL2 to AAL2d in the CC are the same as for AAL2 connections carrying DCH traffic.

In the event of a failure occurring in the HSDPA-capable CHC, the CHC will send a mes-sage over the supervision bus to the CC if possible. The CHC will then perform an au-tonomous reset because no redundant HSDPA-capable CHC is available to take overthe functions necessary to maintain ongoing HSDPA calls.

3.1.5 The MAC-hs ConceptThe 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 radiocell, efficiently utilizing the Iub interface, and guaranteeing the QoS provided to the sub-scribers.

In UMR5.0, the MAC-hs supports both interactive and background services. Further-more, the Node B’s HW is prepared to support streaming services in future releases.

Generally, the MAC-hs provides functionalities for the following:• Handling of Parameters• Flow Control• Transmission Control• HARQ• Channel Quality Estimation• Measurements and Performance Measurement (PM) Counters

3.1.5.1 Handling of ParametersThe MAC-hs handles HSDPA-related IEs received from the RNC or sent to the RNC viaNBAP signaling. Furthermore, the MAC-hs supervises the maximum number of HARQretransmissions which is a vendor-settable OAM parameter for each radio cell. Adjust-ing this parameter may become necessary in difficult radio environments. In an indoorenvironment, for example, a low value for this parameter is beneficial, whereas in an out-door scenario a high value is favorable in order to serve UEs at the border of the relevantmacro cell.

SAY KIAT

Highlight

37

3.1.5.2 Flow ControlThe Node B’s flow control protects the priority queues from an overflow situation andsupplies the Node B with user traffic data in such a way that the throughput at the Uuinterface is maximized under the given QoS constraints.

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

3.1.5.3 Transmission ControlThe transmission control function manages the HSDPA Uu interface resources in termsof transmission time, channelization codes, and transmit power. With regard to thetransmit power for HS-PDSCHs, on the other hand, all HS-PDSCHs of the same UEhave to be transmitted with the same power. When assigning the transmit power to theHS-PDSCHs, the transmission control functional entity must make sure that it does notexceed either the maximum HSDPA transmit power configured via NBAP signaling orthe transmit power available for HSDPA. Furthermore, if the scheduler decides to applythe 16QAM modulation for at least one UE, it reduces the HS-PDSCH transmit powerby a certain amount.

The transmission control functional entity includes the scheduler functionality where, inUMR5.0, either a “Maximum CIR” (carrier- to interference-power ratio) or a “ProportionalFair“ scheduler is used.

The Maximum CIR scheduler, on the one hand, works according to the following princi-ple: at each time transmission interval (TTI), it selects the UE(s) for transmission in de-creasing order of their current CIR. In other words, the UE with the best CIR is servedfirst, UEs with lower CIRs are currently blocked and served later. Thus, the MaximumCIR scheduler ensures high peak data rates as well as a maximum Node B cell through-put. Each UE reports its current CIR contained in the channel quality information (CQI)at every TTI via the HS-DPCCH. Refer to "Channel Quality Estimation" on page 38.

The Proportional Fair scheduler, on the other hand, provides a fairer distribution oftransmission bandwidth among the HSDPA users within a radio cell. Thus, the Propor-tional Fair scheduler assures that all HSDPA users within this cell will benefit from theavailability 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 setthe 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 theinitial transmission.

• Modulation schemeWhen selecting the modulation scheme, the transmission control function must takeinto account restrictions arising from UE capabilities and those which are implied bythe optional feature handling.

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

38

3.1.5.4 HARQThe hybrid automatic repeat request (HARQ) provides functionality for fast and efficientretransmission techniques and error detection. Thus, the UE calculates the cyclic redun-dancy check (CRC) of the incoming packet from the Node B. If this CRC is the same asthe one contained in the packet, an ACK (acknowledged) signal is sent to the Node B.Otherwise, NACK (not ACK) is sent, thus requesting for a retransmission of the errone-ous packet.

The HARQ functionality is based on an N-channel stop and wait automatic repeat re-quest (ARQ). The HARQ supports both chase combining and incremental redundancy.The number of retransmission attempts is limited to a maximum value given by the cor-responding OAM parameter (see subsection Handling of Parameters, above).

Applying stop and wait ARQ, the transmitter persists on the transmission of the currentdata block until the UE has successfully received this block. To avoid idle times,N parallel processes (“channels”) are set up, thus allowing different processes transmitin 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” ARQbut stored. If the retransmitted packet is erroneous, too, the previous and the currentpacket are combined, thus attempting to recover from the errors. Eventually, either thepacket is received without an error, or the UE recovers from the error by means of chasecombining, or the maximum number of retransmissions is exceeded. In the latter case,error recovery is left to higher-protocol levels.

As regards the incremental redundancy, the transmitter adds previously not transmittedredundant information to the packet if the receiver detected an error in this packet in ad-vance. Adding further redundant information increases the chances of error-free trans-missions or retransmissions with enough errors removed to allow error correction bymeans of chase combining with previous packets.

3.1.5.5 Channel Quality EstimationThe channel quality estimation (CQE) functional unit provides an estimate of the chan-nel quality of a specific UE in the currently scheduled time transmission interval (TTI) forthe transmission control function. This estimate allows the transport block size and thenumber of HS-PDSCH channelization codes for the relevant UE to be selected appro-priately.

The HS-PDSCH radio channel quality is estimated for each UE using the HS-DSCH. Atleast 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 powerfor the associated DCH and, on the other hand, the channel quality information (CQI)periodically reported by the UE on the HS-DPCCH. The RNC determines the configura-tion parameters for CQI reporting and provides them to both UE and Node B.

3.1.5.6 Measurements and Performance Measurement (PM) CountersIn addition to the above features, the MAC-hs provides functionality for updating the var-iables for PM counters. The chapter "HSDPA Performance Measurement Counters" onpage 155 provides a description of the new and modified PM counters for the support ofHSDPA.

SAY KIAT

Highlight

SAY KIAT

Highlight

39

3.1.6 Modifications of Signal ProcessingWith the introduction of HSDPA, signal processing in the base band, which is in generalperformed by the CHC, and both DL and UL signal processing are adapted for a properoperation of the feature.

3.1.6.1 Downlink Signal ProcessingDL spreading and modulation is performed on the TRX or DRIC card which provide thenecessary functionality for DL signal processing. The CHC, on the other hand, performssymbol rate processing and slot formatting for the DL channels. For HSDPA, the inter-face from the CHC to the TRX or DRIC card remains unchanged.

DL physical channel types that are part of the pre-HSDPA function of the CHC are alsosupported by the HSDPA-capable CHC. Additionally, the HSDPA-capable CHC sup-ports physical channels required to provide HSDPA to the subscribers: HS-PDSCH andHS-SCCH. The slot formats supported for HS-PDSCH and HS-SCCH are in accordancewith 3GPP. This slot format characteristically only carries data, but not power controlcommands or pilot sequences or anything else.

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

The scrambling code and the channelization codes for the spreader units are configuredwhen HSDPA is set up in a UTRAN cell. In other words, their configuration is a directconsequence of an NBAP: Physical Shared Channel Reconfiguration procedure.

The following list provides information about the channel configuration and thus alsoabout the signal processing in DL direction:• HS-SCCH

The HS-SCCH is the DL control channel for HSDPA. The information carried on thischannel 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-PDSCHThe HS-PDSCH is the DL data channel carrying the user data.The HS-DSCH’s spreading factor is 16.The HSDPA-capable CHC supports both HS-PDSCH slot format “0” and slotformat “1”, indicating QPSK and 16QAM, respectively.In HSDPA mode of operation, the HSDPA-capable CHC is able to process one up to15 HS-PDSCHs per HSDPA cell. The maximum total number of HS-PDSCH chan-nelization codes supported is 15. Depending on the number of HSDPA cells that areset 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 cellswhich the Node B serves. In other words, all HSDPA cells which are subordinated tothe same Node B are assigned the same number of HS-PDSCH channelizationcodes.Furthermore, if the 16QAM modulation scheme is applied, the HSDPA-capable CHCcan 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 processing30 HSDPA channelization codes in total and up to 15 codes per cell. Tab. 3.4 illus-trates this:

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

40

• DPCHThe DPCH (dedicated physical channel) is the corresponding physical channel tothe DCH.In addition to the HSDPA processing specified above, DPCH processing is support-ed simultaneously. The DPCH processing resources, however, are reduced com-pared to the HSDPA-capable CHC’s non-HSDPA mode. When the HSDPA-capableCHC works in HSDPA mode, the DPCH symbol rate processing capacity guaranteessimultaneous processing of up to 96 AMREQs or 144 AMREQs on the DL when theCHC96 or the hs-CHC, respectively, is used.

3.1.6.2 Uplink Signal ProcessingUplink physical channel types that are part of the pre-HSDPA function of the CHC arealso supported by the HSDPA-capable CHC. Additionally, the HSDPA-capable CHCsupports a physical channel required to provide HSDPA: HS-DPCCH.

The following list provides information about the channel configuration and thus alsoabout the signal processing in the UL direction:• DPCH

The chip rate processing capacity guarantees the simultaneous processing of up to96 elementary UL DPCHs originating from up to 96 different UEs. Furthermore,when operating in HSDPA mode, the CHC’s DPCH symbol rate processing capacityguarantees the simultaneous processing of up to 96 AMREQs or 144 AMREQs onthe UL when the CHC96 or the hs-CHC, respectively, is used.

• HS-DPCCHFor each UL DPCH, the HSDPA-capable CHC is capable of simultaneously process-ing one HS-DPCCH originating from the same UE. Therefore, the overall chip rateprocessing capacity guarantees simultaneous processing of up to 96 elementaryoperations, each including one DPCH and one HS-DPCCH originating from thesame UE.The HS-DPCCH carries the CQI of the corresponding UE, for example.

3.1.7 Modifications of Power ControlThe priorities of both CCHs and DCHs are higher than those of the HS-DSCH and ofHS-SCCHs for HSDPA service. For this reason, the MAC-hs scheduler provides onlythat power for HSDPA service which remains after assigning the power to CCHs andDCHs.

Cell mode 16QAM/QPSK modulation QPSK-only modulation

1-cell mode 15 15

2-cell mode 7 15

3-cell mode 5 10

Tab. 3.4 Maximum number of HS-PDSCHs on a single HSDPA-capable CHC

SAY KIAT

Highlight

SAY KIAT

Highlight

41

3.2 Functional SplitIn UMR5.0, the packet scheduler for HSDPA traffic is implemented in the Node B ratherthan in the RNC where the scheduler for Rel 99 traffic is situated. Furthermore, the HS-DSCH terminated in Node B’s MAC-hs layer is the only UTRAN transport channel notterminated in the RNC. Using the HS-DSCH enables several users to be time-multi-plexed, thus making the resources available to other users during silent periods.

The modulator on the TRX or DRIC cards takes care of the new modulation scheme.Additionally, the Node B’s power amplifiers provide a higher linearity for 16QAM.

The main functionalities of HSDPA are concentrated on the Node B’s CHC. One of thefollowing 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 ofthe AAL2 connections require modifications concerning the TNL management. Fur-thermore, the CC provides an interface for multiplexing and demultiplexing UTOPIA(AAL5 and AAL2d) cells from and to UTOPIA.

• NBAP processingThe CC forwards the transmit power measurements from the TRX and DRIC cardsto the HSDPA scheduler.Furthermore, the modified admission control algorithm is implemented in the corecontroller. With this release, the CC therefore uses the non-HSDPA power insteadof 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 forHSDPA power control, HSDPA signal processing, and HSDPA priority queue manage-ment. The MAC-hs, to be more precise, contains the following functional entities:• Scheduler• HARQ• Flow control• Transmission control

3.2.3 Repeater (REP)The REP remains unchanged in comparison with the product release prior to UMR5.0.In other words, the REP module performs data transport between the CHCs and theTRX or DRIC cards.

3.2.4 Transceiver (TRX) or Digital Radio Interface Card (DRIC)These hardware cards accommodate the functionality for the new 16QAM modulationscheme. As described in the chapter about "Modifications of Radio Frequency (RF) Is-sues" on page 33, the currently installed HW can be reused for 16QAM.

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

42

3.3 Man-Machine InterfaceThe front panel of the new hs-CHC serves as a direct man-machine interface (MMI) forthe operator by offering the following:• Front Panel Indicators• Front Panel Connectors• Manual Intervention

3.3.1 Front Panel IndicatorsThe look and feel of the hs-CHC is the same as that of the pre-HSDPA CHC. The hs-CHC indicates its state to the user, thus indicating the status of the card in terms of• Administrative state (AST)• Operational state (OST)• Alarm status (ALS)• Availability status (AVS)

The hs-CHC visually indicates whether a module is providing HSDPA service. Further-more, the hs-CHC physically and logically controls the functionality of HSDPA upon es-tablishment and release of HSDPA processing resources.

In order to identify the hs-CHC, the card is provided with a new label.

3.3.2 Front Panel ConnectorsThe hs-CHC’s front panel connectors and the accessible functionality by way of thesefront panel connectors match those of the pre-HSDPA CHC48.

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


43

4 HSDPA Mobility

4.1 Functional DescriptionThe High Speed Downlink Shared Channel (HS-DSCH) is a common transport channelthat is shared by several UEs in the same cell. The MAC-hs functionality of the Node Bperforms scheduling of UEs on a per cell basis. Therefore, the UE receives theHS-DSCH of one cell and can receive DCHs of multiple cells. The cell where theHS-DSCH is currently established is called the serving HS-DSCH cell. The quality of theserving HS-DSCH cell constantly varies due to the mobility of the UE. If the quality isdegraded or the serving HS-DSCH cell is deleted, the SRNC needs to move the servingfunction to another cell where the quality is good. Furthermore, the UE may enter orleave the area where HSDPA is supported. In this case, the SRNC performs channel-type switching from DCH to HS-DSCH or from HS-DSCH to DCH.

The following UE mobility scenarios are supported within UMR5.0:• HS-DSCH establishment (when the UE is in Cell_DCH or Cell_FACH state)

– Intrafrequency, intra-SRNC, intra-Node B handover– Interfrequency, intra-SRNC, intra-Node B handover (at channel-type-switching

from FACH to HS-DSCH)• Inward mobility (DCH -> HS-DSCH)

– Intrafrequency, intra-RNC, inter-Node B handover• Change of the serving HS-DSCH cell

– Intrafrequency, intra-RNC, intra-Node B handover– Intrafrequency, intra-RNC, inter-Node B handover

• Outward mobility (HS-DSCH -> DCH)– Intrafrequency, intra-SRNC, inter-Node B handover– Intrafrequency, inter-RNC handover– Intrafrequency, inter-RNC (SRNC) relocation– Interfrequency, intra-SRNC, inter-Node B handover

4.1.1 HSDPA RAB HandlingThis 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 anHSDPA system

SAY KIAT

Highlight

44

4.1.1.1 UE Support of HSDPAThe SRNC uses the UE capabilities to determine whether or not the UE supportsHSDPA and if so, which HS-DSCH category it belongs to.

The SRNC determines the UE to be HSDPA capable if the following conditions are bothtrue:• The “UE Radio Access Capability” IE indicates that the UE is release 5 and that it

supports HSDPA.• The HSDPA feature is enabled.

Otherwise, the SRNC considers the UE as non-HSDPA capable.

The SRNC determines this information during RRC connection establishment, inter-RAT handover to UTRAN, or SRNS relocation. It may be necessary to obtain theinformation via UE capability enquiry. If the UE is considered capable of HSDPA, the UEprovides the HS-DSCH category to which it belongs.

3GPP TS 25.306 “UE Radio Access Capabilities” defines 12 HS-DSCH categories.UMR5.0 supports UE categories 1-6, 11, and 12. Tab. 4.1 shows the information de-fined for all HS-DSCH categories.

Parameter Usage

Maximum number of HS-DSCH codesreceived

To determine the number of HS-PDSCHchannels that the UE can receive in anyTTI

Minimum inter-TTI interval To determine the number of TTIs betweenconsecutive HS-DSCH transmissions

Maximum number of bits of an HS-DSCHtransport block received within an HS-DSCH TTI

To determine the maximum amount of datato be transmitted to the UE per TTI. Theamount of data is the size of MAC-hs PDU.

Total number of soft channel bits To determine the Process Memory Sizes ofall the HARQ processes.

Maximum number of AM RLC entities RNC uses 3 AM entities for SRB and also1 per PS BE or PS Streaming RAB.

Minimum total RLC and MAC-hs buffersize

3GPP TS 25.306 “UE Radio AccessCapabilities” defines the minimum value,but the actual value is signaled explicitlyand its usage is described in the section"Impacts on the Radio Bearer Translation"on page 47.

Tab. 4.1 Information defined for all HS-DSCH categories

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

45

4.1.1.2 RAB Eligibility for HSDPAThe 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 PSinteractive/background RABs belonging to Release 5 UEs supporting HSDPA arespecified as eligible for HSDPA even if they cannot be assigned on an HS-DSCH dueto their location or the RAB combination.

CS RABs and PS conversational RABs are not eligible for HS-DSCH and can only besupported on DCH. This is because these RABs have very strict delay requirementswhich are difficult to meet with a shared resource such as HS-DSCH.

4.1.1.3 Radio Bearer CombinationsThe 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 forthe DCCH only radio bearer combination, see Tab. 4.2.

Radio bearer combination Transport channelssupported

Notes

DCCH DCH/CCH

DCCH + CS Conversational DCH

DCCH + CS Streaming DCH

DCCH + PS BE HS-DSCH+DCH/DCH/CCH DCH only whenHS-DSCH is unavailable

DCCH + CS Conversational+ PS BE

DCH

DCCH + PS Conversational+ PS BE

DCH

DCCH + PS Streaming +PS BE

DCH

Tab. 4.2 Radio bearer combinations

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

46

4.1.1.4 RAB Multiplexing OptionsA PS RAB that is a candidate for HSDPA may also be mapped onto DCH and FACHduring its existence. Traffic monitoring can trigger channel-type switching betweenHS-DSCH and FACH while the RAB stays on HSDPA-enabled cells. DCH can be usedfor these RABs if the RAB combination changes or the RAB moves out of the HSDPA-enabled cells.

The “RB Mapping Info” IE is used to configure these options in the UE:• Multiplexing option 1 (for PS RABs in Cell_FACH state):

– UL transport channel type = RACH– DL transport channel type = FACH

• Multiplexing option 2 (for PS RABs in Cell_DCH state):– UL transport channel type = DCH– DL transport channel type = DCH

• Multiplexing option 3 (for HSDPA):– UL transport channel type =DCH– DL transport channel type = HS-DSCH

The radio bearer mapping configuration of multiplexing option 3 requires:• The MAC-d flow in the DL is configured in the UE and the DCH may be configured

if HS-DSCH is intended for use in the DL.• The DCH is configured in the UE in the DL and the MAC-d flow is not configured if

DCH is intended for use in the DL.

This behavior is achieved by deleting the MAC-d flow when the use of HS-DSCH isstopped. If the UE is in Cell_DCH state and the MAC-d flow exists, the UE always usesthe multiplexing option with HS-DSCH in the DL. If the MAC-d flow does not exist whilethe DCH does exist, the UE uses the multiplexing option with DCH in the DL. Further-more, the multiplexing option DCH + HS-DSCH is defined in 25.331 but it is not support-ed by early HSDPA UEs.

The multiplexing options are assigned upon RAB setup for all RABs that are HSDPA-eligible if the UE supports HSDPA. The multiplexing options are not reconfigured whenthe UE’s RAB combination changes or the UE moves in or out of HSDPA-enabled areas.

Furthermore, the “RB Mapping Info” IE is sent to HSDPA-capable UEs during SRNSrelocation of HSDPA-eligible RABs. This includes the HS-DSCH multiplexing option toallow 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. TheMAC-d flow is supported on a single transport bearer on the Iub/Iur interface and is thenfed into a single priority queue in MAC-hs. In the HS-DSCH information sent to theNode B for this configuration there is one MAC-d flow list element and one priority queuelist element which references the only MAC-d flow list element for the UE context. Thepriority queue is used to route the data to the appropriate queue and to prioritize thedata. The priority queue is assigned to a “Scheduling Priority Indicator” in the HS-DSCHFP DATA FRAME as CmCH-PI. For details, please refer to Tab. 2.3 in "HS-DSCHDATA FRAME" on page 22 and "Priority Queue Management" on page 146.

The “Scheduling Priority Indicator” is based on the “Traffic Class” and the “TrafficHandling Priority” IEs. These IEs are received with the RAB parameters of the RABASSIGNMENT REQUEST message, see Tab. 4.3.

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

47

4.1.1.5 Impacts on the Radio Bearer TranslationThe radio bearer translation algorithm is used to generate configuration parametersderived from the RAB parameters and the UE capabilities. The results provideinformation 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 varioussubsteps.

Traffic class Traffic handling priority Scheduling priority indicator

Interactive 1 (highest) 15

... ...

15 (lowest) 1

Background N/A 0

Tab. 4.3 RAB parameters in the RAB ASSIGNMENT REQUEST message

48

Fig. 4.1 Radio bearer translation steps

The following relation is valid upon PS BE establishment and channel-type switchingfrom 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 tothe DCH configuration which exist in parallel, see Fig. 4.2. If the DTCH is mapped ontothe HS-DSCH in the DL because the UE has selected the multiplexing option withHS-DSCH in the DL, the DL DCH still exists and is configured to 0 kbit/s.

RAB

RB Type

212-219 207, 209

208, 210

AAL2/5

RLC/RB Info

M1

RAB Type + Rate (PS BE)

DCH Type

227, 228205, 206

TFS

M2

RAB291, 292 Combination

M5Combination +UE CapabilityClass Not Allowed

Max UE SupportedRate for PS BE

UE Physical Layer Category

HS-DSCH Info

XXX

M6 New

step forHSDPA

optional

DCH

TFCS Type

220, 221278, 279

TFSC

M3

DCH

DPCH Type

220, 221202, 203

Physical CH Par

M4Combination + Rate

Combination

Allowed/

RABEstablishment

RRCConnectionEstablishment

RAB Release

BRA/CTS

49

Fig. 4.2 HS-DSCH and DCH configuration

If HS-DSCH is required, the RAB combination allows HSDPA usage, and a suitable cellis 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 minimumrates 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 PSBE DCH rates in the service combination such that all rates are equal to or less thanthe maximum rate supported by the UE. A table of permitted UL/DL DCH data ratecombinations 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, isnot taken into account since the maximum DCH rate that is used in the DL is set to0 kbit/s. Therefore, the “DL Capability with Simultaneous HS-DSCH Configuration”IE from the “UE Radio Access Capability” IE is ignored.

• Step 2The RNC filters the list of permitted rates from step 1 such that all rates are equal toor less than the maximum bit rate requested from the core network. If HSDPA isused, this check is performed for the set of UL rates only. In other words, the UL DCHrates from step 1 are compared with the “UL Maximum Bit Rate” value received inthe RAB parameters.

DL

DCCH

DCH

DPCH

DTCH

DCH HS-DSCH

UL

DCCH

DCH

DPCH

DTCH

DCH

50

• Step 3

The RNC selects from the list of permitted rates the initial and maximum rates thatcan 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 theDL. The RNC therefore restricts the permitted rates such that all rates are equalto or less than 64 kbit/s. The governing procedure fails if no rate is left in the listof permitted rates. The RNC selects the rate which is closest to the maximum bitrate requested by the core network if more than one permitted rate remains in thelist.

– Maximum rate:If more than one permitted rate remains in the list after step 2, the RNC selectsthe 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:

where (x1, y1) is the coordinate for the maximum bit rate requested by the core networkand (yi, yi) is the coordinate of the permitted rates. The DL rate is set to 0 kbit/s if HSDPAis used. Therefore, two data rate combinations cannot be equally close to the maximumbit rate requested by the core network.

Bit rate adaptation uses the pool of rates that were output from step 2 of M2. Only theUL DCH rate increases or decreases according to traffic activity if HSDPA is used. TheDL DCH rate is fixed at 0 kbit/s.

The new step M6 is introduced to obtain the HS-DSCH parameters. If the radio bearertranslation 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 radiobearer type which is determined from the RAB parameters. The radio bearer type islimited to 384 kbit/s in the DL (largest DCH rate). If the core network signals maximumbit rates above 384 kbit/s, they are assumed to be equal to 384 kbit/s, which results inwindow sizes tuned for 384 kbit/s.

If HSDPA is used, the RLC window sizes are selected according to the availablememory in the UE rather than on the basis of a DL rate parameter supplied by the corenetwork. The DL rate signaled by the RAB parameters and supported on the air inter-face may be much larger than 384 kbit/s. The maximum rate is limited by the UE capa-bility class. The maximum rate also depends on the RLC window sizes, which in turndepend on the UE’s available memory.

di x1 xi–( )2y1 yi–( )2

+=

SAY KIAT

Highlight

SAY KIAT

Highlight

51

This method of selecting the window size for an AM RLC RAB is applied if all of thefollowing conditions are valid:

1. The UE is HSDPA-capable2. 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 UEsand for HSDPA-capable UEs using a RAB combination involving more than one AMRLC RAB, for example PS BE + PS Streaming.

Tab. 4.4 shows the new system data table for the selection of the RLC window size forHSDPA-capable UEs with one AM RLC RAB.

The UE memory is taken from the “Total RLC AM buffer size” IE sent in the “UE RadioAccess Capabilities” in the RRC CONNECTION SETUP COMPLETE message.

Furthermore, the RNC takes into account the “Maximum RLC AM Window Size” IE alsosent in the “UE Radio Access Capabilities”. The RNC assigns the memory size as theminimum Min (Maximum RLC AM Window Size, RLC Window Size from table).

The UL window also increases with increasing memory with the proposed window sizesin Tab. 4.4. This is to allow a 384 kbit/s bearer on the UL. If UL bit rate adaptation oc-curs, the UL window size remains the same. However, a large UL window that is perma-nently specified reduces the memory available for the DL. If the UE only supplies a smallmemory, the DL is prioritized and as a result the UL: 384 kbit/s bearer may not be useful.

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

52

4.1.1.6 RRC Connection State ModelFig. 4.3 shows the RRC connection state model for HSDPA. PS streaming/conversa-tional + PS BE combinations are not shown. These RAB combinations are supported onDCH. Channel-type switching from HS-DSCH to DCH occurs if a PS streaming/conver-sational RAB is added to an existing PS BE RAB and this PS BE RAB is currently onHS-DSCH. RAB establishment resulting in a single PS BE RAB leads to HS-DSCHassignment.

If the PS streaming/conversational RAB of a PS streaming/conversational + PS BE RABcombination 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 fromDCH_ACTIVE state to Cell_DCH or Cell_FACH state takes place, that is, a switch toHS-DSCH never occurs. If one PS BE RAB of a PS BE + PS BE RAB combination isreleased, the connection remains in Cell_DCH/Cell_FACH state or moves fromCell_DCH to Cell_FACH state, that is, the UE is not switched to use HS-DSCH.

Fig. 4.3 UE state model for HSDPA

Cell_DCH

Cell_FACH

Cell_PCH

DCH ACTIVE

CS RAB setup or release

DCH INACTIVE



Cell_DCH +HS-DSCH

Leaving HSDPAcoverage;

2nd PS BE RAB setup

CTS triggers HSDPA cellunavailable

CTS triggers HSDPA cell

available

CS RAB setup

SAY KIAT

Highlight

53

4.1.1.7 Traffic Monitoring and Channel-Type SwitchingTraffic 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 toHS-DSCH, no bit rate adaptation trigger is needed in the DL since bit rate adaptation isnot performed on HS-DSCH. Therefore, buffer utilization and buffer volume measure-ments are not configured. In the UL, bit rate adaptation is possible and UE measure-ments 4A and 4B are used. Measurement events 4A and 4B are only configured if thereis 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 inboth UL and DL. This is the same trigger as for channel-type switching from Cell_DCHto Cell_FACH state. The hysteresis time for switching from HS-DSCH to FACH due toinactivity detection can be specified by the operator. Channel-type switching from FACHto HS-DSCH is caused by PS RAB buffer overflow in UL or DL. This is the same triggeras for channel-type switching from FACH to DCH. The existing trigger for channel-typeswitching from FACH to DCH due to initial direct transfer is unaffected by the introduc-tion of HSDPA.

Bit rate adaptation is not applicable while the DL uses HS-DSCH. The UL, however,resides on DCH and bit rate adaptation is possible. On reception of events 4A and 4B,bit rate adaptation to a higher or lower rate is triggered. Node B dedicated measure-ments for the DL transmitted code power (Radio Link Quality measurements) are notused while HS-DSCH is on the DL. These measurements are only applicable forcontrolling the DL power if the PS BE RAB uses DCH.

4.1.1.8 Power Control and Measurement Feedback ParametersTab. 4.5 shows parameters provided by the SRNC. These parameters are read fromOAM data. One set of parameters per UE HS-DSCH physical layer category issupported.

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 CQImeasurement report

CQI Repetition Factor CQI repetition factor Integer (1..4) Number of repetitions of aCQI report. Not necessarywhen CQI Feedback Cyclek = 0.

ACK-NACK RepetitionFactor

Ack-Nack repetition factor Integer (1..4) Number of repetitions ofACK/NACK reports

Tab. 4.5 Power control and measurement feedback parameters (SRNC)

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

54

Tab. 4.6 shows the parameter provided by the CRNC. This parameter is cell-specificand taken from the cell object.

4.1.1.9 RAB Setup Procedure from DCH to HS-DSCHRAB setup from DCH to HS-DSCH is triggered upon reception of a RAB ASSIGNMENTREQUEST message for a PS interactive or background RAB with the followingpreconditions:

1. The radio bearer combination currently contains only DCCH.2. The UE supports HSDPA.3. The UE is in Cell_DCH state.4. The UE is not in compressed mode at the time when the RAB assignment request

is received.

The procedures to establish the RAB on DCH are initiated if the condition 1, 2, or 4 isnot true. If condition 3 is not true, see "RAB Setup Procedure from FACH to HS-DSCH"on page 58.

The first step is the selection of an HS-DSCH RL ID that is the RL ID of the cell wherethe HSDPA resources will be established. The cell selection is described in "HSDPAMobility Handling" on page 73. Afterward, the radio bearer translation algorithm iscalled, see "Impacts on the Radio Bearer Translation" on page 47. This produces the

CQI Power Offset ∆CQI Integer (0..8) Power offset used in the ULbetween the HS-DPCCHslots carrying CQI informa-tion and the associatedDPCCH

ACK Power Offset ∆ACK Integer (0..8) Power offset used in the ULbetween the HS-DPCCHslot carrying HARQ ACK in-formation and the associat-ed DPCCH

NACK Power Offset ∆NACK Integer (0..8) Power offset used in the ULbetween the HS-DPCCHslot carrying HARQ NACKinformation and the associ-ated DPCCH

HS-SCCH Power Offset N/A -32 .. + 31.75 dB Power offset of HS-SCCHrelative to the pilot bits onthe DL DPCCH


Tab. 4.5 Power control and measurement feedback parameters (SRNC)


Measurement Power Offset POhsdsch -6..13 dB Default Power offset between HS-PDSCH and P-CPICH/S-CPICH.

Tab. 4.6 Power control and measurement feedback parameters (CRNC)

55

MAC-d flow information and the priority queue information for the HS-DSCHconfiguration.

The SRNC-based power offset and measurement-related parameters are generated,see "Power Control and Measurement Feedback Parameters" on page 53. Then theSRNC initiates the synchronized RL reconfiguration preparation procedure to theCRNC. This is a local procedure as HS-DSCH via the Iur interface is not supported andcells 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 theactive 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. WhenHS-DSCH is used on the DL, the DL TFS of the DCH associated with the PS BE RABis set up and configured to 0 kbit/s using a TFS with one TF. The number of transportblocks contained is set to “zero”.

Since the UE is assigned to an HS-DSCH resource belonging to a particular cell withina particular Node B, only the affected Node B is configured with the HS-DSCHconfiguration parameters and the affected cell within that Node B is identified by theHS-DSCH RL ID.

The admission control is performed in the CRNC, see "HSDPA Admission Control andCongestion Control" on page 99. If the resources are admitted, the CRNC allocates anHS-DSCH RNTI such that it is unique for the selected cell, see "Allocation of H-RNTI"on page 72. Additionally, the CRNC allocates the “Measurement Power Offset” param-eter, see "Power Control and Measurement Feedback Parameters" on page 53. Thenthe CRNC initiates the NBAP synchronized RL reconfiguration preparation procedure.

The NBAP: RL RECONFIGURATION PREPARE message contains the followinginformation:• 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 thereceived information.

The NBAP: RL RECONFIGURATION READY message contains the followinginformation:• 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 theNBAP RL RECONFIGURATION READY message. The SRNC initiates the ALCAPtransport bearer establishment procedures. The transport bearer for the DCH partcarries the UL DTCH and is established toward all Node Bs/DRNCs in the active set. If

56

the “Transport Bearer Modification Feature” flag is set to “ON” for the DL direction of thisDCH, the link characteristics for connection admission control (CAC) are set to the DCHrate used, that is 0 kbit/s. Otherwise, they remain configured according to the maximumrate that this DCH may use. The transport bearer for the MAC-d flow is establishedtoward the Node B containing the HS-DSCH RL ID.

The NBAP: RL reconfiguration commit procedures are initiated after successfulcompletion of the transport bearer establishment procedures and the RRC radio bearersetup procedure is initiated.

The UE is configured with the following information:• H-RNTI (from CRNC)• Within the “RB mapping info” IE:

– Multiplexing options, see "RAB Multiplexing Options" on page 46• Within the “Added or Reconfigured DL TrCH Information” IE:

– HARQ process information (from Node B)– MAC-d flow/priority queue configuration (from SRNC: RBT)– MAC-hs reset indicator set to “true”

• Within the “Downlink HS-PDSCH Information” IE:– HS-SCCH code set information (from Node B)– Measurement feedback information (from SRNC/CRNC)

• Within the “Uplink DPCH Power Control Info” IE:– ACK/NACK control info (SRNC)

• Within the “Downlink information for each radio link” IE corresponding to selectedHSDPA serving cell:– Serving HS-DSCH radio link indicator

The procedure finishes upon reception of the RRC: RADIO BEARER SETUPCOMPLETE 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 thecore network indicating that establishment of the RAB failed. Any resources establishedfor the RAB are released. If an RRC RADIO BEARER SETUP FAILURE message isreceived, a radio failure occurs which results in dropping the RRC connection since theNode B is already committed to the new configuration. The reason is that RRCconnection reestablishment is only supported if a RAB exists.

The following failures result in a retry on DCH:• Admission control failure including an NBAP: RL reconfiguration failure with the

cause “not enough user plane processing resources”. For more information see"Pre-emption and Interaction with Admission Control" on page 71.

Fig. 4.4 shows the message sequence chart for RAB setup (DCH to HS-DSCH).

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

57

Fig. 4.4 Message sequence chart for RAB setup (DCH to HS-DSCH)

DCH to add (UL DTCH)HS-DSCH to add

NBAP: RL RECONFIGURATION PREPARE DCH to add (UL DTCH)

Node 1UE Node B2 SRNC

HSDPA Cell Selection

NBAP: RL RECONFIGURATION PREPARE

NBAP: RL RECONFIGURATION READY

Decision to establish RABRLs already exist

Allocate HS-DSCH RNTI

HS-DSCH RNTIHS-PDSCH RL ID

DCH Information ResponseHS-DSCH FDD Information Response

NBAP: RL RECONFIGURATION READYDCH 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

New H-RNTIDownlink HS-PDSCH IinformationRB mapping info ->

Added/reconfigured DL TrCH information ->DL HS-DSCH MAC-d flow id

HS-DSCH

58

4.1.1.10 RAB Setup Procedure from FACH to HS-DSCHThe RAB setup from FACH to HS-DSCH is triggered upon reception of a RAB assign-ment request for a PS interactive or background RAB with the following preconditions:

1. The radio bearer combination currently contains only DCCH.2. The UE supports HSDPA.3. The UE is in Cell_FACH state.

If conditions 1 and 2 are not true, the procedures to establish the RAB on DCH or FACHare initiated.

The SRNC checks the setting of the “Channel for Interactive or Background ClassRABs” parameter upon RAB setup if the UE is in Cell_FACH state:• “Cell_FACH”

The SRNC proceeds with PS RAB establishment in Cell_FACH state.• “Cell_DCH”

Cell selection is applied as described in "HSDPA Mobility Handling" on page 73. Thisselects an HSDPA-enabled cell if available. PS RAB establishment on HS-DSCH isinitiated as described below if an HSDPA-enabled cell can be found on any frequen-cy. Otherwise, the PS RAB is established in Cell_DCH state.

If an HSDPA-enabled cell is found, the SRNC assigns the HS-DSCH RL ID as the RLID of the target cell. The radio bearer translation algorithm is called, see "Impacts on theRadio Bearer Translation" on page 47. This produces the MAC-d flow information andthe priority queue information for the HS-DSCH configuration.

The SRNC based power offset and measurement related parameters are generated,see "Power Control and Measurement Feedback Parameters" on page 53. Then theSRNC initiates the RL setup procedure. This is only done locally, since channel-typeswitching via the Iur interface is not possible. There is only one Node B in the active setand this is connected via the Iub interface.

The UL part of the PS BE RAB is established on DCH. The Node B is thereforeconfigured with UL DCH information and UL physical channel information. The “DCHSpecific Info” IE contains a mandatory UL and DL transport format set. When HS-DSCHis used on the DL, the DL transport format set of the DCH associated with the PS BERAB is configured to 0 kbit/s using a transport format set with one transport format. Thenumber of transport blocks contained is set to “zero”.

The CRNC initiates the NBAP RL setup procedure. The NBAP: RL SETUP REQUESTmessage contains the following information:• UL/DL DPCH info• UL/DL DCH info for the DCCH• UL DCH info for the PS DTCH• MAC-d flow/priority queue configuration• Power offset and measurement feedback information• H-RNTI• HS-PDSCH RL ID

The Node B assigns the codes upon reception of the HS-DSCH information. Further-more, the Node B configures the MAC-hs entity, the HARQ processes, and thescheduler with the information received.

59

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 theNBAP RL SETUP RESPONSE message. Then the SRNC initiates the ALCAP transportbearer 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 setto 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 thatthis DCH may use.

The SRNC initiates the RRC radio bearer setup procedure upon successful completionof the transport bearer establishment procedures. The UE is configured with thefollowing information:• H-RNTI (from CRNC)• Within the “RB mapping info” IE:

– Multiplexing options, see "RAB Multiplexing Options" on page 46• Within the “Added or Reconfigured DL TrCH Information” IE:

– HARQ process information (from Node B)– MAC-d flow/priority queue configuration (from SRNC: RBT)– MAC-hs reset indicator set to “true”



• Within the “Downlink information for each radio link” IE corresponding to selectedHSDPA 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 SETUPCOMPLETE message.

The following failures result in the RAB establishment procedure failing:• NBAP: RL setup failure with 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 thecore network indicating that the establishment of the RAB failed. Furthermore, anyresources 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).

60

Fig. 4.5 Message sequence chart for RAB setup (FACH to HS-DSCH)

DCH to add (for SRB)DCH to add (UL DTCH)

Node BUE SRNC

NBAP: RL SETUP REQUEST

Decision to establish RAB on HS-DSCHNo RLs exist currently


HS-DSCH to add (DL DTCH)HS-DSCH RNTI

NBAP: RL SETUP RESPONSEHS-DSCH FDD Information Response

ALCAP Iub Transport Setup (HS-DSCH)

ALCAP Iub Transport Setup (UL DTCH)

ALCAP Iub Transport Setup (SRB)



New H-RNTIDownlink HS-PDSCH IinformationRB mapping info ->

Added/reconfigured DL TrCH information ->DL HS-DSCH MAC-d flow id

HS-DSCH

- HS-SCCH Code Information

HS-PDSCH RL ID

Cell Selection:see “HSDPA Mobility Handling”

61

4.1.1.11 Channel-Type Switching from FACH to HS-DSCHThe procedure is initiated by PS RAB buffer overflow on UL or DL, see "Traffic Monitor-ing and Channel-Type Switching" on page 53. With channel-type switching from FACHto HS-DSCH, an HSDPA-enabled cell is selected, see "HSDPA Mobility Handling" onpage 73. The UE is switched to HS-DSCH as described below if an HSDPA-enabled cellcan 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 theprocedure for RAB establishment from FACH to HS-DSCH, see "Channel-Type Switch-ing from FACH to HS-DSCH" on page 61. The RRC procedure, however, is the trans-port channel reconfiguration procedure instead of the radio bearer setup procedure.

The TRANSPORT CHANNEL RECONFIGURATION message contains the followinginformation:• H-RNTI (from CRNC)• Within the “Added or Reconfigured DL TrCH Information” IE:

– HARQ process information (from Node B)– MAC-d flow/priority queue configuration (from SRNC: RBT)



• Within the “Downlink Information for Each Radio Link” IE corresponding to selectedHSDPA 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• ALCAP: TB setup failure• RRC: transport channel reconfiguration failure

In the event of these failures, the connection reverts to Cell_FACH state and anyresources already assigned are released.

Fig. 4.6 shows the message sequence chart for channel-type switching from FACH toHS-DSCH.

SAY KIAT

Highlight

62

Fig. 4.6 Message sequence chart for channel-type switching from FACH to HS-DSCH

4.1.1.12 Channel-Type Switching from HS-DSCH to FACHThe procedure is initiated if inactivity is detected on both UL and DL, see "Traffic Moni-toring and Channel-Type Switching" on page 53.

This procedure is very similar to the existing procedure for channel-type switching fromCell_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 theMAC-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

DCH to add (for SRB)DCH to add (UL DTCH)

Node BUE RNC

NBAP: RL SETUP REQUEST

Decision to switch PS RAB


HS-DSCH to add (DL DTCH)HS-DSCH RNTI

NBAP: RL SETUP RESPONSEHS-DSCH FDD Information Response

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

New H-RNTIDownlink HS-PDSCH IinformationAdded/reconfigured DL TrCH information ->

HS-DSCH

- HS-SCCH Code Information

HS-PDSCH RL ID

from FACH to HS-DSCH

Cell Selection:see “HSDPA Mobility Handling”

63

Fig. 4.7 shows the message sequence chart for channel-type switching from HS-DSCHto FACH.

Fig. 4.7 Message sequence chart for channel-type switching from HS-DSCH to FACH

RRC: RADIO BEARER RECONFIGURATION COMPLETE

Node B1UE Node B2 RNC

Cell Update (cell reselection)

NBAP: RL DELETION REQUEST

NBAP: RL DELETION RESPONSE

Trigger to switch a RABfrom HS-DSCH to FACH

Deallocate HS-DSCH RNTI

ALCAP Iub Transport Bearer Release (HS-DSCH)

ALCAP Iub Transport Bearer Release (UL DTCH)

ALCAP Iub Transport Bearer Release (DCCH)

ALCAP Iub Transport Bearer Release (UL DTCH)

ALCAP Iub Transport Bearer Release (DCCH)

NBAP: RL DELETION REQUEST

NBAP: RL DELETION RESPONSE

RRC: RADIO BEARER RECONFIGURATION RRC State Indicator = FACHDL Deleted TrCH information(MAC-d flow)

64

4.1.1.13 RAB Setup Procedure from HS-DSCH to DCHRAB setup from HS-DSCH to DCH is triggered upon reception of a RAB assignmentrequest to establish a RAB while the current RAB combination uses the HS-DSCH andthe target RAB combination will not use HS-DSCH, see "Impacts on the Radio BearerTranslation" on page 47.

The radio bearers mapped onto HS-DSCH on the DL must be switched to DCH. Theradio bearer translation mechanism is called with the “HS-DSCH Required” indicator setto “not required”. The radio bearer translation algorithm outputs a DCH onlyconfiguration, assigning the initial rate for the PS BE RAB.

If the new RAB also uses AM RLC, the SRNC regenerates the RLC window sizes basedon the RB type, see "Impacts on the Radio Bearer Translation" on page 47. The SRNCthen initiates the RB reconfiguration procedure, see "Radio Bearer Reconfiguration Pro-cedure" on page 69.

The SRNC initiates the synchronized RL reconfiguration preparation procedure to:• Delete the HS-DSCH at the Node Bs.• Reconfigure simultaneously the DCH which has a current DL rate of 0 kbit/s. The UL

DCH is reconfigured if the current rate differs from the target rate.• Add the DCH for the RAB that is to be established.

Afterward, AAL2 establishment procedures are initiated for the new RAB and the RLreconfiguration commit procedure is initiated.

The DL link characteristics for CAC are configured to the used DCH rate if the “TransportBearer Modification Feature” flag is set to “on”. Otherwise, they remain configured to themaximum 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” IEto 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 RRCprocedure. Upon reception of the RB SETUP COMPLETE message, the SRNCreleases 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 rateadaptation which was not active while the DL was using HS-DSCH.

The following failures result in the RAB establishment procedure failing:• NBAP: RL reconfiguration preparation failure with 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 thecore network indicating that the establishment of the RAB failed. Any resourcesestablished for the RAB are released. If an RRC RADIO BEARER SETUP FAILUREmessage is received, an RRC connection reestablishment procedure is also requiredsince 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 ReconfigurationProcedure" on page 69.

65

Fig. 4.8 shows the message sequence chart for RAB setup (HS-DSCH to DCH).

Fig. 4.8 Message sequence chart for RAB setup (HS-DSCH to DCH)

DCH to add (UL/DL DTCH for new RAB)DCH to modify (UL/DL DTCH for PS RAB)

NBAP: RL RECONFIGURATION PREPARE DCH to add (UL/DL DTCH for new RAB)

Node 1UE Node B2 RNC

Radio Bearer Reconfiguration

NBAP: RL RECONFIGURATION PREPARE

Trigger to set up a RAB which results in a

HS-DSCH to delete (DL DTCH)


ALCAP Iub Transport Bearer Setup (new DCH)

ALCAP Iub Transport Bearer Setup (new DCH)





RRC State Indicator = DCHAdded/reconfigured DL TrCH information

- if no mac multiplexing

- reconfigure UL/DL DCH for PS DTCH

-> reconfiguration to DCH onlyRAB combination not allowed on HS-DSCH

OPT 1

1

Performed if newRAB uses RLC AM

DCH to modify (UL/DL DTCH for PS RAB)


Added/reconfigured UL TrCH information

- add UL/DL DCH for new DTCH


Deallocate H-RNTI

Dedicated Measurement Activation for DL Tx power events A/F

66

4.1.1.14 RAB Release Procedure from HS-DSCH to DCHRAB release from HS-DSCH to DCH is triggered upon reception of a request to releasethe 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 + PSRAB 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).

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

67

Fig. 4.9 Message sequence chart for RAB release (HS-DSCH to DCH)




Trigger to release a RAB which is on HS-DSCHRevert to DCH

Deallocate H-RNTI


ALCAP Iub Transport Bearer Release (UL DCH)

ALCAP Iub Transport Bearer Release (UL DCH)

NBAP: RL RECONFIGURATION PREPARE DCH to delete (UL DTCH)

NBAP: RL RECONFIGURATION PREPARE DCH to delete (UL DTCH)

RRC: RADIO BEARER RELEASE COMPLETE

RRC: RADIO BEARER RELEASERRC State Indicator = DCHDeleted DL TrCH Information (DCH)Deleted DL TrCH Information (HS-DSCH)Deleted UL TrCH Information

HS-DSCH to delete (DL DTCH)



68

4.1.1.15 RAB Release Procedure from MulticallRAB release from multicall is triggered if the UE has more than one RAB and receivesa trigger to release one of them. This initiation is unchanged.

In addition to the existing actions, the RLC window sizes are regenerated according tothe values derived from the UE memory availability, see "Impacts on the Radio BearerTranslation" on page 47.

Furthermore, a radio bearer is reconfigured if the following conditions are satisfied:• The UE is HSDPA-capable.• The UE has two RABs which use AM RLC.• The procedure releases one of the two RABs using AM RLC.

The radio bearer reconfiguration procedure is performed upon completion of the RABrelease procedure, that is, after sending the RAB ASSIGNMENT RESPONSE messageto the core network.

If the UE fails the radio bearer reconfiguration and the cause is “configurationunsupported”, the RNC reverts the local RLC parameters to what they were before theradio bearer reconfiguration and resumes the governing RAB setup procedure. TheRAB setup procedure may fail due to limited UE memory. In the event of other failurecauses, the RNC initiates the Iu release procedure.

Fig. 4.10 shows the message sequence chart for RAB release from multicall.

Fig. 4.10 Message sequence chart for RAB release from multicall



Trigger to release a RAB when

OPT 1

1

For HSDPA-capable UEs whenPS BE RAB remains and RAB

two RABs exist

Perform existing RB Release procedure

to be released was AM RLC

69

4.1.1.16 RRC Connection Reestablishment ProcedureRRC connection reestablishment is triggered upon reception of an NBAP: RL FAILUREINDICATION message for the last radio link set in the UE’s active set. Afterward, theRNC starts the timer T314RNC and waits for an RRC: CELL UPDATE message from theUE with cause “RL Failure” or “RLC Unrecoverable error”. This is the same trigger as forthe procedure to reestablish an RRC connection on DCH.

If the RRC: CELL UPDATE message is received before the NBAP: RL FAILUREINDICATION message, the RNC deletes all resources in the first step except the Iuresources and the internal UE context. Afterward, the RNC starts the timer T314RNC andwaits for the next retransmitted CELL UPDATE message. This second CELL UPDATEmessage triggers the reestablishment procedure.

RRC connection reestablishment may be forced by the RNC, for example in the eventof an RLC-unrecoverable error on DCCH detected by UTRAN. This includes the releaseof all UTRAN resources except the Iu resources and the internal UE context. Thedisappearance 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, theSRNC performs reestablishment to FACH instead of reestablishment to DCH orHS-DSCH. UEs, however, are reestablished on DCH if they are HSDPA-non-capable orHSDPA-capable with a RAB combination which is not allowed to use HS-DSCH. TheseUEs may be reestablished in an HSDPA cell if such a cell is selected by the UE after itdetects a radio link failure.

If the UE uses HS-DSCH, the CELL UPDATE CONFIRM message includes additionallythe “Deleted DL TrCH information” IE in order to delete the MAC-d flow currentlyconfigured in the UE. The UE responses with a TRANSPORT CHANNELRECONFIGURATION COMPLETE message.

4.1.1.17 Radio Bearer Reconfiguration ProcedureRadio bearer reconfiguration is initiated if a second AM RAB is set up or released. It isused to modify the RLC parameters such that the UE’s used RLC buffer space is withinits capabilities. This procedure can only be called during a governing RAB setup/releaseprocedure, see "RAB Setup Procedure from DCH to HS-DSCH" on page 54 and "RABRelease Procedure from Multicall" on page 68.

At first, the local RLC parameters are reconfigured to the new RLC parameters. Thenthe 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 RABthat uses AM RLC, the existing AM RLC RAB is reconfigured to use the RLC windowsizes derived from the RB type. In the event of a RAB assignment to release one of twoRABs that use AM RLC, the remaining RAB is reconfigured to use the RLC window

SAY KIAT

Highlight

70

sizes derived from UE available memory if the remaining RAB is eligible for HS-DSCHusage.

If the UE fails the radio bearer reconfiguration and the cause is “configurationunsupported”, the RNC reverts to the local RLC parameters used before the radiobearer reconfiguration and resumes the governing RAB setup procedure. This RAB set-up procedure may fail due to limited UE memory. In the event of other failure causes,the RNC initiates the Iu release procedure.

Fig. 4.11 shows the message sequence chart for radio bearer reconfiguration.

Fig. 4.11 Message sequence chart for radio bearer reconfiguration

4.1.1.18 SRNS Relocation ProcedureThe RNC includes the appropriate RLC configuration in the CELL UPDATECONFIRM/RB RECONFIGURATION message if the UE is ascertained to be HSDPAcapable from the relocation container. That is, any AM BE RAB has the “RB MappingInfo” IE as described in section "RAB Multiplexing Options" on page 46 and the RLCwindow size according to "Impacts on the Radio Bearer Translation" on page 47. TheRLC window size is derived from UE available memory if the PS BE RAB is the only AMRLC RAB. If more than one AM RLC RAB exist, the smaller RLC window size is derivedfrom the RB type.

4.1.1.19 RAB Setup Procedure from CCH to DCH and DCH to DCHThis procedure is changed in a way that radio bearer reconfiguration is performed be-fore RAB setup in the event of:• The UE is HSDPA capable.• The existing RAB combination includes a PS BE RAB.• The existing RAB combination includes only one AM RLC RAB.• The RAB to be setup is AM RLC.

The procedure is applicable for a HSDPA-capable UE that has a PS BE RAB (inCell_FACH or Cell_DCH state) and is therefore configured with the RLC window sizesderived from UE available memory if the RNC receives an RAB assignment request fora PS streaming RAB (which also uses AM RLC). In this case it is necessary to changethe RLC window sizes to the values derived from the RB type. For more information see"Impacts on the Radio Bearer Translation" on page 47.

UE SRNC

Change local RLC parameters

RRC: RADIO BEARER RECONFIGURATION COMPLETE

RRC: RADIO BEARER RECONFIGURATIONRB Information to reconfigure (DL RLC info)Downlink PDSCH Information (unchanged)Activation time = “now”

71

Fig. 4.12 shows the message sequence chart for RAB setup (CCH to DCH, DCH toDCH).

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 ControlAdmission 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 isaccounted for by the admission control. The UL DCH for the new RAB is establishedin all cells of the active set if the active set of the UE has more than one cell but theDL 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 anUL/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 anUL/DL DCH supporting DCCH.

• Change of the serving HS-DSCH cellThe RAB requests only the DL HS-DSCH because the UL DCH and the UL/DL DCHsupporting DCCH are already established. The UL DCH, however, may be switchedfrom a non-HSDPA-capable CHC to an HSDPA-capable CHC, in which case Node Badmission control (user plane resource availability) may fail the request.

• Active set update (SHO addition) when using HS-DSCHThe RAB requests a UL DCH and a UL/DL DCH supporting the DCCH. NoHS-DSCH resources are requested in this scenario.

Radio-link pre-emption is not supported for the HS-DSCH/DCH combinations.The “Pre-emption Capability” IE for the MAC-d flow is set to “shall not trigger pre-emption” by the SRNC. The “Pre-emption Capability” IE is part of the allocation/retentionpriority. The core network includes the allocation/retention priority for each RAB to beset up or modified by the UTRAN in the RANAP RAB ASSIGNMENT REQUEST orRELOCATION REQUEST messages.

GSM SRNCGSM


OPT 1

1

Existing RAB establishment procedure

Performed in the event of:- UE is HSDPA capable- existing RAB combinationincludes PS BE

- existing RAB combinationincludes only one AM RLC RAB

- RAB to be set up is AM RLC

72

If the Pre-emption feature is switched on and the “Allocation/Retention Priority” IE wasreceived in the RAB assignment request, the “Pre-emption Capability” IE of the DCH forthe relevant DTCH is set to “shall not trigger pre-emption” when the HS-DSCH is alsorequested.

Admission control failure in the above HS-DSCH establishment procedures can occurfor the following reasons:

1. Failure to allocate the Node B resources2. Failure to allocate the DL DCH resources3. 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 resourceshortage in the Node B. The RNC identifies admission control failure when it receivesan NBAP message with the NBAP failure cause set to “not enough user plane process-ing resources”.

In the event of RAB establishment, a retry on DCH is attempted. Even if the failureoccurred due to DCH resource shortage with the reason 2) or 3), the retry on DCHshould use the received “Allocation/Retention Priority” IE which could result in success-ful admission with pre-emption of another user. The retry on DCH is attempted at the“minimum” rate, which is when the received allocation/retention priority parameters areapplied. 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 inCell_FACH state regardless of the admission control failure type.

In the mobility scenarios, the reasons 1), 2) and 3) apply for active set update (SHOaddition). Furthermore the reasons 1) and 3) apply for a serving cell change. Failuresare 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 iscurrently 384 kbit/s, the UL bit rate is adapted to 64 kbit/s and a soft-handover re-try is performed. If this fails, reestablishment on FACH is performed.

– Upon admission control failure due to reason 1) or 3) when the UL rate is currently64 kbit/s and due to reason 2), a channel-type switching from DCH/HS-DSCH tothe DCH minimum rate is performed (same procedure as outward mobility). In theevent of active set update (soft handover addition) failure, this is followed by a softhandover retry. If this fails, reestablishment on FACH is performed.

• The ongoing procedure is a serving cell change:A channel-type switching from DCH/HS-DSCH to DCH minimum rate is performed(same procedure as outward mobility) followed by a soft handover retry. If this fails,reestablishment on FACH is performed.

4.1.1.21 Allocation of H-RNTIH-RNTI is the unique identifier of an HSDPA user within a cell. It is used to scramble thecontrol data on the HS-SCCH.

73

4.1.2 HSDPA Mobility HandlingThe quality of the serving HS-DSCH cell always varies and the SRNC needs to movethe serving HS-DSCH cell to another cell if the quality is degraded or the servingHS-DSCH cell is deleted. With the HSDPA Mobility Handling feature, it is possible toestablish the HS-DSCH on the cell in the active set where the quality is best. The systemthroughput will thus be improved. Furthermore, this feature enables the deployment ofHSDPA 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 anactive set, wherever possible. If the best cell within the active set is a non-HSDPA-capable cell and HS-DSCH is currently used, channel-type switching from HS-DSCH toDCH is performed. For more information on RAB eligibility for HSDPA see "HSDPA RABHandling" on page 43.

An “HSDPA Cell” is defined in this document as a cell that supports HSDPA and has the“Resource Operational State” set to “enabled”. A cell is not taken into account as anHSDPA cell if it supports HSDPA but its operational state is “disabled”. The SRNC doesnot try to establish HS-DSCH on such a cell. For more information see "HSDPA Codeand Power Allocation and Redimensioning" on page 108. HS-DSCH is not supportedvia Iur interface. Therefore, all cells under the control of another RNC are considered tobe non-HSDPA cells.

The prerequisites for the handling of HS-DSCH are:

1. HSDPA-related parameters which characterize the HS-DSCH MAC-d flow are un-changed during the call. For more information on these parameters, for example the“Scheduling Priority Indicator” IE, see "HSDPA RAB Handling" on page 43.

2. HSDPA-related parameters are only sent to the nodes which are relevant forestablishing 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-DSCHcell 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 deletedduring the active set update procedure. The active set update procedure isperformed to prepare the change of the serving HS-DSCH cell if the change of theserving HS-DSCH is triggered by the reception of a measurement report with event1A, 1B, 1C, or 1A’.

4.1.2.1 Scenarios for Mobility Handling of HS-DSCHThe following scenarios are supported for mobility handling of HS-DSCH.

HS-DSCH establishment

The scenarios supported upon HS-DSCH establishment are:• Intrafrequency, intra-SRNC, intra-Node B handover• Interfrequency, intra-SRNC, intra-Node B handover

The SRNC tries to establish HS-DSCH if the active set of the UE includes HSDPA-capable cells (Cell_DCH state) or the UE has an RRC connection to a cell whereHSDPA is supported (Cell_FACH state). Fig. 4.13 shows the related intrafrequency,intra-SRNC, intra-Node B handover scenario.

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

74

Fig. 4.13 HS-DSCH establishment if the UE is in Cell_DCH or Cell_FACH state

The SRNC tries to move the UE to an HSDPA-supporting cell if the UE has an RRCconnection to a cell which does not support HSDPA (Cell_FACH state) and channel-type switching from FACH to HS-DSCH is triggered due to traffic monitoring. This is notperformed if a RAB is established. If such an HSDPA-supporting cell is available, theSRNC establishs HS-DSCH on that cell. Fig. 4.14 shows the related interfrequency,intra-SRNC, intra-Node B handover scenario.

Fig. 4.14 HS-DSCH establishment if the UE is in Cell_FACH state

UEHSDPA cell

Serving HS-DSCH cell

Frequency#1’

Frequency#1’

Node B

UE

UE

Non HSDPA cell


Frequency#1’

Frequency#1’

Node B

Frequency#2’

Frequency#2’

HSDPA cell

UE

SAY KIAT

Highlight

75

Inward mobility (DCH -> HS-DSCH)

The scenario supported upon inward mobility (DCH -> HS-DSCH) is:• Intrafrequency, intra-RNC, inter-Node B handover

Channel-type switching from DCH to HS-DSCH is performed if the UE enters anHSDPA-capable cell and the condition described in "Inward Mobility" on page 81 is met.Fig. 4.15 shows the related intrafrequency, intra-RNC, inter-Node B handoverscenario.

Fig. 4.15 Inward mobility

Change of the serving HS-DSCH cell

The scenarios supported upon HS-DSCH cell change are:• Intrafrequency, intra-RNC, intra-Node B handover• Intrafrequency, intra-SRNC, inter-Node B handover

A change of the serving HS-DSCH cell is performed if the UE enters a new HSDPA-capable cell because of an active-set change and the condition described in section"Change of the Serving HS-DSCH Cell" on page 84 is met. Furthermore, the servingHS-DSCH cell is changed if the quality of the serving HS-DSCH cell becomes worsethan other HSDPA-capable cells within the active set.

Fig. 4.16 and Fig. 4.17 show the intrafrequency, intra-RNC, intra-Node B handoverand intrafrequency, intra-RNC, inter-Node B handover scenarios for a change of theserving HS-DSCH cell due to a change of the active set. A change of the servingHS-DSCH cell within the active set is almost the same and not shown.

UE

UENon HSDPA cell


Frequency#1’

Frequency#1’

HSDPA cell

Active set

Active set

76

Fig. 4.16 Change of the serving HS-DSCH cell within a Node B

Fig. 4.17 Change of the serving HS-DSCH cell between two Node Bs

UE

UEHSDPA cell Serving HS-DSCH cell

Frequency#1’

Frequency#1’

Node B

Active set

Active set

UE

UEHSDPA cell


Frequency#1’

Frequency#1’

Active set

Active set

Node B1 Node B2

77

Outward mobility (HS-DSCH -> DCH)

The scenarios supported upon outward mobility (HS-DSCH -> DCH) are:• Intrafrequency, intra-SRNC, inter-Node B handover• Intrafrequency, inter-RNC handover• Intrafrequency, inter-RNC (SRNC) relocation• Interfrequency, intra-SRNC, inter-Node B handover

Channel-type switching from HS-DSCH to DCH is performed if the UE leaves anHSDPA-capable cell or the quality of a non-HSDPA-capable cell meets the conditiondescribed in section "Outward Mobility" on page 93. Fig. 4.18 shows the related intra-frequency, intra-SRNC, inter Node B handover scenario.

Fig. 4.18 Outward mobility between two Node Bs

Channel-type switching from HS-DSCH to DCH is performed regardless of the HSDPAcapability of a cell if the UE enters a cell that is controlled by the DRNC and the qualityof the cell meets the condition described in section "Outward Mobility" on page 93because HS-DSCH via the Iur interface is not supported. Fig. 4.19 shows the relatedintrafrequency, inter-RNC handover scenario. If SRNS relocation has beencompleted, channel-type switching from DCH to HS-DSCH can be performed asdescribed for inward mobility.

UE

UEHSDPA cell


Frequency#1’

Frequency#1’

Active set

Active set

Node B1 Node B2

Non HSDPA cell

SAY KIAT

Highlight

78

Fig. 4.19 Outward mobility between two RNCs

If Intrafrequency SRNS relocation without Iur interface is triggered, channel-typeswitching from HS-DSCH to DCH is performed before the SRNS relocation procedureis initiated, in other words before the SRNC sends the RANAP: RELOCATIONREQUIRED message. Fig. 4.20 shows the related intrafrequency, inter-RNC (SRNC)relocation scenario. If SRNS relocation has been completed, channel-type switchingfrom DCH to HS-DSCH can be performed as described for inward mobility.

Fig. 4.20 Outward mobility between two RNCs (SRNC relocation)

UE

UEHSDPA cell


Frequency#1’

Frequency#1’

Active set

Active set

SRNC DRNC

UE

UEHSDPA cell


Frequency#1’

Frequency#1’

Active set

Active set

SRNC

SAY KIAT

Highlight

79

If the SRNC receives a measurement report of event 2D/2D’/2D’’, channel-typeswitching from HS-DSCH to DCH is performed and interfrequency/intersystemhandover might be performed.

The SRNC receives a measurement report of event 2D/2D’/2D’’ in the event of:• The end of the coverage of an HSDPA-capable cell• A fading gap• High adjacent-channel interference

Fig. 4.21 shows the related interfrequency, intra-SRNC, inter-Node B handoverscenario.

Fig. 4.21 Outward mobility between different frequencies/systems

4.1.2.2 MAC-hs Reset and Loss of DataThe variable parameters used in the MAC-hs, for example TSN or T1, are required tobe synchronized between the Node B and the UE for the HARQ process and thereordering process at the UE. The SRNC informs the UE that the MAC-hs in the Node Bis reset and the variable parameters stored in the UE will be initialized. In UMR4.0-HS,the MAC-hs in the Node B is always reset when the serving HS-DSCH cell is changed.Therefore, it is preferred to set the “MAC-hs Reset Indicator” IE always to “true”. The“MAC-hs Reset Indicator” IE is included in the TRANSPORT CHANNEL RECONFIGU-RATION message but it is not included in NBAP messages from the Node B to theCRNC.

If the MAC-hs in the Node B is reset, MAC-d PDUs already sent to the Node B andstored in the MAC-hs are discarded. The SRNC stops transmission of HS-DSCH dataframes during a change of the serving HS-DSCH cell to minimize the loss of data.

If the UE is informed by the SRNC that the MAC-hs is reset, the UE sends the STATUSPDU to the SRNC. The SRNC can now retransmit the SDUs lost due to the MAC-hsreset.

UE

UENon HSDPA cell


Frequency#1’

Frequency#1’

Frequency#2’

Frequency#2’

HSDPA cell

Node B1 Node B2 or GSM area

UE

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

80

4.1.2.3 Measurement ConfigurationThis section provides an overview of the differences from the measurementconfiguration due to the introduction of HSDPA.

With UMR5.0, event 1D is introduced to detect the best cell within the active set, referto section "Change of the Serving HS-DSCH Cell" on page 84. Event 1D is ameasurement dedicated to HSDPA and independent of the measurements currentlydefined, 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 intrafrequencymeasurement events 1A, 1B and 1C.

4.1.2.4 HS-DSCH EstablishmentThe trigger conditions for HS-DSCH establishment are:

1. Cell_DCH state (no RAB is active)A PS RAB is established and the active set includes an HSDPA-capable cell.

2. Cell_FACH stateA PS RAB is established (no RAB is active) or channel-type switching is performedfrom FACH to HS-DSCH and an HSDPA-capable cell is available.

PS RAB establishment

In UMR5.0, HS-DSCH is not established in Cell_DCH state if compressed mode is ac-tive in the UE since simultaneous activation of compressed mode and HS-DSCH is notsupported. Therefore, compressed mode is deactivated before HS-DSCH is estab-lished. If the SRNC receives event 2D/2D’/2D’’, channel-type switching from HS-DSCHto DCH is performed and compressed mode is activated again.

Upon PS RAB establishment, the selection of the serving HS-DSCH cell depends on theRRC state of the UE:• Idle

HSDPA-capable UEs are moved to the HSDPA-capable cell when establishing anRRC connection as follows:– The “HCS_PRIO” IE of the HSDPA-capable cell should have a value lower than

the value of the non-HSDPA-capable cell so that all UEs send RRC CONNEC-TION REQUEST messages from the non-HSDPA-capable cell.

– The “Frequency info” IE in the RRC CONNECTION SETUP message is set to thefrequency of the cell where HSDPA is supported if all of the following conditionsare met: The HSDPA feature is enabled, the UE differentiation is set to “true”, andthe “Access Stratum Release Indicator” IE is set to “REL-5”. Furthermore, the”Establishment Cause” IE is set to “originating interactive call”, “originating back-ground call”, “terminating interactive call”, or “terminating background call”. The“Protocol Error Indicator” IE is set to “false” or is not included in the RRCCONNECTION REQUEST message.

This mechanism is not applicable if the “Resource Operational State” IE in the“HS-DSCH Resource Information” IE is set to “disabled”.If no cell is available due to load control, the RRC connection establishmentprocedure might be rejected. For more information on the load control mechanismsee UE Differentiation.

SAY KIAT

Highlight

SAY KIAT

Highlight

81

• Cell_FACHThe SRNC establishes a PS RAB on HS-DSCH if no other RAB is active at this time,the UE has an RRC connection to an HSDPA cell, and the UE supports HSDPA.

• Cell_DCH

The UE establishes the RRC connection as described for Idle mode. The SRNCestablishes HS-DSCH when a PS RAB is established, no other RAB is active at thistime, compressed mode is not active, and the UE supports HSDPA as follows.– If the active set consists of one cell and this cell is an HSDPA cell, the SRNC

establishes HS-DSCH on that cell. Otherwise, the SRNC establishes DCHinstead of HS-DSCH.

– If the active set consists of multiple cells, the SRNC establishes HS-DSCH on thecell which was added last. If this cell is a non-HSDPA cell or is controlled by theDRNC, the SRNC establishes DCH instead of HS-DSCH.

Channel-type switching from FACH to HS-DSCH

Upon channel-type switching from FACH to HS-DSCH due to traffic monitoring, theSRNC moves the UE to the HSDPA cell if the UE has an RRC connection to a non-HSDPA-capable cell and the UE supports HSDPA. If the UE has an RRC connection onthe HSDPA cell, the SRNC tries to perform channel-type-switching from FACH toHS-DSCH on that cell. This feature is applicable only when both the HSDPA feature andthe UE differentiation are set to “true”.

This mechanism is not applicable if the “Resource Operational State” IE in the“HS-DSCH Resource Information” IE is set to “disabled”.

If channel-type switching from FACH to HS-DSCH fails, the UE remains in the cell wherethe UE currently has the RRC connection. If the target HSDPA cell is overloaded,channel-type-switching from FACH to DCH is performed to the original cell where theUE currently has the RRC connection. Channel-type-switching from FACH to DCH mayfail if the original cell is overloaded, too.

The load control mechanism for this feature is described in UE Differentiation. Forinformation on the message sequence charts see "RAB Setup Procedure from DCH toHS-DSCH" on page 54.

4.1.2.5 Inward MobilityInward mobility is triggered if the UE enters an area where HSDPA is supported and thequality 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 reportedHSDPA cell is the best and much better than the reported non-HSDPA cells in order toavoid frequent channel-type switching between DCH and HS-DSCH. In addition,channel-type switching from DCH to HS-DSCH is not performed if compressed mode isactive in the UE.

The SRNC selects the serving HS-DSCH cell based on the measurement report (1A,1B, 1C, or if configured 1A’). The quality of each cell is derived from the “CPICH Ec/N0”IE included in the “Cell Measured Results” IE. HS-DSCH is only established if the differ-ence of the quality between the best HSDPA cell and the non-HSDPA cells is above apredefined threshold in order to avoid frequent channel-type switching between DCHand HS-DSCH. Furthermore, HS-DSCH is not established if compressed mode is activein the UE.

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

82

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 SRNCperforms an active set update.

– If the best cell is an HSDPA cell and is under the control of the SRNC, the differ-ence in quality between the best HSDPA cell and the non-HSDPA cells ischecked. The SRNC performs an active set update if this difference is below thepredefined threshold. If the difference is above the predefined threshold, theSRNC performs an active set update followed by channel-type switching fromDCH to HS-DSCH and setup of measurement 1D.

If the check of the measurement report results in an intrafrequency SRNS relocationwithout Iur interface, SRNS relocation is performed instead of an active set update andchannel-type switching from DCH to HS-DSCH.

Fig. 4.22 shows how a new radio link is established via a new Node B and HS-DSCHis established on that radio link. In this document, the red line indicates the transportbearer for DCH and the blue line indicates the transport bearer for HS-DSCH.

Fig. 4.22 Inward mobility

The SRNC includes all HSDPA-related parameters in the RADIO LINK RECONFIGU-RATION PREPARE and the TRANSPORT CHANNEL RECONFIGURATION messag-es since this is the first establishment of HS-DSCH and the UE and the Node B do nothave these parameters.

Fig. 4.23 shows the message sequence chart for inward mobility. If the trigger forestablishing the HS-DSCH is a measurement report (1B or 1C), the deletion of the radiolink(s) in Node B1/Node B2 might be performed by the active set update procedure. Ifthe radio link(s) have already been established via Node B2, the RL addition procedureis used to establish new radio link(s) via Node B2.

Since DL bit rate adaptation is not applicable when HS-DSCH is used, the CRNCterminates the transmitted code power (radio link quality) measurement by sending aDEDICATED MEASUREMENT TERMINATION REQUEST message to the relatedNode Bs upon the successful configuration of measurement 1D. The rate for the ULDTCH is changed to 64 kbit/s if the rate is other than 64 kbit/s and the transport beareris modified accordingly. For more information on the handling of the transport bearer forDTCH see "HSDPA RAB Handling" on page 43.

SRNC

UE

Node B2Node B1

SRNC

UE

Node B1 Node B2

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

83

Fig. 4.23 Message sequence chart for inward mobility

RADIO LINK RECONFIGURATION PREPARE

Node B1UE Node B2 SRNC

RADIO LINK SETUP REQUEST

RADIO LINK SETUP RESPONSE

Decision to performCTS (DCH -> HS-DSCH)

RADIO LINK RECONFIGURATION READY


MEASUREMENT REPORT (Event 1A)

Active Set Update

ALCAP Iub Transport Bearer Setup (DCH)

ACTIVE SET UPDATE

ACTIVE SET UPDATE COMPLETE

DCH -> HS-DSCH (CTS) Allocate H-RNTI

(Modification of UL DTCH (if necessary), Deletion of DL DTCH)


(Modification of UL DTCH (if necessary),Deletion of DL DTCH,

Establishment of HS-DSCH)


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-DSCHat the specified activation time

TRANSPORT CHANNEL RECONFIGURATION COMPLETE

MEASUEMENT CONTROL (Event 1D) (Setup)

84

4.1.2.6 Change of the Serving HS-DSCH CellA change of the serving HS-DSCH cell occurs if the UE uses HS-DSCH and moves with-in the area where HSDPA is supported. The purpose of a change of the servingHS-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 thequality of the current serving HS-DSCH cell is worse than the quality of anotherreported HSDPA cell. A change of the serving HS-DSCH cell is only performed if thequality of another HSDPA cell is much better than the quality of the current servingHS-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 activeset.

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 DCHis performed. In addition, channel-type switching from HS-DSCH to DCH is performedif the reported cell is controlled by the DRNC since HS-DSCH via the Iur interface is notsupported.

The measurement 1D is configured as follows:

1. The “Triggering Condition 2” IE in the MEASUREMENT CONTROL message is setto “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. Acell individual offset is not used for event 1D. Therefore, the “Use CIO” IE to evaluatethe actual quality of the cell is not included in the MEASUREMENT CONTROLmessage. The SRNC selects the serving HS-DSCH cell based on the measurement re-port for event 1D and establishes HS-DSCH.

The SRNC selects the cell reported by the measurement report of event 1D.

1. If this cell is an HSDPA cell and is controlled by the SRNC, the SRNC performs achange of the serving HS-DSCH cell.

2. If this cell is a non-HSDPA cell or is controlled by the DRNC, the SRNC performschannel-type switching from HS-DSCH to DCH, see 4.1.2.7"Outward Mobility" onpage 93.

The SRNC ignores the measurement report of event 1D if the reported cell is the sameas the current serving HS-DSCH cell.

Fig. 4.24 shows how the serving HS-DSCH cell is moved from one radio link to anotherunder the control of the same Node B.

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

85

Fig. 4.24 Intra-Node B change of the serving HS-DSCH cell due to measurement event 1D

The SRNC sends a RADIO LINK RECONFIGURATION PREPARE message to therelated Node B, that is Node B1 in Fig. 4.24. The RADIO LINK RECONFIGURATIONPREPARE message includes the cell-specific parameters since the Node B1 alreadyhas the HSDPA-related parameters. The Node B knows the cell where HS-DSCH isnewly established and where HS-DSCH is deleted by referring to the “HS-PDSCH RLID” IE.

Similarly, the TRANSPORT CHANNEL RECONFIGURATION message includes thecell-specific parameters since the UE already has the HSDPA-related parameters. Inaddition, the “MAC-hs Reset Indicator” is set to “true” in the TRANSPORT CHANNELRECONFIGURATION message.

Fig. 4.25 shows the message sequence chart for an intra-Node B change of the servingHS-DSCH cell due to measurement event 1D. The “target cell” indicates the cell whereHS-DSCH will be established and the “source cell” indicates the cell where HS-DSCHwas established before the serving HS-DSCH cell was changed.

SRNC

UE

Node B2

SRNC

UE

Node B2Node B1 Node B1

86

Fig. 4.25 Message sequence chart for an intra-Node B change of the serving HS-DSCH cell (event 1D)

Fig. 4.26 shows how the serving HS-DSCH cell is moved from one radio link to anotherradio link between two different Node Bs.

Fig. 4.26 Inter-Node B serving cell change due to measurement event 1D

The SRNC sends a RADIO LINK RECONFIGURATION PREPARE message to theNode Bs concerned, these being Node B1 and Node B2 in Fig. 4.26. The RADIO LINKRECONFIGURATION PREPARE message sent to the Node B which releasesHS-DSCH, that is Node B1 in Fig. 4.26, only includes “HS-DSCH MAC-d flows todelete” to delete all HS-DSCH MAC-d flows.

The RADIO LINK RECONFIGURATION PREPARE message sent to the Node B whichestablishes HS-DSCH, that is Node B2 in Fig. 4.26, includes all HSDPA-related

Node B1UE SRNC

Decision to change HS-DSCH serving cell

Allocate H-RNTI


(for target cell)

UE can start “listening” to the newHS-DSCH at the given activation time





Deallocate H-RNTI(for source cell)

SRNC

UE

Node B2

SRNC

UE

Node B2Node B1 Node B1

87

parameters since this is the first HS-DSCH establishment for that Node B. The HSDPA-related parameters are the same as the parameters used to configure HS-DSCH. TheTRANSPORT CHANNEL RECONFIGURATION message includes only the cell-specific parameters since the UE already has the HSDPA-related parameters. Inaddition, the “MAC-hs Reset Indicator” is set to “true” in the TRANSPORT CHANNELRECONFIGURATION message.

Fig. 4.27 shows the message sequence chart for inter-Node B serving cell change dueto measurement event 1D. The “target cell” indicates the cell where HS-DSCH will beestablished and the “source cell” indicates the cell where HS-DSCH was established be-fore the serving HS-DSCH cell was changed.

Fig. 4.27 Message sequence chart for inter-Node B serving cell change (event 1D)

Node B1UE SRNC


Allocate H-RNTI


(for target cell)





Node B2

MEASUREMENT REPORT (Event 1D)

RADIO LINK RECONFIGURATION PREPARE (Deletion of HS-DSCH)

RADIO LINK RECONFIGURATION PREPARE (Establishment of HS-DSCH)






88

Measurement report 1A, 1B, 1C, or, if configured, 1A’

The active set of a UE varies as the UE moves from one cell to another. As a conse-quence, a new HSDPA cell can be added to the active set and this cell might be the bestone. The quality of each cell is derived from the CPICH Ec/N0 IE included in the “CellMeasured Results” IE.

The SRNC selects the serving HS-DSCH cell based on the measurement report ofevent 1A, 1B, 1C or, if configured, 1A’ and a predefined threshold to avoid frequentchange of the serving HS-DSCH cell.

The SRNC selects the new active set based on the “Event results” IE. Afterward, theSRNC 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 currentserving HS-DSCH cell but the difference between the quality of the best cell andthe 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 qualitybetween the best cell and the current serving HS-DSCH cell is above thepredefined threshold. In this case, the SRNC performs an active set updatefollowed by a change of the serving HS-DSCH cell if the best cell is an HSDPAcell and is controlled by the SRNC. If the best cell is a non-HSDPA cell or is con-trolled by the DRNC, the SRNC performs channel-type switching from HS-DSCHto 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 relocationwithout Iur interface, SRNS relocation is performed instead of an active set updateand/or channel-type switching from DCH to HS-DSCH.

If the change of the serving HS-DSCH cell is triggered by the measurement reportingevent 1A or 1A’, the current serving HS-DSCH cell is not deleted by the active set updateprocedure. If, however, the change of the serving HS-DSCH cell is triggered by meas-urement reporting event 1B or 1C, the current serving HS-DSCH cell might be deletedby the active set update procedure. Therefore, the message sequence chart is differentin both cases.

Fig. 4.28 shows a scenario where the radio link on which HS-DSCH was previouslyestablished is not deleted after the change of the serving HS-DSCH cell.

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

89

Fig. 4.28 Change of the serving HS-DSCH cell due to measurement event 1A

If the active set update procedure is completed, the message sequence is the same asfor inter-Node B change of the serving HS-DSCH cell due to measurement event 1D. Ifthe new radio link is established via a Node B that currently has HS-DSCH andHS-DSCH is moved to that radio link, the message sequence after the active set updateprocedure is the same as for an intra-Node B change of the serving HS-DSCH cell dueto measurement event 1D. Fig. 4.29 shows the message sequence chart for the changeof the serving HS-DSCH cell due to measurement event 1A where the current servingHS-DSCH cell is not deleted. “Target Cell” indicates the cell where HS-DSCH will beestablished and “Source Cell” indicates the cell where HS-DSCH was establishedbefore the serving HS-DSCH cell was changed.

SRNC

UE

Node B2

SRNC

UE

Node B1 Node B1 Node B2

m

90

Fig. 4.29 Message sequence chart for the change of the serving HS-DSCH cell (event 1A)

Node B1UE SRNC


Allocate H-RNTI


(for target cell)





Node B2

MEASUREMENT REPORT (Event 1A)

RADIO LINK RECONFIGURATION PREPARE (Deletion of HS-DSCH)







Serving HS-DSCH Cell Charge

RADIO LINK ADDITION REQUEST

RADIO LINK ADDITION RESPONSE

Active Set Update

ACTIVE SET UPDATE


91

Fig. 4.30 shows a scenario where the radio link on which HS-DSCH was previouslyestablished is deleted after the change of the serving HS-DSCH cell.

Fig. 4.30 Change the serving HS-DSCH cell due to measurement event 1C

If the active set update procedure is completed, the current serving HS-DSCH cell isdeleted. In order to minimize the loss of data, the SRNC stops the transmission ofHS-DSCH data frames before the active set update procedure is performed. The SRNCsends a RADIO LINK RECONFIGURATION PREPARE message to the Node Bconcerned, that is Node B2 in Fig. 4.30, if the active set update procedure is complete.The RADIO LINK RECONFIGURATION PREPARE message includes all HSDPA-related parameters which were used in the previous configuration of HS-DSCH. TheTRANSPORT CHANNEL RECONFIGURATION message includes all HSDPA-relatedparameters since the radio link on which HS-DSCH is mapped has been deleted by theactive set update procedure and the UE has released all HSDPA-related parameters.

Fig. 4.31 shows the message sequence chart for the change of the serving HS-DSCHcell due to measurement event 1C. The “target cell” indicates the cell where theHS-DSCH will be established and the “source cell” indicates the cell where theHS-DSCH was established before the serving HS-DSCH cell was changed.

The transport bearer corresponding to the source serving HS-DSCH cell is deleted bythe active set update procedure and the transport bearer corresponding to the targetserving 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)

SRNC

UE

Node B2

SRNC

UE

Node B1 Node B1 Node B2

92

Fig. 4.31 Message sequence chart for the change of the serving HS-DSCH cell (Event 1C)

Node B1UE SRNC


Allocate H-RNTI


(for target cell)




Node B2

MEASUREMENT REPORT (Event 1C)




HS-DSCH Reestablishment



ACTIVE SET UPDATE


RADIO LINK DELETION REQUEST

RADIO LINK DELETION RESPONSE

Active Set Update



93

4.1.2.7 Outward MobilityOutward mobility occurs if the UE leaves the area where HSDPA is supported. In thiscase, the quality of the non-HSDPA cell is much better than the quality of the HSDPAcell or the HSDPA cell is removed from the active set. Therefore, channel-type switchingfrom 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 andthe quality of the non-HSDPA cell is better than the quality of the HSDPA cells. Chan-nel-type switching from HS-DSCH to DCH is performed only when the quality of thecurrent serving HS-DSCH cell is much worse than the quality of the non-HSDPAcells 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 beincluded in the next active set.

3. Measurement report (event 1A, 1B, 1C, 1D, or, if configured, 1A’) from the UE andthe quality of the cell under the control of the DRNC is better than the quality of theHSDPA cells under the control of the SRNC.

4. Measurement report (event 2D/2D’/D’’) from the UE. Channel-type switching fromHS-DSCH to DCH is performed only when the quality of the current servingHS-DSCH cell is much worse than the quality of the non-HSDPA cells in order toavoid frequent channel-type switching between HS-DSCH and DCH.

5. Measurement report (event 1A, 1C, or, if configured, 1A’) from the UE andintrafrequency SRNS relocation without Iur interface is triggered.

Outward mobility is subdivided into an intrafrequency and an interfrequency/intersystemprocess.

Detection of outward mobility (intrafrequency process)

Outward mobility is detected during the change of the serving HS-DSCH cell processdue 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 relocationduring channel-type switching from HS-DSCH to DCH, it is treated as a measurementreport that is received within the time period between SRNS relocation is triggered andthe SRNC sends an RANAP: RELOCATION REQUIRED message.

If intrafrequency SRNS relocation with Iur interface is performed, the UE does not useHS-DSCH because HS-DSCH via Iur interface is not supported.

Fig. 4.32 shows how a new radio link is established via a new Node B while this Node Bdoes not support HSDPA.

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

94

Fig. 4.32 Outward mobility

The current serving HS-DSCH cell is deleted if the active set update procedure iscompleted. The SRNC stops transmission of the HS-DSCH data frame before channel-type switching from HS-DSCH to DCH in order to minimize the loss of data. If the activeset is not changed, that is the trigger is event 1D or SRNC relocation, only channel-typeswitching from HS-DSCH to DCH is performed.

Fig. 4.33 shows the message sequence chart for outward mobility. For more informa-tion on the handling of the transport bearer for DTCH see "HSDPA RAB Handling" onpage 43.

Since DL bit rate adaptation is applicable when DCH is used, the CRNC sends aDEDICATED MEASUREMENT INITIATION REQUEST message to the relatedNode Bs to initiate the transmitted code power (radio link quality) measurement ifmeasurement event 1D is released.

SRNC

UE

Node B2

SRNC

UE

Node B1 Node B2Node B1

95

Fig. 4.33 Outward mobility

Node B1UE SRNC

Decision to perform CTS (HS-DSCH -> DCH)

RADIO BEARER RECONFIGURATION COMPLETE

UE can start “listening” to DCHat the given activation time

RADIO BEARER RECONFIGURATION


Node B2

MEASUREMENT REPORT (Event 1B/1C)

RADIO LINK RECONFIGURATION PREPARE (Modification of UL/DL DTCH)


ALCAP Iub Transport Bearer Setup (UL/DL-DSCH)

HS-DSCH Reestablishment



ACTIVE SET UPDATE


RADIO LINK DELETION REQUEST

RADIO LINK DELETION RESPONSE

Active Set Update

Deallocate H-RNTI

ALCAP Iub Transport Bearer Release (DCCH + DTCH)


MEASUREMENT CONTROL (Event 1D) (Release)

96

Detection of outward mobility (interfrequency / intersystem process)

If the UE enters the end of the coverage of an HSDPA-capable cell, the quality of thatcell becomes insufficient and the SRNC may receive a measurement report ofevent 2D/2D’/2D’’.

The following procedure is performed if the SRNC receives the measurement report ofevent 2D/2D’/2D’’:

1. The SRNC performs channel-type switching from HS-DSCH to DCH withoutchanging the frequency/system.

2. The SRNC orders the UE to perform interfrequency/intersystem measurement.

If the condition for interfrequency/intersystem handover is met, the UE is moved to an-other frequency or system. The UE stays on the frequency currently used if the conditionfor an interfrequency/intersystem handover is not met and interfrequency/intersystemmeasurement is deactivated.

4.1.2.8 DRNC BehaviorHSDPA is not established via the Iur interface. If the RNC acts as a DRNC, the SRNCmay request the DRNC to establish HS-DSCH. In this case, the DRNC rejects therequest with the case value “DL Shared Channel Type not Supported”.

4.1.2.9 Error HandlingThis section summarizes the handling of failures.

HS-DSCH establishment or release

HS-DSCH establishment or release is subdivided into two phases:• Active set update• Channel-type switching between HS-DSCH and DCH or change of the serving

HS-DSCH cell

For more information on error handling see "HSDPA RAB Handling" on page 43.

When channel-type switching from DCH to HS-DSCH is performed, the active setupdate 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 reconfigurationprepare failure) or an ALCAP failure, DCH is still available even if HS-DSCH is not avail-able. Therefore, the SRNC keeps the current configuration, that is DCH. Channel-typeswitching 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 setupdate 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 causevalue other than “not enough user plane processing resources”) or an ALCAP failure,HS-DSCH is released and RRC connection reestablishment is performed sinceHS-DSCH is not established on the best cell any more. Channel-type switching fromFACH to HS-DSCH is triggered by traffic monitoring.

Upon an admission control failure or an NBAP/RNSAP failure (RL reconfigurationprepare failure with the cause value “not enough user plane processing resources”), aretry at the minimum rate of the DCH is performed.

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

97

When the serving HS-DSCH cell is changed, the active set update procedure has beensuccessfully completed (event 1A, 1B, 1C, or, if configured, 1A’). In the case of event1D or 2D/2D’/2D’’, however, the active set is unchanged. Since the associated DCH hasalready 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 valueother than “not enough user plane processing resources”) or an ALCAP failure,HS-DSCH is released and RRC connection reestablishment is performed sinceHS-DSCH is not established on the best cell any more. Channel-type switching fromFACH to HS-DSCH is triggered by traffic monitoring.

Upon an admission control failure or an NBAP/RNSAP failure (RL reconfigurationprepare failure with the cause value “not enough user plane processing resources”), aretry at the minimum rate of the DCH is performed.

If an RRC message fails and RRC connection reestablishment is allowed according tothe current system, RRC connection reestablishment is performed. The failure handlingof 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 causevalue “synchronization failure” from the cell where HS-DSCH is currently establishedand the radio link concerned is not the last one, the radio link is deleted. The ULsynchronization immediately gets lost and channel-type switching from HS-DSCH toDCH is performed. This behavior is similar to outward mobility handling where theserving HS-DSCH cell is deleted by event 1B. If the radio link concerned is the last one,RRC connection reestablishment is performed. If the cause value of the RADIO LINKFAILURE INDICATION message is other than “synchronization failure”, no HSDPAspecific error handling is performed.

Reception of measurement report 1D during change of the serving HS-DSCHcell/outward mobility

If the SRNC receives a measurement report of event 1D during a change of the servingHS-DSCH cell/outward mobility and the active set update is completed, the SRNChandles this report in a way similar to other intrafrequency measurement reports duringRAB setup. Measurement reports other than event 1D are handled during inwardmobility/change of the serving HS-DSCH cell/outward mobility similarly to their handlingduring RAB setup. If the SRNC receives a measurement report of event 1D during anactive set update, the SRNC handles this report in a way similar to other intrafrequencymeasurement 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 aRELEASE CALL message.

Missing RL restore indication

The CRNC expects to receive an RL RESTORE INDICATION message during radio linkestablishment:• 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 servingHS-DSCH cell change followed by an active set update. Even if the UL

98

synchronization is not achieved in the new radio link, the SRNC receives an ACTIVESET UPDATE COMPLETE message via the existing radio links. The SRNC startsthe change of the serving HS-DSCH cell upon reception of the ACTIVE SETUPDATE COMPLETE message regardless of the reception of an RL RESTOREINDICATION message from the cell where HS-DSCH is established. If the timerT_sync has expired, the same error handling is applied as described for a radio linkfailure of the radio link onto which the serving HS-DSCH cell is mapped.

4.1.2.10 UE DifferentiationThe purpose of the UE differentiation is to assign power resources to HSDPA UEs asmuch as possible. This section describes the interdependencies between UEdifferentiation, load control, cell configuration, and UE type.

The available load-control types are:• No load control• Load-overflow mechanism• Load-balancing mechanism

UE differentiation uses the load-overflow mechanism. A traffic overflow fromfrequency 1 to frequency 2 occurs if a cell in frequency layer 1 is not able to carryadditional radio links. In the UE differentiation mechanism, the CRNC selects the cell tobe checked depending on the cell configuration and the UE type, that is R99 or HSDPA.

Tab. 4.7 shows the interdependencies between UE differentiation, load control, cellconfiguration and UE type. “HSDPA” indicates the cell where HSDPA is supported andthe HSDPA state is enabled. “non HSDPA” indicates the cell where neither HSDPA issupported nor the HSDPA state is enabled. If HSDPA is disabled, UE differentiation isnot performed even if UE differentiation is enabled.

Note 1: A non-HSDPA cell is selected at first. If this procedure fails, an HSDPA cell isselected. The load-overflow mechanism is applied in the cell in both cases.

Note 2: An HSDPA cell is selected at first. If this procedure fails, a non-HSDPA cell isselected. The load-overflow mechanism is applied in the cell in both cases.

UE differentiation enabled UE differentiation disabled

HSDPA - non HSDPA(R99 UE in non HSDPA cell)

UE differentiation (Note 1) Load control: Load control type

HSDPA - non HSDPA(HSDPA UE in non HSDPA cell)


HSDPA - non HSDPA(R99 UE in HSDPA cell)

Load control: Load control type Load control: Load control type

HSDPA - non HSDPA(HSDPA UE in HSDPA cell)


non HSDPA - non HSDPA(R99 UE)


non HSDPA - non HSDPA(HSDPA UE)


Tab. 4.7 Interdependency between UE differentiation, load control, cell configuration and UE type

SAY KIAT

Highlight

99

4.1.3 HSDPA Admission Control and Congestion ControlThe HSDPA feature in UMR5.0 requires functionality to admit UEs onto the HSDPAchannel, i.e. the HS-DSCH and the HS-PDSCH. UEs which support HSDPA are onlyadmitted to the HSDPA channel if certain preconditions, such as a successful loadcheck 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 tomaximize the gain HSDPA provides to the user and the cell capacity. UMR5.0 supportsonly the setup of PS Interactive/Background bearers on the HS-DSCH. Although usedin an HSDPA-capable cell, these bearers sometimes have to be set up on dedicatedchannels (DCHs), however, if a UE is only capable of 3GPP Rel 99 or if no more HSDPAresources are available, etc. To avoid such a scenario, additions and changes havebeen made to the existing rate restriction algorithm.

If, however, PS Interactive/Background RABs are set up on DCHs, the operator is ableto restrict or to lower the rates on the relevant DCH. This keeps the available HSDPAresources 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 therate itself.

4.1.3.1 Radio Resource Management (RRM) IssuesThis section deals with the following topics:• RRM functionalities in the controlling RNC (CRNC) affected by HSDPA• Interactions between RRM functions

RRM functionalities in the controlling RNC (CRNC)

The CRNC handles the cell-related RRM functionalities. Fig. 4.34 illustrates those RRMfunctionalities that are located in the CRNC. HSDPA admission control affects the high-lighted functionalities.

Fig. 4.34 Radio resource management functions in the CRNC

Interactions between RRM functions

Admission control reacts upon different serving RNC (SRNC) radio link (RL) requestsby either reporting a response or a failure. Admission control’s behavior upon receptionof requests related to DPCHs has only been slightly modified.

Admission control handles HSDPA-related requests in a similar way to DPCH-relatedrequests. The handling is based on the DPCHs required by the HSDPA-capable UE. In

Resource Load Control

Interfrequency

Congestion Node B Measurem. Power Control

Initial Values forPower Control

Allocation Control Control

Load Control

Affected by HSDPAAdmission Control

AdmissionControl

Code Allocation,Release

RestrictionControl

CongestionControl

MeasurementReporting Control

PreprocessingControl

100

general, each UE on a PS RAB which is associated to the HSDPA channel requires thefollowing:• 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) withSF 256

– One associated DPCH (signaling radio bearer SRB) for traffic of varying SF re-gardless of whether or not waiting data exists

The decision of admission control about whether or not to admit a UE on a channel de-pends on periodic common measurements. The relevant measurement reports are sentvia NBAP. These reports indicate the ratio of non-HSDPA power in relation with themaximum configured power in the relevant Node B. Each report is treated by higher-lay-er-filtering (floating average) over a certain time frame.

Fig. 4.35 illustrates the interactions between admission control and code allocation in-cluding the protocols and measurements, call processing, and OAM databases in theevent of allocating or deallocating resources.

Fig. 4.35 Interactions between admission control and code allocation

CRNCMeasure-

mentDatabase

CRNCDynamicDatabase

OAMDatabase

Yes

No

Yes

No

Yes

No

RNSAP: Radio Link Setup Request

Dea

lloca

te R

esou

rces

DL Scramblingand

ChannelizationCode

Allocation/Release

RNSAP: Radio Link Deletion Request

RNSAP: Radio Link ReconfigurationCommit

RNSAP: Radio Link ReconfigurationCancel

RNSAP: Radio Link Addition Request

RNSAP: Radio Link Setup Response

RNSAP: Radio Link Addition Failure

RNSAP: Radio Link Reconfiguration Ready

RNSAP: Radio Link Reconfiguration Failure

RNSAP: Radio Link Addition Response

RNSAP: Radio Link Setup Failure

CRNC: Congestion Indication

NBAP: Common Measurement Report

Resource Allocation

RNSAP: Radio Link ReconfigurationPrepare

AdmissionControl

RNSAP: Radio Link Deletion Response

Allo

cate

Res

ourc

es}}

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

101

4.1.3.2 Load, Power, and Code ManagementIn the event of a request to set up, reconfigure, or hand over a new radio link, admissioncontrol determines the current load. The decision regarding whether to admit or rejectthis request is based on the load value determined and the additional load occurringthrough the radio link’s setup, reconfiguration or handover. Admission control appliesthe following formula for this decision:

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.0for the received total wideband power (RTWP) on the UL.

In the DL direction, on the other hand, the system load is calculated analogously to thealgorithm defined in UMR3.5. The total transmitted carrier power measurement, howev-er, is replaced by the measurement of the non-HSDPA power if both the cell is capableof serving HSDPA and the non-HSDPA power measurement has been successfully es-tablished.

The transmitted-carrier power measurements will only be set up if HSDPA has been dis-abled or the Node B does not support non-HSDPA power measurements due to an up-grade phase, etc. In this case, admission control performs the load calculation with theresults of the transmitted-carrier power measurements.

When setting up a DL radio link for HSDPA, admission control is performed for the as-sociated dedicated physical channels (DPCHs). The admission control algorithm thenhas to admit these channels in a similar way as for other dedicated channels. In orderto take into account the associated DPCHs and the UL DPCH of the HS-DPCCH of allHSDPA users in the event of congestion, too, congestion control is adapted to this situ-ation. For details, please refer to "Congestion Control Algorithm" on page 106.

Update of load values

On the UL, the update of the load values is based on the RTWP measurements. Theupdate is then performed upon setup, release, handover, or reconfiguration of the rele-vant radio link.

In the DL direction, admission control updates the load values of the non-HSDPA loadwhen handling a new non-HSDPA measurement report and at the setup, release,handover, or reconfiguration of the relevant radio link.

Allocation of the power for HS-DSCH

The allocation of the power for the HS-DSCH is described in "Code and Power Alloca-tion" on page 112.

Error handling

If the non-HSDPA power measurements cannot be initiated, transmitted carrier powermeasurements will be started instead. As a consequence, the cell operates only in non-HSDPA mode. "State Management" on page 108 describes the specific handling of themeasurement setup and the related error handling in more detail.

currentLoad newLoad oldLoad–+ Threshold<

102

4.1.3.3 Admission Control in the CRNCThis section describes the handling of radio link setups, reconfigurations, and hando-vers by admission control in the CRNC.

In general, HSDPA admission control does not interact with admission control for DPCHusers. If a congestion occurs on the UL or if the setup of either the associated DPCH inthe UL direction or the UL DPCH for the HS-DPCCH fails, however, admission controlrejects admitting PS bearers on the HSDPA channel.

With regard to the admission decision for HSDPA users, the CRNC which is aware of itsassociated Node Bs distinguishes between a new-call request/transport channel-typeswitching (CTS) and a soft/softer handover. In this context, the distinction is as follows:a completely new radio bearer, on the one hand, is set up in its own RNC. In other words,the SRNC is identical with the CRNC. A radio link setup request via the RNSAP protocol,on the other hand, identifies a soft/softer/hard handover. If an RRC connection reestab-lishment request is received via the Iur interface, however, CTS is performed becauseUMR5.0 does not support HSDPA via the Iur interface.

Basically, the HSDPA feature impacts on admission control handling for HSDPA userswith respect to the following topics:• Handovers due to

– Change of the serving HSDPA cell– Inward mobility– Outward mobility

• New calls and call reestablishment• Reconfiguration from DCH to HS-DSCH and vice versa

Handovers

Whenever a handover of an existing bearer associated with the HSDPA channel is per-formed, the MAC-hs is reset. If congestion occurs, admission control does not reject thehandover of the related DPCHs. Furthermore, the handover of a PS bearer on the oldcell’s HSDPA channel to be located on the new cell’s HSDPA channel is performed in asimilar way as a handover for DCHs.

With respect to mobility, admission control handling is performed as follows, dependingon 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 servingcell 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 theold serving cell. This requires a new handling method, too.

– For the new serving cell, nothing has to be released, which is also a new handlingmethod.

– The CRNC allocates the H-RNTI (radio network temporary identify) for the newserving cell.

– The CRNC deallocates the H-RNTI for the old serving cell.• Case 2: Inward mobility

– On the DL, the load information for the associated DPCH (SRB 3.4 kbit/s) is avail-able.

– On the UL, the load information for both the HS-DPCCH (for the HSDPA radio link)and the associated DPCCH is available (UL PS bearer 64 or 384 kbit/s).

– In both the UL and DL directions, the old load information is available.

103

– Upon RL reconfiguration, the old load of all cells in the active set is removed. Thishandling 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 releasesprior to UMR5.0. In the event of a multicall, the new bearer is set up in DCH state. Thesetup is automatically performed by the SRNC. Furthermore, the cell’s capability of pro-viding HSDPA service must be determined as described in "Code and Power Allocation"on page 112.

Admission control then has to verify the possibility of setting up the required UL DPCHfor the SRB and PS traffic (i.e. the associated DPCH) and both the UL- and DL-associ-ated DPCHs for the HS-DPCCH. Therefore, in the event of a RAB setup or an increaseof the load, admission control checks the “Congestion Indication” IE and will only pro-ceed if this IE’s value is “FALSE”. If this condition is not fulfilled, however, admissioncontrol rejects the setup on the HSDPA channel.

Admission control uses several load thresholds for the different DPCHs which are re-quired for an HSDPA-capable UE to operate. The thresholds are as follows:• For the associated DPCH on the DL, the threshold for the SRB 3.4 kbit/s is applied.

The HS-DPCCH required in the UL direction uses the threshold for this SRB, too.• For the associated DPCH on the UL, the thresholds for the PS interactive/back-

ground bearers is applied. Their corresponding UL rate thresholds are based on theslope function.

• Since the HS-DPCCH is only used for control issues, a new load is applied for theHS-DPCCH which is exclusively applicable to the HSDPA radio link, thus requiringa new physical channel type attribute for the HS-DPCCH. The gain factors Bc andBd, however, will only be system data.

With regard to requirements concerning the signal-to-interference ratio (SIR), the valuesof the channels mentioned before are applied.

Since two channels, i.e. the associated DPCH and the HS-DPCCH which is only appli-cable for the HSDPA radio link, are always used on the UL, HSDPA admission controlhas to consider these two pieces of load information.

With respect to call establishment and reestablishment in UMR5.0, admission controlhandling 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 mobilityhandover.

i NOTEWhen admission control rejects the setup on the HSDPA channel, a retry onDCH state with the minimum rate is attempted. RAB pre-emption will then ap-ply, too.

104

• Case 2: PS RAB setup triggering a FACH to HS-DSCH procedure or CTS due totraffic triggering a FACH to HS-DSCH procedureAdmission control handles these situations in the same way as an inward mobilityhandover. In these situations, however, only one radio link is applicable and no loadinformation is available.

• Case 3: HS-DSCH to DCH procedure due to RAB assignment/releaseAdmission control handles this situation in the same way as an outward mobilityhandover.

• Case 4: HS-DSCH to FACH procedure due to inactivity or reestablishment toFACH– 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 twopieces of the old UL load information: one for the UL PS DTCH and one for theUL HS-DPCCH.

– The CRNC deallocates the H-RNTI.

Reconfiguration from DCH to HS-DSCH and vice versa

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

4.1.3.4 Restriction Control in the CRNC for HSDPA

In most cases, it is more beneficial for the whole system to set up a PS radio bearer (onlyPS interactive/background bearer in UMR5.0) on top of the HS-PDSCH instead of ontop of the DCH. Some situations may occur, however, in which the setup of the PS in-teractive/background bearer on top of the DCH is required. This exception is valid forthe following situations:• No support of HSDPA by the UE• No support of the multicall/bearer combination on the HSDPA channel by the UE

The UE supports the PS interactive/background bearer on top of the HS-PDSCH butnot for the required service combination.

• Not enough user plane processing resourcesThe UE supports the PS interactive/background bearer on top of the HS-PDSCH.One of the following situations occurred, however:– No more resources are available in the Node B’s hs-CHC. As a consequence, the

Node B rejects the setup of the PS bearer on top of the HSDPA channel with thecause set to “Not Enough User Plane Processing Resources“.

– The current load is too high in order to allow the setup of the associated DPCHs.As a consequence, admission control rejects the setup of the PS bearer on top ofthe HS-PDSCH. In this situation, however, a retry on the DCH with the minimumUL/DL rate of 8 kbit/s/8 kbit/s and pre-emption is possible.

In any of these situations, the admission of the PS interactive/background bearer on theDCH is to be limited to rates equal to or lower than 128 kbit/s in HSDPA-capable cells.This is due to avoid HSDPA-capable UEs not allowed on the HS-PDSCH or Rel 99-only

i NOTEHSDPA restriction control is an optional feature controlled by the SWP “HSDPA Restric-tion Control“ flag and only enabled if the feature is part of the contract.

105

UEs consume cell capacity and thus degrading the performance of HSDPA. Otherwise,HSDPA would suffer from a lack of available resources because it can only use the pow-er remaining after DPCH bearers have been served. As currently applied, this restrictionis performed by limiting the minimum available spreading factor rather than the rate it-self.

The operator can restrict the minimum available SF, using the additional new restrictioncontrol functionality with the following key properties:• This rate restriction is to be independent of the normal rate restriction.

Therefore, an additional new separate parameter which is configurable via the OMC-R is specified in order to restrict the minimum available SF for the PS interac-tive/background RAB on top of the DCH in the relevant HSDPA cell.

• The new rate restriction only applies for the PS interactive/background bearers onthe DCH in an HSDPA-capable cell. PS interactive/background bearers on DCHs innon-HSDPA-capable cells, however, are not affected.

• The effectively-allowed minimum SF is the maximum of the following: the minimumSF allowed by the normal restriction control and the minimum SF allowed by the spe-cific restriction control for the PS interactive/background bearer.Therefore, the existing (normal) restriction control is modified in such a way that it isable to determine this maximum and, consequently, the applicable SF.The following mathematical expression is applied when determining the effectively-allowed minimum SF:

• Setting the minimum available SF for the PS interactive/background RAB on theDCH in an HSDPA-capable cell to the lowest SF (8) in the OMC-R will disable thisnew restriction control mechanism.

• The new rate restriction mechanism is only available if the specific cell’s HSDPAchannel serves a predefined number of HSDPA-capable UEs. Otherwise, the SFsand, therefore, the rates, too, will not be restricted, thus maximizing the throughputfor the Rel 99 UEs.

• The parameters are cell-specific

The new restriction control algorithm is only applied if both the “HSDPA Restriction Con-trol“ optional feature flag is enabled and the number of UEs using HSDPA service ex-ceeds a predetermined threshold. Admission control thus uses the already allocated H-RNTI to determine the number of UEs allocated on the HSDPA channel.

Changed restriction control procedure for HSDPA

Admission control uses the already allocated H-RNTI to determine whether HSDPA-ca-pable UEs are assigned to the HSDPA channel. The new rate restriction mechanism isapplied when the allocated H-RNTI is greater than the specified threshold and the ad-mission of a new PS interactive/background bearer is evaluated. Furthermore, admis-sion control determines the minimum effectively allowed SF.

If the new restriction control algorithm fails only due to the minimum SF allowed by thenormal restriction control, the currently existing restriction failure cause will always beused.

In the event of a bearer failing the new HSDPA restriction control, the CRNC always pro-vides the failure cause of the HSDPA restriction control to the SRNC. Furthermore, theCRNC always provides the minimum available SF to the SRNC.

minEffSF max minNormSF minHsdpaSF[ , ]=

106

At the setup (RAB establishment, reestablishment, or CTS) or handover of a bearer (softor inter-frequency handover), the new HSDPA-specific restriction control mechanism isapplied. The SRNC, however, then handles the restriction according to the current im-plementation. In other words, it retries the procedure with the minimum rate instead ofthe minimum SF.

Furthermore, the new HSDPA-specific restriction control is applied for bearer reconfig-uration, i.e. bit rate adaptation UP or DOWN. A failure in the BRA procedure due to HSD-PA restriction control requires a new error handling of the SRNC. If the normal restrictioncauses the failure, however, the existing handling will be applied.

Handling of a BRA request upon activation of HSDPA restriction control

If the threshold for activating the HSDPA-specific restriction control has been reached,the PS interactive/background bearer may issue a BRA UP or DOWN procedure. Re-gardless of whether the BRA UP or BRA DOWN procedure is used, i.e. in any configu-ration of the bearer, the SRNC performs the subsequent error handling if the bearer failsdue to the HSDPA-specific restriction check. The following actions are carried out perUTRAN cell:• First, the SRNC cancels that RL reconfiguration over the SRNC and/or the DRNC

which has successfully been reconfigured before.• The SRNC checks the value of the minimum available SF.

– If the RLs in the active set fail due to the HSDPA-specific restriction control whenthe UE is in soft handover state, the SRNC selects the minEffSF.

– If the current bearer’s SF is smaller than the minimum available SF, the SRNC per-forms a BRA DOWN procedure to a DL rate which is equal to the rate indicatesby the minimum available SF or the next lower rate.

– Otherwise, if the current bearer’s SF is greater than the minEffSF, the SRNC willkeep the current configuration of the bearer(s).

4.1.3.5 Admission Control in the Node BIn UMR5.0, no admission control mechanism for the HS-DSCH, and therefore forHSDPA, exists in the Node B. The Node B, however, may reject bearers due to a lackof resources.

The setup of that DL DPCH which is associated to the HS-DSCH is treated by theNode B’s admission control algorithm for dedicated channels. In UMR5.0, this admis-sion control algorithm, however, is extended in such a way that its operation is based onthe non-HSDPA power instead of the transmitted carrier power if the affected UTRANcell is capable of serving HSDPA.

4.1.3.6 Congestion Control AlgorithmCongestion control defines the absolute limits for DCH radio bearers in situations whenthe network runs out of resources in either the UL or the DL direction. Introducing theHSDPA feature does not impact on the congestion control algorithm on the UL.

In the DL direction, in contrast, resources on the HS-DSCH are allocated for HSDPA-capable UEs as long as both the predefined thresholds for HSDPA services are not ex-ceeded and these resources are available in the system. The congestion decision doestherefore not directly depend on the usage of the HS-DSCH. For this reason, the non-HSDPA transmitted carrier power is used to decide about whether or not a congestion

SAY KIAT

Highlight

107

occurred. The algorithm applied is the same as introduced in the UMR3.5 EnhancedCongestion 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 carrierpower.

• With regard to non-HSDPA UEs, stage 1 and stage 2 activities for congestion reso-lution will remain the same. HSDPA-capable UEs, however, are not treated instage 1.

• The congestion control algorithm takes account of UEs from both the primary andthe secondary scrambling code tree. The algorithm furthermore prioritizes bearersof 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 isaccording to 3GPP TS 25.133, with one exception: on the DL, the decision about wheth-er or not congestion occurred depends on the current non-HSDPA transmitted carrierpower.

The same exception applies for error handling. If the event-triggered common measure-ment initiation request for the non-HSDPA transmitted carrier power fails, congestioncontrol 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 cellswhich provide HSDPA service. Since only resources left from DCH bearers are providedfor HSDPA UEs to transmit on the HS-DSCH, no actions are performed on HSDPA UEsduring stage 1. UEs which transmit on the HS-DSCH must therefore be excluded fromstage 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 UTRANcell. The UEs which use the HS-DSCH are ranked according to the SF of their associ-ated DPCH. Those UEs which are to be reconfigured or dropped are then selected intwo stages.

The following rules apply for these two stages:• The congestion control algorithm handles UEs with the lowest downlink (DL) spread-

ing factor (SF) first, considering both the primary and the secondary scramblingcode tree.

• If bearers have identical DL SFs and, furthermore, if these DL SFs are comprisedfrom the primary and the secondary scrambling code tree, bearers from the second-ary scrambling code tree are treated first. In other words, the algorithm prioritizesbearers from the secondary scrambling code tree over those from the primaryscrambling code tree with the same DL SF.

For details about the different congestion stages (stage 1 and stage 2), please refer tothe OMN:RNC Cell Configuration - Basics.

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

SAY KIAT

Highlight

108

4.1.3.7 Integration of the Admission Control Algorithm for HSDPAHSDPA 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 cellis capable of providing HSDPA service.

4.1.4 HSDPA Code and Power Allocation and RedimensioningThis section deals with the HSDPA code and power allocation and redimensioning. Thistopic contains the following issues:• HSDPA RRC connection state management and handling• Code allocation and setup of the HSDPA physical channels

– Highspeed physical downlink shared channel (HS-PDSCH)– Highspeed shared control channel (HS-SCCH)

• Setup of the “Non-HSDPA Transmit Power” measurement• Deletion of HSDPA resources

The first three issues in this list are related to logical OAM which is the signaling asso-ciated with the control of logical resources, such as channels and cells. The logical OAMis performed in the RNC although physically implemented in the Node B.

4.1.4.1 State ManagementA UTRAN cell is capable of providing HSDPA service as soon as the new “High SpeedDownlink Packet Access Channel” object (MOC HSDPA) is configured. The resourcestatus indication (RSI) and the audit response HSDPA capability information indicate thecapabilities 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 HSDPAresources. This scenario is in line with the implementation principle in product releasesprior to UMR5.0, such as power capability values. In the event of a configuration mis-match, i.e. if the Node B is not capable of HSDPA although the configuration data re-quires HSDPA, NBAP (Node B application part) failure handling is applied. The NBAP:PHYSICAL SHARED CHANNEL RECONFIGURATION FAILURE message is thusused.

Upon the setup of the HSDPA resources, the RSI is used to monitor the HSDPA re-sources. The current status is indicated by means of the HS-DSCH resource informa-tion. Fig. 4.36 provides an overview of the RSI handling.

In general, each status indication of an RSI contains the operational state (OST) and theavailability status (AVS) of the MOC HSDPA, i.e. the HSDPA channel.

109

Fig. 4.36 Handling of resource status indications

Upon reception of an RSI indicating “HS-DSCH resource information: operationalstate = disabled“, the controlling RNC (CRNC) takes the following measures:• Setting the state attribute of the MOC HSDPA to disabled• Informing the operation and maintenance center (OMC) about the deactivated sta-

tus of the MOC HSDPA including the MOC’s availability status• Triggering the release of all radio links that are both established on the degraded cell

and mapped to the disabled HS-DSCH. To release the links, radio link deletion pro-cedures are executed. When these procedures are executed, the following casesare 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 cellupdate information with the cause set to “Radio Link Failure Or RLC Unrecovera-ble Error“, new radio resources are set up on a forward access channel (FACH).

HSDPA operational state = enabled

Node B CRNC

Resource status indication (RSI)

“HS-DSCH resource informationoperational state: disabled ”Cell operational state: degraded

NBAP: Radio Link Deletion

Resource status indication

“HS-DSCH resource informationoperational state: enabled ”Cell operational state: enabled

HSDPA operational state = disabled


HSDPA-related failure inthe Node B

Resolution of the HSDPAfailure in the Node B

HSDPA channels configured,non-HSDPA power andmeasurement set up

Non-HSDPA measurementswill be continued (Node B willuse its transmitted carrierpower measurements andmap these onto the non-HSDPA power measurementreport)

For all affected HSDPAchannels associated with thedegraded cell

110

– Otherwise, if further radio links are still active for the specific UE, the RNC issueschannel-type switching (CTS) from the HS-DSCH to a DCH.

Upon reception of an RSI indicating “HS-DSCH resource information: operationalstate = enabled “, the controlling RNC (CRNC) takes the following measures:• Setting the state attribute of the MOC HSDPA to enabled• Informing the OMC about the reactivated status of the MOC HSDPA including the

MOC’s availability status

Tab. 4.8 provides an overview of the states supported by the HSDPA channel HS-DSCH) and the corresponding trigger events.

Furthermore, a dependency exists between the state of the HSDPA channel and the as-sociated UTRAN cell. The state relations between these two objects are shown inTab. 4.9.

HS-DSCH state/status Trigger event(s) for the relevant state combination

OST AVS

disabled offline This is the initial state combination. Furthermore, thisstate combination is set in the event of one of the fol-lowing:- Creation of HS-DSCH object- Deactivation of related UTRAN cell object

disabled not installed The local UTRAN cell is not available.

enabled empty set This state combination is set in the event of one of thefollowing:- Completion of Physical Shared Channel Reconfigura-

tion Request (PSCRR) procedure for HS-DSCH es-tablishment

- Reception of RSI with cause “HSDPA available“- Reception of audit message with cause “HSDPA

available“

disabled dependency The AVS of the related cell is failed.

disabled failed This state combination is set in the event of one of thefollowing:- Occurrence of a failure in the PSCRR procedure for

HS-DSCH establishment- Reception of RSI with cause “HSDPA unavailable“- Reception of audit message with cause “HSDPA un-

available“- Completion of the PSCRR (code = 0) procedure for

HS-DSCH deletion triggered by non-HSDPA powermeasurement failure

Tab. 4.8 Possible states of the HS-DSCH (HSDPA channel)

111

4.1.4.2 Common MeasurementsThe HSDPA feature requires the introduction of new common measurements whose in-tention is to measure the transmitted carrier power of all codes not used for the trans-mission of HS-PDSCHs and HS-SCCHs. These measurements are called the “Non-HSDPA Transmit Power” measurement. The “Non-HSDPA Transmit Power” measure-ment includes both periodic and event-triggered measurements which are initiated inde-pendently. The periodic and event-triggered measurements are used for admissioncontrol 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

OST/AVS Trigger event(s) for the respective statecombination(s)

Cell state/status HS-DSCHstate/status

enabled/empty set

enabled/empty set

Both the UTRAN cell and the HS-DSCH areavailable.

disabled/failed

disabled/dependency

The HS-DSCH depends on the UTRANcell’s availability. The UTRAN cell, in turn, isfaulty.Note that under normal circumstances, thisstate combination will not occur.

enabled/degraded

disabled/failed

The UTRAN cell is available, whereas a faultoccurred on the HS-DSCH. The HS-DSCH’sfailure impacts on the cell’s state.

enabled/degraded

enabled/empty set

The cause which led to the cell’s degrada-tion does not impact on the HS-DSCH’sstate.

disabled/offline

disabled/offline

The cell is not available or removed and theHS-DSCH’s state depends on the cell’sstate! Possible trigger events are:- Local cell not activated- Local deactivated after previous activation

disabled/not installed

disabled/not installed

The HS-DSCH’s state depends on the cell’sstate! 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 thefollowing situation:The RNC optional feature handling indicatedthe support of HSDPA (swp = “true”) andcreating the HSDPA objects was accepted.At cell activation, however, the HSDPA sup-port has been withdrawn (swp = “false”).

Tab. 4.9 Dependencies between cell states and HS-DSCH states

112

Transmit Power” measurement, however, applies the same characteristics as the previ-ous “Transmitted Carrier Power” measurement.

4.1.4.3 Code and Power AllocationIn general, no generic assignment of a guaranteed minimum power for HSDPA via theIub interface exists. As applied for streaming services, however, a guaranteed bit ratecan be assigned to HSDPA services. The required power is thus reported to the RNCvia the “HS-DSCH Required Power Value” IE. This information element indicates theminimum necessary power for a specific priority class to meet the guaranteed bit ratefor all the established HS-DSCH connections, belonging to this priority class. This im-plementation complies with 3GPP TS 25.433, NBAP Specification, section 9.2.1.31Iba.

The HSDPA resources of a UTRAN cell are represented by a sequence of channeliza-tion codes. The channelization codes’ spreading factors (SFs) for HS-PDSCHs and HS-SCCHs are 16 and 128, respectively. All HS-PDSCH and HS-SCCH channelizationcodes which one single UE can receive are subordinated to one single primary scram-bling code. However, no restrictions exist regarding associated DCHs. In other words,the corresponding signaling radio bearer (SRB) can be assigned to any secondaryscrambling code of the cell, whereas the HSDPA channels must be assigned to theUTRAN cell’s primary scrambling code.

A UTRAN cell’s HSDPA resources are operator-configurable. In UMR5.0, one code treeis used and the maximum number of four HS-SCCHs can be configured.

As a restriction, however, the maximum configuration, i.e. 15 HS-PDSCHs and 4 HS-SCCHs, is not possible if the paging channel (PCH) is mapped onto a dedicated sec-ondary common control physical channel (S-CCPCH) in conjunction with the current al-location of the common channels. Mapping of the PCH onto an S-CCPCH is optional. Ifthe 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 usersand all other UEs in the UTRAN cell are assigned to a secondary scrambling code if thiscode is configured.

Fig. 4.37 provides an overview of the mapping of transport channels to their corre-sponding physical channels.

113

Fig. 4.37 Mapping of transport channels to physical channels

The setup for common channels is not changed with UMR5.0. In other words, none ofthem is moved to a secondary scrambling code. Therefore, after the setup of the UTRANcell, the following channelization codes are used below one spreading factor of 16:• 1 channelization code of SF = 64• 1 channelization code of SF = 128 (optional)• 4 channelization codes of SF = 256

Fig. 4.38 outlines this information.

Transport Channels Physical Channels

Paging Channel (PCH)

Dedicated Physical Data Channel (DPDCH)

Dedicated Physical Control Channel (DPCCH)

Physical Random Access Channel (PRACH)

Secondary Common Control

Acquisition Indicator Channel (AICH)Paging Indicator Channel (PICH)

Physical Channel (S-CCPCH)

Dedicated Channel (DCH)

Random Access Channel (RACH)

Forward Access Channel (FACH)

Common Packet Channel (CPCH) Common Pilot Channel (CPICH)

Synchronization Channel (SCH)

Broadcast Channel (BCH) Primary Common ControlPhysical Channel (P-CCPCH)

Standalone SRB for PCCH (on S-CCPCH)

Downlink Shared Channel (DSCH)

Highspeed Downlink SharedChannel (HS-DSCH)

Highspeed Physical DownlinkShared Channel (HS-PDSCH)

HS-DSCH-related Shared ControlChannel (HS-SCCH)

Dedicated Physical Control Channel (UL)for HS-DSCH (HS-DPCCH)

optional

114

Fig. 4.38 Basic code allocation strategy (code tree)

When initially allocating the starting number of HS-PDSCH codes and the codes whichare used for the HS-SCCH, the code with the smallest number is used in both cases.This handling is in line with the radio resource management of previous releases.

After the setup of the UTRAN cell, the CRNC reserves all specified codes for the HS-PDSCH and the HS-SCCH, using the code tree (see Fig. 4.38). Furthermore, theCRNC marks the descendant and ascendant codes of the specified codes as unavaila-ble. To make sure that none of the code tree’s codes is assigned to any user, reservingand marking is done simultaneously with the assignment of the common channel chan-nelization codes in the code tree.

Fig. 4.39 and Fig. 4.40 show the UMR5.0 cell setup sequence. In UMR5.0, the cell set-up procedure has been modified in comparison to the product release prior to UMR5.0.

256256256256

128

256256256256256256 256256256256256256

128128

64

128128

64

32

Available Code (SF = X) Unavailable Code (SF = X)Used Code (SF = X)

+ 15 * HS-PDSCH 16 16....16

6464

32

128128 128

16

X X X

i NOTEBefore starting the initial code allocation for the HS-PDSCH, the RNC confirms that theHSDPA feature is enabled by verifying that the SWP “HSDPA” flag has been set to“true” (swp = true). This check is only performed during the setup of the cell. If the cellhas already been active when the SWP “HSDPA” flag’s value is set to “true”, the changewill only take effect at the next cell setup procedure.If the flag’s value is set to “false”, no HSDPA capability is provided. Therefore, the samecell setup procedure as in previous product releases will be applied.

0

115

Fig. 4.39 Setup of the HS-DSCH (part 1)

Node B RNC

Cell setup


Physical shared channelreconfiguration request

Physical shared channelreconfiguration response

alt

par

Common transport channel setup

Common measurements setup for RTWP

Common measurementinitiation request (cell, non-HSDPA power, periodic)

alt Common measurementinitiation response (cell, non-HSDPA power, periodic)

Common measurementinitiation request (cell, non-HSDPA power, event-triggered)

par Common measurementinitiation failure (non-HSDPApower, periodic, cause IE)

opt Resource status indication (RSI)

“HS-DSCH resource informationoperational state: disabled ”

Physical shared channelreconfiguration request(number of both PDSCHand SCCH codes = 0)

alt Physical shared channelreconfiguration response


Common measurements setup for transmitted carrier power

1

2

2

3

3

4

4

5

5

4

4

4

- NBAP cell setup- SysInfoUpdate SIB1,

2, 3, 11

If the TPSCR expireswithout any positive ornegative response, thePSCR request will berepeated a predefinednumber (N) of times. Ifthe N retries expire, theNBAP cell deletion willbe started.

As in UMR4.0, includingSIB5 and SIB7

A failure in the setup ofan event-triggeredmeasurement does nothave any impact on thefurther procedure.Congestion control willthen rely on periodicmeasurements

The RSI can bereceived or not

If the TPSCR expireswithout any positive ornegative response, thePSCR request will berepeated for N times. Ifthe N retries expire, theNBAP cell deletion willbe started.

Periodic and event-triggered as in UMR4.0

116

Fig. 4.40 Setup of the HS-DSCH (part 2)

In contrast to the previous product release, all common channels and measurementsare no longer independent of each other. With UMR5.0, the “Non-HSDPA Power” meas-urement can only be set up upon completion of the “Physical Shared Channel Recon-figuration” (PSCR) procedure, i.e. when the HS-DSCH is set up. This is due to the factthat both measurements must be configured on the same channel coding card (CHC) inthe Node B. This CHC must be the specific card on which the HS-DSCH has been setup and is maintained.

Node B RNC

Common measurements setup for transmitted carrier power

Physical shared channelreconfiguration failure(cause IE)


NBAP cell deletion

Physical shared channelreconfiguration failure(cause IE)


par

Common transport channel setup

Common measurements setup for received total wideband power

Common measurements setup for transmitted-carrier power

NBAP cell deletion

4

4

3

2

1

2

2

2

2

1

2



117

After successful setup of the UTRAN cell, the HSDPA resources are set up by sendingthe NBAP: PHYSICAL SHARED CHANNEL RECONFIGURATION message to theNode B. This message provides the “HS-PDSCH-FDD-Code-Information” and “HS-SCCH-FDD-Code-Information” optional parameters for the HS-PDSCH and HS-SCCH,respectively. Furthermore, the TPSCR timer is started.

Upon reception of the NBAP: PHYSICAL SHARED CHANNEL RECONFIGURATIONmessage, the Node B parses this message, thus verifying the availability of all neces-sary resources. If establishing the Node B’s HSDPA resources fails, however, theNode B sends an NBAP: PHYSICAL SHARED CHANNEL RECONFIGURATION FAIL-URE message with a cause corresponding to the failure type which occurred. Tab. 4.10provides information about the mapping of failure types and cause values.

If the RNC receives neither an NBAP: PHYSICAL SHARED CHANNEL RECONFIGU-RATION FAILURE message nor an NBAP: PHYSICAL SHARED CHANNEL RECON-FIGURATION RESPONSE message before the expiry of the TPSCR, the RNC repeatsthe request a predefined number (N) of times. As a consequence, the Node B is capableof receiving and processing subsequent NBAP: PHYSICAL SHARED CHANNELRECONFIGURATION messages of the same configuration. If these N repetitions ex-pire, the cell deletion procedure is triggered.

Upon reception of an NBAP: PHYSICAL SHARED CHANNEL RECONFIGURATIONFAILURE message, the RNC takes the following measures:• Setting the state attribute of the MOC HSDPA to disabled• Informing the OMC about the failed setup, including the failure’s cause value. The

NBAP failure will trigger the corresponding alarm as a consequence.• Releasing the configured HSDPA codes in the code tree and making them available

to DCH users.• Setting up the “Transmitted Carrier Power” common measurements in the way they

were performed in the product release prior to UMR5.0.

Upon reception of an NBAP: PHYSICAL SHARED CHANNEL RECONFIGURATIONRESPONSE 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

i NOTEAn NBAP: PHYSICAL SHARED CHANNEL RECONFIGURATION FAILURE messageimpacts neither on the operational state of the UTRAN cell nor on already instantiatedcommon transport channels.

Failure type Cause value

The Node B does not support HSDPA.No HSDPA license is available at all.

CauseRadioNetwork:“Requested Configuration Not Supported”

The total available number of HSDPAlicenses is not sufficient.

CauseRadioNetwork:“Number Of Downlink Codes Not Supported“

The total amount of internal Node Bresources is not sufficient.

CauseRadioNetwork:“Node B Resources Unavailable”

Tab. 4.10 Mapping of failure types and cause values

118

• Initiating the “Non-HSDPA Transmit Power” measurement (see "Common Measure-ments" on page 111)

If the setup of the periodic “Non-HSDPA Transmit Power” measurement succeeds, theHS-DSCH setup procedure ends. Additionally, a failed setup of the event-triggered“Non-HSDPA Transmit Power” measurement does not impact on the HSDPA setup inthe relevant UTRAN cell.

Otherwise, if the periodic “Non-HSDPA Transmit Power” measurement fails, the RNCtakes the following measures:• Informing the OMC about the failed periodic “Non-HSDPA Transmit Power” meas-

urement. This triggers the corresponding alarm indicating the unsuccessful periodic“Non-HSDPA Transmit Power” measurement.

• Deleting the configured HSDPA codes by means of the NBAP: PHYSICAL SHAREDCHANNEL RECONFIGURATION message. In this case, the number of codes as-signed to PDSCHs or SCCHs is set to zero. Nevertheless, the operational state ofthe UTRAN cell is not impacted for DCH users and the cell still operates in non-HSD-PA mode. Therefore, a deactivation and a subsequent activation procedure must beapplied 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 UTRANcell.

• Setting the HSDPA MOC’s operational state to disabled and its availability status tofailed. Furthermore, the RNC informs the OMC about the change of states bymeans of an alarm and a notification.

• Releasing the configured HSDPA codes in the RNC’s code tree. These codes aremade available to DCH users.

• Setting up the “Transmitted Carrier Power” measurement which has been used inproduct releases prior to UMR5.0.

4.1.4.4 Modification and Deletion of HSDPA ResourcesBoth 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 ofthe relevant UTRAN cell is set to disabled. The cell must therefore first be deactivatedbefore modifying or deleting it. In addition to removing the cell plus the correspondingcommon 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 ALCAPrelease to the RNC.

As soon as the cell is in the operational state disabled, the operator can modify theHSDPA-related parameters or delete the MOC HSDPA to prevent HSDPA initializationat the next cell activation. For details, refer to "Operating the Feature" on page 123.

When removing the UTRAN cell from the active set, thus deleting all existing common,dedicated, and physical shared channels, an NBAP: PHYSICAL SHARED CHANNELRECONFIGURATION message requesting the deletion of HSDPA resources is obso-lete and therefore not sent. Furthermore, hanging HSDPA resources cannot exist whenthe UTRAN cell is removed for the same reason that this message is not sent.

i NOTEIn an HSDPA-capable cell, the HSDPA feature may be disabled and then reenabledagain. When disabling HSDPA, all HSDPA-related radio bearers must be released inadvance!

119

4.2 Functional SplitThis chapter describes the functional split of mobility topics with respect to HSDPA. Thefollowing items are covered:• HSDPA RAB Handling• HSDPA Mobility Handling• HSDPA Admission Control and Congestion Control• HSDPA Code and Power Allocation and Redimensioning

4.2.1 HSDPA RAB HandlingNot applicable.

4.2.2 HSDPA Mobility HandlingNot applicable.

4.2.3 HSDPA Admission Control and Congestion ControlAdmission and congestion control handling is implemented in the CRNC. Additionally,admission and congestion control may impact on the SRNC with regard to the interfacesbetween the SRNC and the CRNC.

In the Node B, the admission control algorithm is implemented in the core controller. Thealgorithm is therefore modified such that the core controller uses the non-HSDPA powerinstead of the transmitted carrier power.

The new HSDPA-related parameters impact on the LMT-RNC.

4.2.4 HSDPA Code and Power Allocation and RedimensioningNot applicable.

120

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

4.3.1 HSDPA RAB HandlingAn additional parameter has been added to the “Radio Bearer Control” object for con-trolling channel-type switching from HS-DSCH to FACH, see Tab. 4.11.

A new parameter, see Tab. 4.12, has been added to the “High Speed Downlink PacketAccess Channel” object (MOC HSDPA) introduced in "HSDPA Code and Power Alloca-tion and Redimensioning" on page 108.

Tab. 4.13 shows the parameters related to HSDPA measurement information. Multipleinstances are supported per RNC [0 .. 12].

Name LMT-Name Range DefaultValue

Description/Remarks

Timer for the switchfrom HS-DSCH toFACH

thsdsch_fach 0 .. 65535 s 30 s Period of uplink and downlink inactivity beforethe PS I/B RAB is switched from HS-DSCH toFACH0 means that inactivity is not monitoredand the connection is not switched to FACH

Tab. 4.11 New parameter for the “Radio Bearer Control” object


Description/Remarks

HS-DSCH PowerOffset

po_dsch -6 ..13 dBstep 0.5

3 dB Default Power offset between HS-PDSCH andP-CPICH/S-CPICH.Note: This parameter must be set to the samevalue for all cells within the same Node B.

Tab. 4.12 New parameter for the “High Speed Downlink Packet Access Channel” object


Description/Remarks

UE HS-DSCH Phys-ical Layer Category

ue_cate 1 ..64 - UE category for HSDPA, part of UE capabili-ties.

CQI FeedbackCycle k

cqi_cyclek 0, 2, 4, 8, 10,20, 40, 80,160 ms

4 ms Period of repetition of a CQI measurement re-port

CQI Repetition Fac-tor

cqi_rep 1 .. 4 1 Number of repetitions of a CQI report. Not nec-essary if CQI Feedback Cycle k = 0.

Tab. 4.13 Parameters for the “HSDPA measurement information” object

121

4.3.2 HSDPA Mobility HandlingThe 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 thatthe order of the reported cells is changed even if the difference in quality of each cell isextremely small, for example 0.1 dB.The “Cell change/CTS threshold” parameter isused to avoid frequent change of the serving HS-DSCH cell or channel-type switchingbetween HS-DSCH and DCH triggered by event 1A, 1B, 1C or, if configured, 1A’.

The “Hysteresis” IE is used to avoid frequent measurement reports of event 1D. There-fore, frequent change of the serving HS-DSCH cell or channel-type switching betweenHS-DSCH and DCH can be avoided as well.

ACK-NACK Repeti-tion Factor

ack_nack_rep 1 .. 4 1 Number of repetitions of ACK/NACK reports

CQI Power Offset cqi_po 0 .. 8 5 Power offset used in the UL between the HS-DPCCH slots carrying CQI information and theassociated DPCCH

ACK Power Offset ack_po 0 .. 8 5 Power offset used in the UL between the HS-DPCCH slot carrying HARQ ACK informationand the associated DPCCH

NACK Power Offset nack_po 0 .. 8 5 Power offset used in the UL between the HS-DPCCH slot carrying HARQ NACK informationand the associated DPCCH

HS-SCCH PowerOffset

hsscch_po -32 .. +31.75dB

0 dB Power offset of HS-SCCH relative to the pilotbits on the DL DPCCH


Description/Remarks

Tab. 4.13 Parameters for the “HSDPA measurement information” object


Description/Remarks

Hysteresis hyst1d 0 .. 7.5 dBby step of 0.5

2 dB Determines the hysteresis value

Time to trigger tmtrg1d 0, 10, 20, 40,60, 80, 100,120, 160,200, 240,320, 640,1280, 2560,5000 ms

640 ms Indicates the period of time between the timingof event detection and the timing of sending themeasurement report.

Tab. 4.14 Parameter for event 1D

122

4.3.3 HSDPA Admission Control and Congestion ControlHSDPA admission control and congestion control requires modifications of the followingMMI-related issues:• Parameters configurable at the LMT-RNC• Performance measurement counters

Parameters configurable at the LMT-RNC

The LMT-RNC parameter which is listed in Tab. 4.15 has been modified with respect toHSDPA admission control.

In addition, Tab. 4.16 lists the two new cell-specific parameters which are configurableby the operator at the OMC-R to handle HSDPA admission control.

Name LMT-Name Range Defaultvalue

Description

Reporting period fortransmitted carrierpower

mmti_tcp 0.01, 0.02 ..60, 120, 180.. 3600 s

10 Reporting period for admission controlThis parameter indicates the interval in whichperiodic reports of either the non-HSDPAtransmitted carrier power (if the cell is HSDPA-capable) or the transmitted carrier power (if thecell does not provide HSDPA service) is is-sued.

Tab. 4.15 Admission control parameter at the LMT-RNC modified due to HSDPA


Description

Minimum SF availa-ble for PS interac-tive/background onDCH in HSDPA cell

minsf_hsdpa 8, 16, 32 8 The minimum SF available in a specific HSD-PA cell for the PS interactive/background RABif at least the predefined number (X) of UEstransmit on the HSDPA channel.

NOTE:A similar parameter (“Minimum SF available“)already exists. This parameter is still used be-cause admission control determines the maxi-mum of both parameters if the HSDPAcondition applies. Please refer to "RestrictionControl in the CRNC for HSDPA" on page 104.

Threshold for acti-vating rate restric-tion for PSinteractive/back-ground on DCH inHSDPA cell

actrc_hsdpa 0 .. 256 UEs 0 If the current number of UEs on the HSDPAchannel exceeds this value in the relevantHSDPA cell, the CRNC will apply rate restric-tion for the PS interactive/background RAB onthe DPCH in this cell.If this parameter’s value is set to “0”, one HSD-PA-capable UE on the HSDPA channel suffic-es to start the rate restriction.

Tab. 4.16 New HSDPA admission control parameters at the LMT-RNC

123

Performance measurement counters

New counters are introduced with this release to measure the following performance in-dicators. All counters are available per UTRAN cell:• Number of HSDPA establishment attempts per cell• Number of HSDPA establishment rejections per cell• Number of successful HSDPA establishment outcomes per cell

A detailed description of new performance measurement counters is available in "HSD-PA Performance Measurement Counters" on page 155.

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



Description

Number of HS-PD-SCH codes

no_pdsch 1 .. 15 - Available number of channelization codes forthe HS-PDSCH

NrOfHSSCCHs no_scch 1 .. 4 - Available number of HS-SCCHs

Tab. 4.17 MOC HSDPA attributes for code and power allocation and redimensioning

124

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

5.1 Functional DescriptionWith regard to UTRAN operation and maintenance, the functional descriptions are sub-sequently provided for• "RNC" on page 124 and• "Node B" on page 130

5.1.1 RNCWith respect to the HSDPA-capable RNC, this section describes the OAM modificationsin terms of:• Equipment Management• Transport Network Layer Management• Radio Network Layer Management• Optional Feature Handling Within the RNC

5.1.1.1 Equipment ManagementTo support HSDPA, the RNC requires new/modified hardware (HW) to be installed.However, only model units with either eRNC configuration or mixed cRNC/eRNC con-figuration are allowed for an upgrade to HSDPA. As a precondition for this upgrade,model units affected must be equipped with CMP (composite/decomposite) or WCMP(wideband CMP) cards. In general, all model units intended for HSDPA capability needa 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 unitsequipped 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 typeif eRNC model units are used.

• Highspeed Packet Radio Link Controller (HSPRLC) cardThe mounting position of the HSPRLC is the A/B/C-PRM where B-PRM and C-PRMare the rack types if eRNC model units are used.

The two new HW cards operate in single redundancy mode. Both HSDST and HSPRLCare capable of plug&play operation. With regard to remote inventory management, bothnew cards represent ob-RIU objects. Their inventory data is added to the existing inven-tory data file (IDF).

125

Impacts on the RNC back end

On the RNC back end (RNC-BE) side, new HMI commands are introduced to configurethe HSDST and HSPRLC cards or components related to the radio network layer. Fur-thermore, new HSDPA-specific parameters are added to existing commands.

Upon creation, modification, or deletion of an HSDPA-specific item at the LMT-RNC, theRNC-BE sends a configuration change notification to the RNC-FE and increases theconfiguration 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 RNCfront end has been adapted in such a way that all HSDPA-related commands and ob-jects are available and can be configured.

As regards operation of HSDPA, the same tasks can be performed at the RC as at theLMT-RNC.

State management

Tab. 5.1 provides the X.731-compliant states by which the new equipment is managed:

Fault management

With respect to the fault management of the new HSDST card, the following new HMIoutput 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 failurein an HSDST card. The alarm will be cleared as soon as the cause for the fault isremoved 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_recoveryThe cause for the fault which led to the 0053299 hsdps_fault alarm is removed andthe equipment is in ins state.

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

126

As regards the HSPRLC’s fault management, the existing alarms 0053268 cmuxbl_faultand 0053269 cmuxbl_fault_recovery are modified with respect to the new card. The0053268 cmuxbl_fault and 0053269 cmuxbl_fault_recovery alarms indicate the occur-rence of a failure in the equipment subordinated to the CMUX and the failure’s recovery,respectively.

In addition to these output messages, the following two existing HMI alarms are en-hanced with information about HSPRLCs and HSDSTs. These alarms are applicable forany trunk card in the RNC:• 1348012 trunk_card_congestion_occurred

If the percentage of congestion for one specific card of an equipment group exceedsthe preset threshold value, the RNC-BE will inform the RNC-FE about the conges-tion.

• 1348013 trunk_card_congestion_recoveredIf the specific card’s percentage of congestion falls below the threshold value, thisalarm will be output, indicating that the congestion is over and thus clearing the1348012 trunk_card_congestion_occurred alarm.

5.1.1.2 Transport Network Layer ManagementOn the Iub interface, the HSDPA traffic is shared with traffic on dedicated channels(DCHs) on the same virtual channel (VC). This VC is configured for AAL2 (ATM adap-tation layer 2) user traffic. Iub HSDPA traffic is possible both via E1/J1/T1 IMA groupsand via STM-1/OC-3 lines. No additional VC needs to be configured in the RNC; how-ever, bandwidth requirements and the required number of available CIDs (call identifiersinside AAL2 VCs) call for the creation of additional AAL2 VCs.

On the Iu interface, the HSDPA traffic is routed via the existing AAL5 (ATM adaptationlayer 5) packet-oriented traffic. Thus, like on the Iub interface, no additional VC needsto be configured.

For proper use of the new HW cards, i.e. HSDST and HSPRLC, the HMI Trunk Equip-ment Control command (atrk) is enhanced. In addition to existing parameters, both theHMI 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 itsstate, respectively. Furthermore, the response messages of the view atrk command areenhanced. Information is added both about the mapping between GMUX and HSPRLCequipment and for displaying the new HW cards’ used bandwidth. The necessary infor-mation about the HSDST and HSPRLC cards is added to the following HMI output mes-sages:• 1348004 card_block_complete• 1348005 card_unblock_complete• 1348006 trunk_card_to_be_blocked

5.1.1.3 Radio Network Layer ManagementFor 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

127

The first two items refer to cells. All new attributes are embedded in one new MOC rep-resenting the HSDPA channel (HS-DSCH) which is subordinated to the “UTRANCell”MOC. The instantiation of the new MOC is optional. This MOC exists only if the cell pro-vides HSDPA service.

Measurement control and radio bearer control are RNC-related attributes. The relevantdata is added to the existing MOCs affected and must be configured even if HSDPA isnot supported by the RNC.

Attributes related to HSDPA measurements with an RNC-wide scope are embedded ina 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 featureis supported.

If the operator wants to use HSDPA in a cell, the following steps have to be performedin the given order:

1. Creation of the cell2. Creation of the highspeed downlink shared channel (HS-DSCH) in a cell3. Modification of OAM parameters via RC/LMT4. Setup of the HS-DSCH in Node B

A detailed guideline description about HSDPA setup in a UTRAN cell is provided in thesection "Operating the Feature" on page 123.

State management

The state management of the HSDPA channel MOC which represents the HS-DSCH issimilar to that of common transport channels.

Upon creation of the MOC in the RNC, the initial combination of OST/AVS is set to dis-abled/offline. Otherwise, if the HS-DSCH is set up in the Node B by means of theNBAP: Physical Shared Channel Reconfiguration procedure, the MOC’s OST/AVScombination will be enabled/empty_set. After the HSDPA setup in the Node B, theNode B issues a resource status indication (RSI) message to the RNC.

Further details are described in the section "State Management" on page 108 in thechapter HSDPA Code and Power Allocation and Redimensioning.

All HS-DSCH-related state/status values are compliant to ITU-T X.731.

Fault management

Whenever the Node B rejects the NBAP: PHYSICAL SHARED CHANNEL RECONFIG-URATION REQUEST message during HS-DSCH creation or setup of the non-HSDPApower 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 1329100nbap_failure. Furthermore, an alarm of severity “major” is newly created, indicating thatthe HS-DSCH channel has failed in the Node B.

Tab. 5.2 lists the possible state transitions and the generated or cleared alarms at theRNC front end during normal operation.

128

Previous OST/AVS Current OST/AVS RNC-FE alarm Remark

MOC Alarm content

- disabled/offline Cell No alarm Upon creation of the cell/HS-DSCH, the OST/AVS valuesare set to the initial values.

disabled/offline disabled/not installed Cell 66537 - ranLocal-CellNotAvailable

Either the local cell is not an-nounced or the interface tothe Node B is interrupted.

disabled/not installed disabled/offline Cell Local cell available The cell alarm is cleared.

disabled/offline disabled/failed Cell 66536 - ranCell-NotOperational

Cell activation failed.

disabled/failed disabled/offline Cell No alarm Operator action; therefore, noalarm is output.

disabled/failed enabled/empty_set Cell Cell operable The existing alarm is cleared.

enabled/empty_set disabled/offline Cell No alarm Operator action; therefore, noalarm is output.

enabled/empty_set disabled/failed Cell 66536 - ranCell-NotOperational

A cell failure occurred.

enabled/empty_set enabled/degraded Cell No alarm This transition is only possi-ble if the HS-DSCH fails.Thus, an HS-DSCH alarm ex-ists.

- disabled/offline HS-DSCH No alarm Upon creation of the HS-DSCH, the OST/AVS valuesare set to the initial values.

disabled/offline disabled/not installed HS-DSCH No alarm The HS-DSCH’s state de-pends on the cell’s state/sta-tus. Therefore, a cell alarm issufficient.

disabled/not installed disabled/offline HS-DSCH No alarm The HS-DSCH’s state de-pends on the cell’s state/sta-tus. Therefore, a cell alarm issufficient.

disabled/offline disabled/failed HS-DSCH HS-DSCH inopera-ble

This alarm is output if the HS-DSCH setup in the Node Bfails.

disabled/failed disabled/offline HS-DSCH No alarm Operator action; therefore, noalarm is output.

disabled/failed enabled/empty_set HS-DSCH HS-DSCH opera-ble

The existing alarm is cleared.

enabled/empty_set disabled/offline HS-DSCH No alarm Operator action; therefore, noalarm is output.

Tab. 5.2 State transitions and generated alarms during normal operation (RNC-FE)

129

Tab. 5.3, on the other hand, provides the possible states and generated alarms afterstate alignment.

5.1.1.4 Optional Feature Handling Within the RNCWith respect to HSDPA, two prerequisites exist for operating the HSDPA feature in theRNC: the new HW cards and an additional HSDPA-related SW flag which enables ordisables the support of HSDPA from the SW’s point of view. This ’HSDPA’ flag, howev-er, can only be switched (from ’HSDPA disabled’ to ’HSDPA enabled’ and vice versa)by Siemens AG/NEC service staff.

enabled/empty_set disabled/failed HS-DSCH HS-DSCH inopera-ble

An HS-DSCH failure oc-curred.

enabled/empty_set disabled/dependency HS-DSCH No alarm This transition is only possi-ble if the cell fails. Thus a cellalarm already exists.

disabled/dependency disabled/offline HS-DSCH No alarm

disabled/dependency enabled/empty_set HS-DSCH No alarm The cell changes from disa-bled/failed to enabled/empty_set. Therefore, thecell alarm is cleared.

Previous OST/AVS Current OST/AVS RNC-FE alarm Remark

MOC Alarm content

Tab. 5.2 State transitions and generated alarms during normal operation (RNC-FE)

OST/AVS RNC-FE alarm Remark

MOC Alarm content

disabled/offline Cell No alarm

disabled/not installed Cell 66537 - ranLocalCellNotAvail-able

disabled/failed Cell 66536 - ranCellNotOperational The cell had reported inoperabilitybefore.

enabled/empty_set Cell No alarm This is the default state.

disabled/offline HS-DSCH No alarm

disabled/not installed HS-DSCH No alarm

disabled/failed HS-DSCH HS-DSCH inoperable The HS-DSCH had reported inop-erability before.

enabled/empty_set HS-DSCH No alarm This is the default state.

disabled/dependency HS-DSCH No alarm This state/status combination de-pends on a cell failure where a cellalarm exists.

Tab. 5.3 States and generated alarms after state alignment

130

The creation of any item related to HSDPA is rejected as long as the ’HSDPA’ flag isdisabled. 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 HSDPAfeature 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 providedfor the cell. If the flag indicates that HSDPA is not supported, the setup of HSDPA in theNode B will be skipped. When activating a cell in a Node B, it must be kept in mind thatHSDPA operation is only possible on one carrier frequency per Node B and that onlysymmetrical HSDPA configurations in all radio cells on the same carrier frequency areallowed in UMR5.0.

Furthermore, the download procedure will fail if HSDPA-related MOCs are included inthis procedure.

5.1.2 Node BWith respect to the HSDPA-capable Node B, this section describes the OAM modifica-tions in terms of:• Equipment Management• Transport Network Layer Management• Radio Network Layer Management• Optional Feature Handling Within the Node B

5.1.2.1 Equipment ManagementIf 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 thatHSDPA traffic can be processed by either the CHC96 or the hs-CHC exclusively as soonas both types are installed. As regards Node B’s remote inventory management, thenew hs-CHC represents an ob-RIU object.

The Node B’s initial trigger to set up HSDPA operation is the configuration of the ’local-CellE’ managed object instances (MOIs) in the database, thus either enabling or disa-bling HSDPA for a particular UTRAN cell. At system start-up, the Node B then evaluateseach instance’s current configuration and triggers the setup of an HSDPA-capable CHCin HSDPA mode according to the rules listed below. This implementation avoids time-consuming and complex reconfiguration of CHCs because the Node B already knowsat start-up time how many cells support HSDPA and no HSDPA-related or Rel 99 trafficmust be shifted to other CHCs.

1. The Node B always sets up an hs-CHC in HSDPA mode if such a type of card is in-stalled.

2. If neither a hs-CHC is installed nor any of the installed hs-CHCs is equipped with aHSDPA high-capacity license and if a HSDPA-capable CHC96 is installed, theNode B sets up the CHC96 in HSDPA mode.

3. Otherwise, if neither an hs-CHC nor an HSDPA-capable CHC96 is installed, theNode B will reject any HSDPA setup request by means of an NBAP: PHYSICAL

131

SHARED CHANNEL RECONFIGURATION FAILURE message containing the ap-propriate probable cause information.

Furthermore, the Node B checks whether the number of codes signaled in the NBAP:PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST message is equal tothe 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 bymeans of an NBAP: PHYSICAL SHARED CHANNEL RECONFIGURATION FAILUREmessage containing proper probable cause information. The distribution of HSDPA cellson available HSDPA-capable CHCs is performed in a kind of round-robin manner, thusresulting in HSDPA cells being evenly distributed on the appropriate CHCs. This func-tionality is currently implemented for Rel 99 cells, as well. An example is provided intable 3.2 on page 30.

Due to the new and changed HW for supporting HSDPA, the N2CH MOC representingall CHCs has been adapted as follows:• The existing attribute “chType” notifying the type of CHC being used has been ex-

tended by a new value which indicates the hs-CHC.• A new attribute has been added to this MOC indicating the cell IDs of those HSDPA

cells served by the HSDPA-capable CHC.

State management

The following applies for an HSDPA-capable CHC’s state management with regard toimplementation-specific and logical OAM:• Implementation-specific OAM

In general, the locking or shutting down of an HSDPA-capable CHC currently provid-ing HSDPA service is only possible if no cell(s) will go down or be affected. In otherwords, no common channel may reside on that CHC. As a consequence, a requestto lock or shut down a CHC operating in HSDPA mode is rejected as long as anysuperior 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 runningon the affected HSDPA-capable CHC will be shifted to other CHCs as far as possibleaccording to the current implementation. HSDPA calls, however, will be lost becauseno call context migration of HSDPA calls exists in UMR5.0.

• Logical OAMIn this context, the state management function treats the physical shared channelwhich is used by HSDPA traffic in the same way as a dedicated channel for Rel 99traffic. Although the physical shared channel is considered as a common resourcefrom 3GPP’s point of view, call context migration is not supported.

Fault management

If a failure occurs in an HSDPA-capable CHC, thus leading to a situation in which noHSDPA-traffic processing is possible, the Node B issues an NBAP: Resource Status In-

i NOTEThe number of HSDPA-capable CHCs in HSDPA mode the Node B sets up is equal tothe 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 Bdetermines the type of CHC to be used for HSDPA operation. The CHC type selectedfor HSDPA processing is then kept until the next restart of the Node B.

132

dication (RSI) to the controlling RNC (CRNC). This RSI indicates the loss of the HSDPAservice for that specific HSDPA cell.

This RSI results in the HS-DSCH’s combination of operational state/availability status(OST/AVS) being set to disabled/failed. The affected cell’s OST/AVS combination isset to enabled/degraded. As a consequence, all HSDPA radio links will be dropped andthe RNC sends an NBAP radio link failure indication for each radio link.

5.1.2.2 Transport Network Layer ManagementAs previously mentioned, at the Iub interface HSDPA traffic is shared with DCH trafficat the same VC used for AAL2 user traffic. Therefore, no changes are necessary withinthe Node B.

On the pysical layer, the Node B supports HSDPA traffic both via E1/J1/T1 lines withIMA and via STM-1/OC-3 lines.

5.1.2.3 Radio Network Layer ManagementThe Node B’s call processing functionality is extended for the support of HSDPA. Fur-thermore, the functionality of the local UTRAN cell (“localCellE” MOC) is adapted to therequirements of HSDPA. This allows an indication of whether HSDPA is supported ornot and of the applied modulation scheme. For details, see "Impacts on the LMT-Node B" on page 141.

5.1.2.4 Optional Feature Handling Within the Node BThe HSDPA feature is subject to the general SW licensing policy ofSiemens AG/NEC Corporation which is valid for the Node B. In other words, the princi-ple of “pay-as-you-grow” is applied.

The following two types of licenses are applied for the HSDPA feature in UMR5.0:• HSDPA data throughput license• HSDPA high-capacity license

HSDPA data throughput license

The HSDPA data throughput license specifies the peak data throughput of HSDPA traf-fic which may be processed by one Node B. One license corresponds to a peak datathroughput of 2.4 Mbit/s per Node B. The total number of licenses (N) defines the totalpeak data throughput peakDataThroughputNodeB as a multiple of 2.4 Mbit/s. In otherwords, peakDataThroughputNodeB = N * 2.4 Mbit/s, where N is in the range from 1 to 6.

During operation, the Node B confirms that this peak data throughput is not exceeded.Therefore, the Node B recalculates the possible peak data throughput depending on theHSDPA configuration at each NBAP: Physical Shared Channel Reconfiguration proce-dure. The calculation is performed according to the following algorithm:

peakDataThrough

putNodeB

numberOf

Codes i( )i 1=

A

∑modulation

Scheme i( )• 0.48• Mbit s⁄=

133

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 theNBAP: Physical Shared Channel Reconfiguration procedure

• modulationScheme(i)Specifies the modulation scheme (HSDPA configuration) applied in cell i. This fac-tor’s values indicate the following:– “0”: HSDPA processing in cell i is disabled– “1”: HSDPA processing in cell i is enabled, using only QPSK– “2“: HSDPA processing in cell i is enabled, using 16QAM and QPSK

If the calculated possible peak data throughput exceeds the licensed peak data through-put, i.e. if peakDataThroughputNodeB > peakDataThroughputNodeB, the Node B will re-ject the NBAP: Physical Shared Channel Reconfiguration procedure with the cause setto “Not Enough User Plane Processing Resources“.

The update of an HSDPA data throughput license of a CC at runtime becomes effectivewithout a system restart. In the event of CC redundancy, the higher license value be-comes effective after a license update of one of the CCs.

HSDPA high-capacity license

The HSDPA high-capacity license is only applicable to the new hs-CHC. The license de-fines the number of HSDPA users per UTRAN cell which one hs-CHC supports. Com-pared to a CHC96, which supports 24 HSDPA users at an uplink rate of 64 kbit/s, theHSDPA high-capacity license allows the maximum number of HSDPA users per cell andhs-CHC to be increased by 50%. In other words, the hs-CHC will then support36 HSDPA users in the same scenario.

Without activating the HSDPA high-capacity license, however, the hs-CHC supportsonly Rel 99 traffic, even if an HSDPA data throughput license is activated for the specifichs-CHC.

134

5.2 Functional SplitThe functional split for UTRAN OAM is not applicable. With regard to the RNC, theNode B, HSDPA mobility, the transport network layer, the Uu interface, and the HSDPAperformance measurement counters, the relevant functional splits are described in thecorresponding 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

5.3 Man-Machine Interface

Both the RC and the LMTs support the changes in the network elements’ (NEs) infor-mation models and databases, i.e. of the RNC and the Node B. Thus, the new MOCsincluding their attributes are displayed at the graphical user interfaces (GUIs); the newor 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’ informationmodels and databases for HSDPA compliancy.

5.3.1 Impacts on the RC GUIWith UMR5.0, the RC GUI displays the new MOCs Hsdps and Hprlc representing thenew RNC HW cards HSDST and HSPRLC, respectively.

The icons of the Hsdps MOC, on the one hand, are situated in the Atm Sum panel whichrepresents the LSM module. As already done for the MOCs Tifs, TifdSide, Wcmps, andWcmpdSide in previous releases, the icons for the Hsdps MOC are shown in the graph-ical area of the panel on the related slots within the background picture using dynamicicon labels. The label of these icons is HSDPS. The Hsdps MOC provides the same at-tributes, actions, and notifications as the Wcmps MOC already does. These attributes,actions, and notifications are handled by the RC in the same way as in previous releas-es.

The Hprlc MOC, on the other hand, is located in the PswcB Sum panel and in the PswcESum panel representing the PRM(B), B-PRM and C-PRM modules. In the backgroundpicture, the labels of all slots which can be used for the HSPRLC card are renamed intoPRLC/HSPRLC. The Hprlc MOC provides the same attributes, actions, and notificationsas the Wcmps MOC already does. These attributes, actions, and notifications are han-dled by the RC the way it has been done in previous releases.

Furthermore, the new MOCs (HSDPA channel and HSDPA radio resource managementcontaining the HSDPA measurement information) of the RNC RAN part are displayedon the RC GUI. The HSDPA-channel-related MOC subordinated to the UtranCell MOCis displayed via a new entry in the “Cell SubObject” list. Only one instance of theHSDPA-channel-related MOC can be created per HSDPA cell. The “Cell SubObject” list

i NOTEThe command lines, GUI windows, and MOC names provided below are only assump-tions, as their syntax is subject to change.

135

therefore contains exactly one additional entry if the cell supports HSDPA. In contrast,as regards the the HsRadioResMngmt MOC representing the HSDPA radio resourcemanagement and subordinated to the RANFunction MOC, up to three instances can becreated. These instances are all situated in the RAN Sum panel, each displayed as aseparate icon. In the default sort order of this panel, the HsRadioResMngmt MOC issorted before the Adj RNC icons.

In addition to these new MOCs, new attributes for existing MOCs are introduced withthis release. In the RNC, both the sbs3gRadioBearerCtrl MOC and thesbs3gIntraFreqHoCtrl MOC have been adapted. In the Node B, on the other hand, thetwo MOCs N2Ch (see "Ch" on page 141) and N2LocalCellE (see "LocalCellE" onpage 142) have been modified.

The new and modified HSDPA-related performance measurement counters for theNode B, which are described in the chapter "HSDPA Performance MeasurementCounters" on page 155, are furthermore supported by the RC.

5.3.2 Impacts on the LMT-RNCThis section provides information on new and modified CLI commands with respect tothe radio access network (RAN). These commands can be entered at the LMT-RNCcommand line interface (CLI). The LMT-RNC provides functionality to configure HSDPAdata to UTRAN cells and to set HSDPA call control data on the RNC site, thus operatingthe HSDPA feature in the whole system.

Furthermore, information about new and modified output messages is contained in thissection.

5.3.2.1 New CLI CommandsTab. 5.4 provides an overview of the new RNC-BE CLI commands and their corre-sponding operations.

HMIcommand

Operation Sub-item Description

hsdpa cre - Creates a new instance

del - Deletes an existing instance

mod - Modifies an existing instance

view - Displays the instance’s settings

view st Displays the state information ofan HSDPA channel instance

hsrrm cre - Creates a new instance


mod - Modifies an existing instance

view - Display’s the instance’s settings

hstci mod - Modifies an existing instance

view - Displays an instance’s settings

Tab. 5.4 New CLI commands

136

hsdpa

The new CLI hsdpa command has been introduced to set, modify, and control the pa-rameters of the HSDPA channel (HS-DSCH). The HSDPA channel must be configuredfor each cell in which the HSDPA feature is to be operated. Tab. 5.5 lists the parametersof the HSDPA channel which can be controlled by the CLI hsdpa command.

Of course, all parameters are new.

The related UTRAN cell must first be deactivated whenever the data of one channel isto be changed by means of the cre, del, or mod operation. The view operation does notonly show the settings/data of the specific HSDPA channel but its state.

If a downlink common channel (DLCC; dlcc CLI command or Downlink Common Chan-nel GUI window) with “ccho_type=0” or “ccho_type=1” exists, the combination of“no_pdsch=15“ and “no_scch=4” is not allowed for the hsdpa CLI command.

With regard to configuration alignment, the relevant configuration data is included in theconfiguration alignment file.

hsrrm

The new hsrrm CLI command controls the radio resource data for each UE category. InUMR5.0, UE categories 1 to 6, 11, and 12 are supported.

The HSDPA radio resources must be configured whenever HSDPA is to be started. Forthis reason, the hsrrm-related parameters as provided in Tab. 5.6 are introduced withUMR5.0. All parameters are new.

hsrc cre - Creates a new instance


view - Displays an instance’s settings

HMIcommand

Operation Sub-item Description

Tab. 5.4 New CLI commands

Parameter name Default value Parameter description

cellid not applicable Cell identifier

nodebid not applicable Node B identifier

no_pdsch not applicable Number of HS-PDSCH channelization codes

no_scch not applicable Number of HS-SCCH channelization codes

po_dsch 6 HS-DSCH power offset

Tab. 5.5 Parameters for the hsdpa command

i NOTEThe HSDPA channel is subordinated to the associated UTRAN cell. Therefore, if the cellis deleted, the HS-DSCH will automatically be deleted, too.

137

Upon creation of an instance’s data, the data which is managed by the hstci commandwill automatically be created at the same time as the relevant default value(s). The sameapplies for the deletion of an hsrrm instance’s data. In other words, when the hsrrm-re-lated data is deleted, the hstci-related data will also be deleted simultaneously. This isbecause the same key parameter is used for both the hsrrm and the hstci commands.


hstci

The new hstci CLI command controls the transport channel information for each UE cat-egory. As stated above, the instances of this item are automatically created upon crea-tion of an hsrrm item and the parameters are set to their default values. Usually thesevalues do not need to be changed. If a modification becomes necessary, however, themod operation can be issued. Tab. 5.7 lists the hstci-related parameters, which are allnew.


ue_cate not applicable UE HS-DSCH physical layer categoryCurrently, only UE category types 1 to 6, 11,and 12 are supported.

cqi_cyclek 4 Channel quality information (CQI) feedbackcycle k

cqi_rep 1 CQI repetition factor

ack_nack_rep 1 ACK-NACK repetition factor

cqi_po 5 CQI power offset

ack_po 3 ACK power offset

nack_po 3 NACK power offset

hsscch_po 3 HS-SCCH power offset

Tab. 5.6 Parameters for the hsrrm command


ue_cate not applicable UE HS-DSCH physical layer categoryCurrently, only UE category types 6, 11, and12 are supported.

macws 16 MAC-hs window size

t1 50 T1 timer

dlrate_peak ue_cate = 6:2,048,000 bit/sue_cate = 11:936,000 bit/sue_cate = 12:1,864,800 bit/s

Downlink peak CPS-SDU rate (Iub/Iur AAL2)

Tab. 5.7 Parameters for the hstci command

138

With regard to configuration alignment, the relevant configuration data is only includedin the “config_file_all” file if the all-alignment is performed by means of the view align dkall command.

hsrc

The new hsrc command controls the RAB combination control data. Tab. 5.8 lists thehsrc-related parameters, which are all new.

dlrate_avg ue_cate = 6:100,000 bit/sue_cate = 11:25,000 bit/sue_cate = 12:50,000 bit/s

Downlink average CPS-SDU rate (Iub/IurAAL2)

dlsize_peak 360 Downlink peak CPS-SDU size (Iub/Iur AAL2)

dlsize_avg 360 Downlink average CPS-SDU size (Iub/IurAAL2)

ulrate_peak 56 Uplink peak CPS-SDU rate (Iub/Iur AAL2)

ulrate_avg 0 Uplink average CPS-SDU rate (Iub/Iur AAL2)

ulsize_peak 56 Uplink peak CPS-SDU size (Iub/Iur AAL2)

ulsize_avg 56 Uplink average CPS-SDU size (Iub/Iur AAL2)

brate_peak ue_cate = 6:2,048,000 bit/sue_cate = 11:936,000 bit/sue_cate = 12:1,864,800 bit/s

Downlink peak bit rate (HSPRLC)

brate_avg ue_cate = 6:100,00 bit/sue_cate = 11:25,000 bit/sue_cate = 12:50,000 bit/s

Downlink average bit rate (HSPRLC)

brate_min 0 Downlink minimum bit rate (HSPRLC)


Tab. 5.7 Parameters for the hstci command


rab1 psib Radio access bearer #1

ul_rate1 64 kbit/s,384 kbit/s

Uplink rate for radio access bearer #1

Tab. 5.8 Parameters for the hsrc command

139

With regard to configuration alignment, the relevant configuration data is only includedin the “config_file_all” file if the all-alignment is performed by means of the view align dkall command.

5.3.2.2 Modified CLI CommandsIn addition to the new CLI commands, existing RNC-BE CLI commands have been mod-ified in order to adapt their functionality to the requirements of the new HSDPA featureas introduced in UMR5.0. The HSDPA feature impacts on the following RNC-BE com-mands:• ifmrms• rbc• dlcc• cell adc

ifmrms

With the introduction of HSDPA in UMR5.0, the data for the measurement report ofevent 1D is necessary. The ifmrms-related parameters have therefore been enhancedby the two parameters in Tab. 5.9.


rbc

The timer for channel-type switching (CTS) from HS-DSCH to FACH has been added tothe rbc-related parameters. For details, see Tab. 5.10.


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 allocatednumber of HS-PDSCH channelization codes and the allocated number of HS-SCCHchannelization 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.


hyst1d 2 Hysteresis for event 1D

tmtrg1d 640 Time to trigger for event 1D

Tab. 5.9 New parameters for the ifmrms command


thsdsch_fach 30 Timer for the switch from HS-DSCH to FACH

Tab. 5.10 New parameters for the rbc command

140

With regard to configuration alignment, this command is not influenced because no pa-rameter is changed. The relevant configuration data is therefore included in the config-uration alignment file.

cell adc

Due to the introduction of the HSDPA feature, the existing cell adc command has beenenhanced with parameters to supervise the UTRAN cell’s admission control for HSDPAcalls. Tab. 5.11 provides the relevant information.


5.3.2.3 New Output Messages at the LMT-RNCWith respect to HSDPA, new RNC-BE outputs are introduced in UMR5.0. The followingmessages are new with this release:• 0053299 hsdps_fault

The RNC-BE uses this alarm to notify the RNC-FE about the occurrence of a failurein an HSDST card. The alarm will be cleared as soon as the cause for the fault isremoved and the equipment is in ins state. This is achieved by the following:– The defective card is replaced.– The result of the command diagnosis is OK.– The equipment is reset by means of the corresponding command.– Plug&play is executed when the card is reinserted into the relevant module.– A lock and unlock operation is successfully performed.

• 0053300 hsdps_fault_recoveryThe cause for the fault which led to the 0053299 hsdps_fault alarm is removed andthe equipment is in ins state.

• 1329203 hsdpa_state_changedThis message indicates that the state of the HSDPA channel (HS-DSCH) haschanged.

5.3.2.4 Modified Output Messages at the LMT-RNCWith respect to the new HW equipment in the RNC and the HSDPA channel, existingHMI alarms have been extended by parameters representing the two new cards or theHSDPA channel. Tab. 5.12 lists the modified output messages in relation to the affectedMOCs:


minsf_hsdpa 8 Minimum available spreading factor for thePS Interactive/Background RAB on a DCH inan HSDPA cell

actrc_hsdp 0 Threshold to activate the rate restriction forthe PS Interactive/Background RAB on aDCH in an HSDPA cell

Tab. 5.11 New parameters for the cell adc command

141

5.3.3 Impacts on the LMT-Node BWith respect to HSDPA, modifications have been made to the following Node B-relatedMOCs in UMR5.0:• Ch

This MOC defines a channel coding card (CHC).• LocalCellE

This functional MOC is a container for all hardware-managed objects (HMOs) re-quired for a particular local cell.

Ch

Tab. 5.13 lists the new and modified attributes related to the “Ch“ MOC. The operatorhas read-only access to these attributes.

HMI output message Affected MOC

Hsdps Hprlc Hsdpa

0053268 cmuxbl_fault X

0053269 cmuxbl_fault_recovery X

1152001 state_of_device_changed X X

1293001 ast_changed_notifcation X X

1329100 nbap_failure X

1348004 card_block_complete X X

1348005 card_unblock_complete X X

1348006 card_reserved_to_be_blocked X X

1348012 trunk_card_congestion_occurred X X

1348013 trunk_card_congestion_recovered X X

Tab. 5.12 Modified output messages at the LMT-RNC

i NOTEThe following attribute names are mere proposals but not yet fixed!

Attribute name Value range Attribute description

assignedHsdpa-Cells

not applicable This new attribute indicates the IDs of thoseUTRAN cells which are served by an HSDPA-capable CHC.

Tab. 5.13 New and modified attributes related to the Ch object in the Node B

142

LocalCellE

Tab. 5.14 lists the new attributes related to the “LocalCellE“ MOC. These attributes canbe configured by the operator.

5.3.4 OAM Tool Set (OTS)The HSDPA feature requires modifactions to the CM+ module of the OTS. The CM+module comprises the south- and north-bound interfaces of the OTS and the OTS core.

5.3.4.1 Extensions for South-Bound Import Operations and OTS CoreDue to the changes in the information models of both the RNC and the Node B, the cor-responding model of the OTS core is updated. In accordance with this update, the da-tabase uploads (reverse engineering function) for both the RNC and the Node B mustbe updated accordingly, too. The only additional functionality required for the newly in-

chType [0;2]Granularity: 1

This attribute specifies the type of CHC whichis used. The attribute’s values indicate the fol-lowing:- “0”: CHC48- “1“: CHC96- “2”: hs-CHCThe attribute value for the hs-CHC has beenadded in UMR5.0.


Tab. 5.13 New and modified attributes related to the Ch object in the Node B


hsdpaSupport [0;1]Granularity: 1

This attribute enables HSDPA processing fora specific UTRAN cell. The attribute’s valuesindicate the following:- “0”: HSDPA processing disabled- “1”: HSDPA processing enabled

modulationScheme [0;1]Granularity: 1

This attribute specifies the modulationscheme to be applied in a specific cell. Thisparameter becomes relevant only if HSDPAsupport has been enabled for this cell. The at-tribute’s values indicate the following:- “0”: QPSK is exclusively applied- “1“: 16QAM and QPSK are applied

hsdpaScheduler-Type

[0;1]Granularity: 1

This parameter specifies which type of sched-uler is to be used in a given cell. The values in-dicate the following:- “0”: User-throughput-optimized scheduler

(Proportional Fair scheduler)- “1“: Cell-throughput-optimized scheduler

(Maximum CIR scheduler)

Tab. 5.14 New attributes related to the LocalCellE object in the Node B

143

troduced classes is the ability to create, delete, and modify these classes by means ofthe CM Editor.

As regards the Node B, the HSDPA-dependent changes in the information model havealready been implemented in the product release prior to UMR5.0.

5.3.4.2 Extensions for South-Bound Export OperationsThe bulk generation of the RNC’s and the Node B’s databases is extended in order tosupport the modifications within the relevant information models. Additionally, the deltagenerator 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 ormodifying 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” classas a child class of the “RANFunction“.

Furthermore the Node B’s bulk mode exclusively supports setting the HSDPA-supportflag and the modulation scheme of the “LocalCellE“ object. Managing the HSDPA-sup-port flag, however, complicates the activation of HSDPA for the customer with respectto OAM. The complication is caused by the following:• The operation requires a restart of all affected Node Bs.• The HSDPA feature must be enabled per cell on both the RNC and the Node B. The

configuration between these two network elements must therefore be kept consist-ent.

It is unavoidable to accept this complication because the Node B’s hardware must knowthe number of cells supporting HSDPA at startup. Threfore, the HSDPA-capable CHCcan perform a switch to HSDPA operation during its startup, thus avoiding the acitivationof HSDPA at a later point in time upon reception of the channel reconfiguration requestfrom the RNC. This online reconfiguration of the HSDPA-capable CHC is very time-con-suming. If a CHC96 is concerned, for example, Rel 99 calls must be allocated on othercards before the switchover to HSDPA mode.

5.3.4.3 Consistency ChecksThe OTS is extended by a consistency check confirming that the Node B’s CallProcMOC uses only those frequency layers for which HSDPA capability is activated. Whenusing HSDPA, a Node B with a 1/1/1 configuration, for example, is not allowed to usefrequency layer 2.

Another check confirms that the configuration of HSDPA in the RNC and the Node B isconsistent. This consistency check indicates HSDPA channels created in the RNC forUTRAN cells which do not support HSDPA (hsdpaSupport = 0). On the other hand, it ispermissible to have no HSDPA channels configured in UTRAN cells with HSDPA sup-port (hsdpaSupport = 1).

Third, it is confirmed that the number of channelization codes used per HSDPA channelis identical throughout the whole Node B. The principle of symmetric distribution ofchannelization codes on all cells is thus kept.

The introduction of the HSDPA feature requires the following extensions for north-boundinterfaces 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-boundinterfaces are equivalent to those for the south-bound export operations mentionedabove.

• 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

5.4 Operating the FeatureAs regards both the RNC and the HSDPA-capable Node Bs, HSDPA configuration viaboth LMT-Node B and RC is possible.

i NOTEAlthough the support of HSDPA and the applied modulation scheme have tobe configured in the Node B, this is not modeled at the MCCM interface.

145

6 Transport Network Layer (TNL) Modifications

6.1 Functional DescriptionHSDPA provides for higher data throughput per UE and per cell. In comparison to Re-lease 99, HSDPA• allows user throughput of more than 384 kbit/s• increases the maximum cell data throughput from 1 Mbit/s to a theoretical maximum

of 13.98 Mbit/s

Such increased data rates require either E1/J1/T1 IMA groups or STM-1/OC-3 lines forthe 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 conventionalRel 99 traffic. On the Iu interface, HSDPA data uses the same AAL5 user plane VCs asconventional user plane traffic. HSDPA is not supported over Iur.

HSDPA is used for interactive and background traffic classes. This traffic is expected toexhibit pronounced bursts that might use an Iub interface to full capacity. A flow controlmechanism (see below) in combination with QoS differentiation is introduced to allow formaximum Iub usage while at the same time providing that HSDPA traffic does not inter-fere with Rel 99 traffic. In the event of congestion, HSDPA traffic is discarded first.

HSDPA is carried on the same ATM AAL2 VCs as is conventional traffic. Therefore, onthe transport network layer there are no configuration changes for HSDPA in compari-son to conventional Release 99 networks. However, because of the increased band-width requirements and the limited number range of call identifiers (see below) inside anAAL2 VC, it is necessary to configure more AAL2 user plane VCs on the Iub interface.

AAL2 user plane VCs can be shared between several calls. To facilitate this, the VC car-ries several AAL2 links which each are associated with an individual call. AAL2 links areidentified by their CID (call identifier) that is transported as an additional header byte ofan ATM cell.

Each HSDPA user requires 3 CIDs to be allocated, which are used for UL DTCH (A-DCH), DCCH, and HS-DSCH. Thus, HSDPA support adds the requirement for 1 addi-tional CID to each call. If there are 64 HSDPA users to a radio cell, and 3 radio cells toa Node B, the CID requirements add up to 576 CIDs per Node B. Since the CID is an 8bit number (ranging from 0 to 255; not all values are available for usage), at least 3 AAL2VCs must be allocated just to provide enough CIDs for a fully equipped HSDPA capableNode B.

6.1.1 Flow ControlWith regard to HSDPA, it is not the RNC but the Node B that controls the transfer rateon Iub. This transfer rate is adjusted to the transfer rate that is achieved on the air inter-face, Uu. For each HSDPA UE, the Node B maintains a buffer (’priority queue’) thatstores the HSDPA user data until it is transmitted over the Uu interface. The Node B re-quests data from the RNC using the credit-based flow control mechanism of 3GPPTS25.435, ’Iub Interface User Plane Protocols for COMMON TRANSPORT CHANNELData Streams’. By requesting more or fewer data packets from the RNC, this buffer iskept at a filling level between an upper and a lower boundary. Among other factors, thenet Uu transfer rate depends on radio interference and the number of retransmissions.

146

Refilling the priority queues is subject to the availability of bandwidth on the Iub inter-face: if conventional traffic does not leave enough bandwidth, HSDPA buffers may tem-porarily go empty. This is an intentional behavior since HSDPA data is of the interactiveand 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, orif 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-DSCHCapacity Allocation message. This message contains information elements (Credits, In-terval, Repetition Period) which can be interpreted by the RNC as an offer regardingdata rates or data packets.

After the first capacity allocation, the HS-DSCH MAC-d flow control is mainly driven bythe 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 ManagementMAC-d is the protocol in the radio network layer (see 2.1.1 "HSDPA Protocol Stack inUTRAN") that is used for data transfer and mapping between logical channels and trans-port channels. Each HS-DSCH is represented as a MAC-d flow and occupies an AAL2CID within the VC for AAL2 user plane traffic.

Managing the priority queues includes the following functions:• Setup of new priority queues, upon request by the SRNC• Deletion of priority queues, if required• Processing of incoming data• Transport block assembly and transfer of the transport block to the HS-PDSCH sym-

bol rate processing entity• Reporting relevant information to the scheduler• Error handling.

6.1.2 QoS MechanismWithin the RNC, QoS differentiation is performed on the AAL2 level. The assigned pri-orities are:

These assignments make sure that HSDPA traffic has least priority.

highest UDI, PS Streaming, AMR voicelow PS best-effort traffic on DCHlowest HS-DSCH

147

6.2 Functional SplitThe changes on the transport network layer with regard to HSDPA impact on both theRNC and the Node B. For more information, refer to "Interworking Between RNC andNode B" on page 35.

6.3 Man-Machine InterfaceThe RNC atrk HMI command (ATRK Interface GUI window) serves to view, block andunblock traffic that the RNC itself (rather than the operator) assigns to its hardware re-sources. This command has been expanded to also offer parameters related to the traf-fic that is automatically assigned to HSDST and HSPRLC cards.

The new hardware also introduces the following new HMI output messages:• 0053299 hsdps_fault• 0053300 hsdps_fault_recovery

The existing alarms• 0053268 cmuxbl_fault• 0053269 cmuxbl_fault_recovery• 1348012 trunk_card_congestion_occurred• 1348013 trunk_card_congestion_recovered

are modified to also cover faults in the HSPRLC hardware. For details see "Fault man-agement".


148

7 Air Interface (Uu) ModificationsWith the support of HSDPA, the Uu interface is upgraded to 3GPP Release 5. Thischange provides new Uu interface functionalities for the HSDPA-capable Node Bs, suchas:• MAC-hs protocol for scheduling between UEs• Adaptive modulation and coding (AMC)• Management of data queues for each UE

7.1 Functional DescriptionThe UMTS air interface (i.e. Uu interface) is the radio interface between the UMTS ter-restrial radio access network (UTRAN) and the user equipment (UE). The Uu interfacecomprises the control plane (C-plane) for signaling and the user plane (U-plane) for thetransfer of user data. The Uu interface consists of three protocol layers:• Physical layer (L1/PHY)• Data link layer (L2)

The data link layer is divided into sublayers:– Medium Access Control Protocol (L2/MAC)– Radio Link Control Protocol (L2/RLC)– Broadcast/Multicast Control Protocol (L2/BMC)– Packet Data Convergence Protocol (L2/PDCP)

• Network layer (L3)The radio resource control protocol (L3/RRC) is the only element of the network lay-er.

Fig. 7.1 provides an overview of the Uu interface’s protocol architecture. Service accesspoints are marked as ellipses.

149

Fig. 7.1 Uu interface protocol architecture

The 3GPP Release 5 (Rel 5) RNC is able to interoperate with a UE of Rel 99, Rel 4, andRel 5 via the Uu interface.

To support HSDPA, minimum changes are required in the UTRAN for compliancy to theRel 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 1Compared to 3GPP Rel 99, the functionalities of the physical layer measurements onthe Uu L1 (physical layer) are changed by Rel 5 with respect to the following:• Received total wideband power (RTWP)• Signal to interference ratio (SIR)

According to 3GPP Rel 5, the Rx antenna connector is the reference point when meas-uring the RTWP.

Furthermore, Rel 5 demands changes concerning the measurement of the SIR. In anRL set consisting of more than one RL, the reported value must be the linear summationof each RL’s SIR in the RL set. If Rx diversity is used, the RL’s SIR must be the linearsummation of each Rx antenna’s SIR for that RL. In addition, if cell portions are defined,SIR measurement must be possible in each cell portion.

The HSDPA-capable Node Bs already comply with these requests.

RLCRLC

RLCRLC

BMC

RRCPDCP

PDCP

GC Nt DC

Duplication avoidance

GC Nt DC

C-plane signaling U-plane information

UuS boundary

control

cont

rol

cont

rol

RLCRLC

RLCRLC

RLCRLC

RLCRLC

MAC

PHY

cont

rol

cont

rol

L1

L2/MAC

L3

L2/RLC

L2/BMC

L2/PDCP

Transport Channels

Logical Channels

150

7.1.2 Changes on the Uu Interface Layer 2The Rel 5-compliant upgrade of the Uu interface impacts on the Uu layer 2 (L2) whichconsists of the broadcast/multicast control (BMC), packet data convergence protocol(PDCP), radio link control (RLC), and media access control (MAC). The broadcast/mul-ticast control, the packet data convergence protocol, and the media access control re-main unchanged after the upgrade from 3GPP Rel 99 to Rel 5.

Radio Link Control (RLC)

In 3GPP Rel 5, the special length indicator (LI) values “111 1100” and“111 1111 1111 1100” are optionally used on the downlink (DL) whereas in Rel 99,these LI values were mandatory. The Rel 5 RNC always applies these special LIs.These values indicate the first octet of an RLC signaling data unit (SDU) in RLC unac-knowledged mode (UM). Both LI values are utilized to inform the UE that the RLC sign-aling data unit (SDU) exactly matches the data field of the RLC protocol data unit (PDU),thus enabling faster decoding on the UE side because the UE then does not have tosearch for the end of the RLC SDU.

On the uplink (UL), in contrast, these special LI values must be used in the 3GPP Rel 5-compliant UMR5.0, whereas in Rel 99, both LIs were forbidden on the UL. Possible in-terworking problems on the UL between Rel 99 RNCs and Rel 5 RNCs are avoided dueto the fact that the Rel 99 RNC already supports the handling of the two special LI valueson the UL in each RLC protocol machine.

On the RLC, there is no further impact on RNC because no new services/functions aremapped onto logical channels.

7.1.3 Changes on the Uu Interface Layer 3The following functionalities of the Uu L3 are affected by this Rel 5-compliant Uu modi-fication:• Radio resource control protocol• Identification of a UE’s 3GPP release• Features previously supported• RRC error handling

7.1.3.1 Impacts on the Radio Resource Control (RRC) ProtocolThe RRC is the Uu L3 protocol. The RRC protocol defines protocol extensions in orderto 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, andRel 5 RRC structures. According to 3GPP, the UE always comprehends the completetransfer syntax specified for its supported protocol version (backward compatibility). ARel 5 UE, therefore, is able to comprehend Rel 99 and Rel 4 message structures aswell.

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

151

(UL) and downlink (DL) messages, whereas critical extensions can only be applied inDL direction. These two kinds of message extensions are processed as follows:• Non-critical extensions

In general, the receiver processes messages including non-critical extensions whichare not comprehended as if these extensions were absent.The sending of messages containing non-critical extensions is performed by addinga non-critical extension container at the end of a release-specific message. Thus,such messages consist of two parts - the actual message and a non-critical exten-sion. Both parts are release-specific.

• Critical extensionsWhen receiving a message including a critical extension which is not comprehend-ed, the receiver will entirely reject this message and inform the sender about the re-jection. A partial rejection of messages is not possible.To send messages with critical extensions, a new version of the message has to bedefined. 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, andRel 5) are distinguished.

Due to the introduction of 3GPP Rel 5-compliant critical and non-critical message exten-sions, enhanced functionalities are required for the RNC’s Rel 5 RRC decoder and en-coder:• Rel 5 RRC decoder

The Rel 5 decoder is able to comprehend Rel 99, Rel 4, and Rel 5 UL messages in-cluding all non-critical extensions introduced up to Rel 5. The decoded messageswill then be sent to the RNC application.

• Rel 5 RRC encoderRNC’s Rel 5 RRC encoder must take care of the UE’s release in order to use theappropriate message structure and include only those critical and non-critical exten-sions supported by the relevant release. Thus, the inclusion of protocol extensionsfrom releases later than the UE’s release is prevented.In UMR5.0, all HSDPA-related messages are encoded with a Rel 5 structure. Thefollowing messages are affected:– CELL UPDATE CONFIRM– RADIO BEARER SETUP– RADIO BEARER RELEASE– RADIO BEARER RECONFIGURATION– TRANSPORT CHANNEL RECONFIGURATION– MEASUREMENT CONTROL (Rel 4 structure with Rel 5 non-critical extensions)

7.1.3.2 Identification of a UE’s 3GPP ReleaseThe Rel 5 RNC obtains the UE’s supported protocol version upon one of the threeevents listed below. In each of these cases, the relevant messages include the new “Ac-cess Stratum Release Indicator“ IE indicating the 3GPP release which the UE supports.Rel 99 is indicated whenever this IE is absent, whereas the presence of the IE indicateseither Rel 4 or Rel 5.

The UE furthermore sends its radio access capabilities contained in the RRC: UE CA-PABILITY INFORMATION. This information always includes Rel 99 capabilities and op-tionally Rel 4 and/or Rel 5 capabilities, depending on the UE’s release.

The RNC then stores this information for the duration of the call.

152

• RRC connection establishmentThe establishment of an RRC connection is inititated upon reception of the RRC:CONNECTION REQUEST message. The UE always includes the ’Access StratumRelease Indicator’ IE in this message. The UE may send other radio access capa-bilities in the RRC: COONECTION SETUP COMPLETE message, together withRel 99 capabilities.The RNC then stores any capability information received for the duration of the call.

• Inter-RAT handover to UTRANAn inter-RAT handover to UTRAN is performed upon reception of the RANAP: RE-LOCATION REQUIRED message.The RNC checks if the ’Access Stratum Release Indicator’ IE is present.– If the ’Access Stratum Release Indicator’ IE is absent during inter-RAT handover

to UTRAN, the RNC treats the relevant UE as Rel 99 UE.– Otherwise, if both the INTER RAT HANDOVER INFO part of the relevant RRC

container includes this IE and the IE indicates Rel 4 or Rel 5, the RNC initiatesthe “UE Capability Enquiry” procedure due to the fact that Rel 4 and Rel 5 IEs arenot part of the RRC container for inter-RAT handover to UTRAN. Thereupon, theRNC proceeds as described above.

• Serving Radio Network Subsystem (SRNS) relocationThe SRNS relocation is performed upon reception of the RANAP: RELOCATIONREQUIRED message.In the event of an SRNS relocation, the identification procedure is similar to that ofan inter-RAT handover.– First, the SRNC includes the UE capabilities, containing Rel 99, Rel 4 and Rel 5

capabilities, in the SRNS Relocation RRC container. This container is then trans-ferred to the target RNC (TRNC).

– The TRNC, in turn, checks either whether the ’Access Stratum Release Indicator’IE is present and all Rel 5-related UE radio access capabilities have been re-ceived, or, alternatively, whether the ’Access Stratum Release Indicator’ IE is ab-sent, thus implying a Rel 99 UE. If neither of these conditions is met and if no PSinteractive/background RAB exists, the target RNC performs the “UE CapabilityEnquiry“ procedure.

This behavior of the TRNC is necessary in case the the SRNC supports a 3GPP re-lease lower than that of the UE and of the TRNC. In such a scenario, the SRNC isnot able to decode/encode all UE capability IEs and therefore omits them from theRRC container.The reason why the TRNC checks for an existing PS interactive/background RAB isthe following: If the RRC container does not include Rel 5 capabilitiesduring the re-location resource allocation, the TRNC then treats this UE as Rel 99-capable onlyand 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 notbe possible to reallocate some resources (e.g. HS-PRLC) to any existing PS inter-active/background RAB. As a consequence, the UE would therefore continuouslyhave 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 arenot used. On the other hand, if a UE supports Rel 5, the RNC applies Rel 5 message

153

structures to only those messages containing HSDPA-related IEs. Other messages areof Rel 99 structure. The following messages may contain HSDPA-related IEs:• CELL UPDATE CONFIRM

SRNC relocation on FACH and re-establishment on FACH• RADIO BEARER SETUP

RAB setup from FACH/DCH to HS-DSCH and from HS-DSCH to DCH• RADIO BEARER RELEASE

RAB release from HS-DSCH to DCH• RADIO BEARER RECONFIGURATION

Setup or release of a second PS BE RAB• TRANSPORT CHANNEL RECONFIGURATION

Channel-type switching (CTS) from FACH to HS-DSCH• MEASUREMENT CONTROL

Setup of event 1D

7.1.3.3 Impacts of 3GPP Rel 5 on Previously Supported FeaturesFor stable operation of an HSDPA-cabable Uu interface, few changes to previously sup-ported features are essential. Features affected by Rel 5 HSDPA are:• Security mode control• Radio bearer control procedures• Tx diversity

The establishment and the release of an RRC connection, however, are not affected bythe 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 thesignaling radio bearer 2 (SRB2). The COUNT-I value of this message will be higher thanthe value of the COUNT-I which was used prior to sending the SECURITY MODE COM-MAND message and then incremented by one. In previous releases, the value for theRRC switching network (SN), being one part of the COUNT-I, was not incremented inthe event of a wrap-around.

Radio bearer control procedures

In Rel 99, the RADIO BEARER RECONFIGURATION message always included the“Primary CPICH Info“ IE if FDD was used. Thus, as a restriction, the UTRAN had to in-form a cell about whether it uses the RADIO BEARER RECONFIGURATION messageto move the UE to CELL_FACH state or not. The UE, however, performed cell selectionand 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 RNCdoes not have to include the “Primary CPICH Info“ IE in the event of a relocation toCELL_DCH.

Tx diversity

In Rel 99, UEs were permitted to apply Tx diversity to all RLs in the active set even if theUTRAN 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 isindicated by the UTRAN. However, since UEs were already allowed to recognize the ac-

154

tive RLs in non-diversity cells (individual RL mode NONE) in Rel 99, this change simplymeans a clarification of the UE’s behavior.

7.1.3.4 RRC Error HandlingThe RNC’s RRC handling of unknown, unforeseen, and erroneous protocol data is com-pliant to 3GPP TS 25.331, section 9. The RNC’s RRC decoder comprehends all newand 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 applya graceful application error handling.

7.2 Functional SplitNot applicable.

7.3 Man-Machine InterfaceNot applicable.

7.4 Operating the FeatureNot applicable.

i NOTEIn UMR5.0, Node Bs are not capable of providing Tx diversity for HSDPA cells.

155

8 HSDPA Performance Measurement Counters

8.1 Functional DescriptionTab. 8.1 shows the performance measurement counters that are newly introduced withsupport of HSDPA. Modifications to existing scanners are listed in Tab. 8.2.

The mtype values are used to configure performance measurements on the CLI inter-face of the LMT-RNC.

The Shortname values are used to configure performance measurements on the CLIinterface of the Radio Commander.

Measurement mtype Shortname Purpose

Measurements performed on RNC

Procedure related measurements

Number of attempted RadioLink Establishments for HS-DSCH

7 hsEstabAtt This measurement provides the number of attemptedHS-DSCH radio link Establishments for each HSDPAcell.The measurement is based on two events:– Transmission of NBAP: RADIO LINK SETUP RE-QUEST by the RNC to the Node B requesting to set up anew HS-DSCH (FACH to HS-DSCH); and– Transmission of NBAP: RADIO LINK RECONFIGURA-TON PREPARE message by the RNC to the Node B re-questing to set up a new HS-DSCH (DCH to HS-DSCH).Only messages initiated from the CRNC are taken intoaccount.

Number of unsuccessful Ra-dio Link Establishments forHS-DSCH per failure cause

101 hsEstabFail This measurement provides the number of unsuccessfulHS-DSCH radio link Establishments for each cell. Foreach failure cause a separate sub-counter is definedThe measurement is based on three events:– Receipt of NBAP: RADIO LINK SETUP FAILURE sentby the Node B in response to a RADIO LINK SETUP RE-QUEST message requesting the setup of a new HS-DSCH– Receipt of NBAP: RADIO LINK RECONFIGURATIONFAILURE sent by the Node B in response to a RADIOLINK RECONFIGURATION PREPARE message for set-up of a new HS-DSCH– Non-receipt of NBAP: RADIO LINK SETUP RE-SPONSE or NBAP: RADIO LINK RECONFIGURATIONREADY (expiration of the appropriate timer) in responseto a RADIO LINK SETUP REQUEST or RADIO LINKRECONFIGURATION PREPARE sent from the RNC tothe Node B, indicating the attempt to establish a new HS-DSCH.Only trigger conditions related to the CRNC are consid-ered. Failure causes are defined in 3GPP TS25.433.

Tab. 8.1 New Performance Management counters

156

Subsystem related measurements

HSPRLC / PRLC throughputrate

192 hsprlcThroughputRate

This measurement indicates the used channels/band-width on HSPRLC and PRLC, given as a percentage ofthe maximum performance. Thus, it indicates the RNChardware utilization by HSDPA service. Several sub-counters are defined for average and maximum valuesfor UL and DL direction.

HSDST throughput rate 193 hsdst-Throughpu-tRate

This measurement provides the HSDST throughput rate,given as a percentage of the HSDST maximum perform-ance. Several sub-counters are defined for average andmax values for UL and DL direction.

Number of attemptedHSPRLC allocations

72 hsprlcAllo-cAtt

This counter collects the number of Resource AllocationRequests of HSPRLC.

Number of successfulHSPRLC allocations

73 hsprlcAlloc-Succ

This counter collects the number of successful ResourceAllocation Requests of HSPRLC.

Number of attempted HSDSTallocations

74 hsdstAllo-cAtt

This counter collects the number of Resource AllocationRequests of HSDST.

Number of successfulHSDST allocations

75 hsdstAlloc-Succ

This counter collects the number of successful ResourceAllocation Requests of HSDST.

RRC connection state management

Number of attempted transi-tions from HS-DSCH toFACH

135 hsTransto-FachAtt

This measurement provides the number of attemptedswitches from HS-DSCH to the CELL_FACH state foreach cell.

Number of unsuccessful tran-sitions from HS-DSCH toFACH state per failure cause

136 hsTransto-FachFail

This measurement provides the number of unsuccessfulswitches from HS-DSCH to the CELL_FACH state foreach cell per cause.

Number of attempted transi-tions from FACH to HS-DSCH

137 hsTrans-FromFach-Att

This measurement provides the number of attemptedswitches from CELL_FACH state to HS-DSCH for eachcell.

Number of unsuccessful tran-sitions from FACH state toHS-DSCH per failure cause

138 hsTrans-FromFach-Fail

This measurement provides the number of unsuccessfulswitches from CELL_FACH state to HS-DSCH for eachcell per cause.

RAB assignment

Number of unsuccessful Ra-dio Bearer Reconfigurationsper failure cause

92 rbReconfFail This counter records the number of unsuccessful radiobearer reconfigurations.

Measurements performed on Node B

HSDPA Cell measurement functions



157

HS-PDSCH code usage ratio hsCodeUsageRatio This ratio indicates the number of HS-PDSCH codes ofone TTI, related to the total number of TTI and the maxi-mum number of HS-PDSCH codes per cell. Only TTIswhere HS-PDSCH codes have been transmitted are con-sidered. There is no difference if the codes are used asQPSK or 16QAM codes. The usage ratio of HS-PDSCHcode is measured every 10 seconds. At the end of thegranularity period, the mean, minimum and maximumvalues are provided.

HSDPA Cell Throughput hsCellThroughput The HSDPA cell throughput records the number of MAC-hs PDU bits including MAC-hs header.The cell throughput is measured every 10 seconds inkbit/s. At the end of granularity period the mean, mini-mum and maximum values are provided.

HARQ NACK ratio hsNackRatio This counter is provided for monitoring the system per-formance and validation of HS-PDSCH/HS-SCCH powercontrol mechanism.The measurements records the sum of all not acknowl-edged data transmissions (including re-transmission)and compares it to the number of all TX attempts. TheHARQ NACK ratio is measured every 10 second. At theend of the granularity period the mean, minimum andmaximum values are provided.

BB usage ratio for HSDPA re-sources

hsBBUsageRatio Provides the mean and maximum base band load forHSDPA resources per cell during the complete granular-ity period.This counter provides additional information related toHSDPA resources, in addition to the existing base band(BB) usage ratio counters. The BB usage ratio considersthe utilized resources per Node B related to the licensedresources, whereas the BB usage ratio for HSDPA is re-lated to the UL resources per HSDPA capable CHCcards not based on the license information. For all cellsconfigured on the same HSDPA capable CHC card thesame values are provided.



Measurement mtype Shortname Modification

UE quantity measurements

Mean number of bearer services per cell re-lated

152 bearService-perCell

HS-DSCH is added to the range of ob-jects considered by this counter.This measurement provides the meannumber of bearer services per cell.

Tab. 8.2 Modified Performance Management counters

158

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 dedicatedchannels per Node B’ (mtype=140) remains unchanged. It covers• both HSDPA and non-HSDPA call data on the uplink• only non-HSDPA call data on the downlink.

The existing PM counters• Number of successful bearer service establishments per cell related (mtype=155)• Mean number of bearer services on lub (mtype=156)

are modified to take account of the new bearers– PS Interactive/Background 64/0– PS Interactive/Background 384/0– PS Interactive/Background 64/0+HS-DSCH– PS Interactive/Background 384/0+HS-DSCH.

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

8.3 Man-Machine InterfaceThe new performance counters are configured using the existing commands and GUIwindows on LMT-RNC or LMT-NB and OMC.


159

9 Operating HSDPANot yet applicable.

160

10 Abbreviations16QAM 16 Quadrature Amplitude Modulation3GPP 3rd Generation Partnership ProjectAAL2 Asynchronous Transfer Mode Adaptation Layer 2AAL5 Asynchronous Transfer Mode Adaptation Layer 5AC Admission ControlACK Acknowledged (message)AGC Automatic Gain ControlALCAP Access Link Control Application PartALS Alarm StateAMR Adaptive Multi-RateAMREQ AMR EquivalentsARQ Automatic Repeat RequestAST Administrative StateATM Asynchronous Transfer ModeAVS Availability StatusBB BasebandBE Best EffortBLSC Broaden Line Switch ControllerBMC Broadcast/Multicast ControlBRA Bit-Rate AdaptationCAC Connection Admission ControlCAPEX Capital ExpenditureCAT Combined Amplifier and TransceiverCC Core ControllerCCH Common ChannelCE Channel ElementCHC Channel Coding CardCID Call IdentifierCIR Carrier- to Interference-Power RatioCLI Command Line InterfaceCmCH-PI Common Transport Channel - Priority IndicatorCMP Composite/DecompositeCMUX Cell MultiplexerCN Core NetworkCQE Channel Quality EstimationCQI Channel Quality InformationCRC Cyclic Redundancy CheckcRNC Classical Radio Network Controller (based on UMR2.0 HW)CRNC Controlling Radio Network ControllerCS Circuit-SwitchedCTS Channel-Type SwitchingDBMS Database Management SystemDCCH Dedicated Control ChannelDCH Dedicated ChannelDHT Diversity Handover Trunk

161

DL DownlinkDLCC Downlink Common ChannelDPCCH Dedicated Physical Control ChannelDRIC Digital Radio Interface CardDRNC Drift Radio Network ControllerDSCP Differentiated Services Code PointDSL Digital Subscriber LineDSP Digital Signal ProcessorDTCH Dedicated Traffic ChannelDUAMCO Duplexer Amplifier MulticouplerE1 European Plesiochronous Digital Hierarchy Signal Level 1eRNC RNC with Enhanced Capacity and ConnectivityETSI European Telecommunications Standards InstituteFACH Forward Access ChannelFP Frame ProtocolFW FirmwareGMUX GTP MultiplexerGTP GPRS Tunneling ProtocolGPRS General Packet Radio ServiceGUI Graphical User InterfaceHARQ Hybrid Automatic Repeat RequestHCS Hierarchical Cell StructureHMI Human-Machine InterfaceHMO Hardware Managed Objecths-CHC Highspeed Channel Coding CardHSDPA Highspeed Downlink Packet AccessHS-DPCCH Highspeed Dedicated Physical Control ChannelHS-DSCH Highspeed Downlink Shared ChannelHS-DSCH FP Highspeed Downlink Shared Channel Frame ProtocolHSDST Highspeed Downlink Shared Channel TrunkHS-PDSCH Highspeed Physical Downlink Shared ChannelHSPRLC Highspeed Packet Radio Link ControllerHS-SCCH Highspeed Shared Control ChannelHW HardwareI/B Interactive/Background (radio access bearer)ID IdentifierIDF Inventory Data FileIE Information ElementIMA Inverse Multiplexing for Asynchronous Transfer ModeIP Internet ProtocolISO International Standard OrganizationITU International Telecommunications UnionIu Interface between an RNC and the Core NetworkIub Interface between an RNC and a Node BIur Interface between two RNCsJ1 Japanese Plesiochronous Digital Hierarchy Signal Level 1L1 Layer 1

162

L2 Layer 2L3 Layer 3LI Length IndicatorLMT Local Maintenance TerminalLPA Linear Power AmplifierLSM Line Switch ModuleMAC Medium Access ControlMAC-d Medium Access Control - DedicatedMAC-hs Medium Access Control - High SpeedMMI Man-Machine InterfaceMOI Managed Object InstanceMOC Managed Object ClassNACK Not Acknowledged (message)NBAP Node B Application PartOAM Operation and MaintenanceOC-3 Optical Carrier Level 3OMC Operation and Maintenance CenterOSI Open System InterconnectOST Operational StateOTS Operation and Maintenance Tool SetP-CPICH Primary Common Pilot ChannelPDCP Packet Data Convergence ProtocolPDU Protocol Data UnitPM Performance MeasurementPRLC Packet Radio Link ControllerPRM Packet Radio Link Control ModulePRS Procedural StatePS Packet-SwitchedPSCR Physical Shared Channel ReconfigurationQoS Quality of ServiceQPSK Quadrature Phase Shift KeyingQRS Quality Requirement SpecificationRAB Radio Access BearerRACH Random Access ChannelRAT Radio Access TechnologyRB Radio BearerRC Radio CommanderRel 4 3GPP Release 4Rel 5 3GPP Release 5Rel 99 3GPP Release 99REP RepeaterRF Radio FrequencyRL Radio LinkRLC Radio Link ControlRNC Radio Network ControllerRNC-BE Radio Network Controller - Back EndRNC-FE Radio Network Controller - Front End

163

RNL Radio Network LayerRNS Radio Network SubsystemRNTI Radio Network Temporary IdentifyRRC Radio Resource ControlRRH Remote Radio HeadRRM Radio Resource ManagementRSI Resource Status IndicationRTWP Received Total Wideband PowerSBS Standby StateS-CPICH Secondary Common Pilot ChannelSDU Signaling Data UnitSF Spreading FactorSIR Signal to Interference RatioSN Switching NetworkSRB Signaling Radio BearerSRB2 Signaling Radio Bearer 2SRNC Serving Radio Network ControllerSRNS Serving Radio Network SubsystemSTM-1 Synchronous Transport Module Level 1STTD Space Time Transmit DiversitySW SoftwareSWP System-Wide ParameterT1 North American Plesiochronous Digital Hierarchy Level 1TB Transport BearerTINF Trunk InterfaceTNL Transport Network LayerTOS Type of ServiceTRNC Target Radio Network ControllerTRX Transceiver (Transmitter/Receiver)TTI Time Transmission IntervalUDP User Datagram ProtocolUE User EquipmentUL UplinkUM Unacknowledged ModeUMR UMTS Mobisphere ReleaseUMTS Universal Mobile Telecommunications SystemUTOPIA Universal Test and Operations Physical Interface for ATMUTRAN UMTS Terrestrial Radio Access NetworkUu Radio Interface between the UTRAN and the User EquipmentVC Virtual ChannelVCI Virtual Channel IdentifierVP Virtual PathVPI Virtual Path IdentifierWCMP Wideband Composite/DecompositeWLAN Wireless Local Area NetworkWLSC Wideband CMP and Line Switch Controller

Documents

Hsdpa Technical Description