Sie sind auf Seite 1von 242

UTRAN

Technical Description
System


TED:UTRAN Common
A50016-G5000-H200-01-7618
ND-57282-708(E)-01


2 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580103e52
f Important Notice on Product Safety
Elevated voltages are inevitably present at specific points in this electrical equipment. Some of the parts
may also have elevated operating temperatures.
Non-observance of these conditions and the safety instructions can result in personal injury or in prop-
erty damage.
Therefore, only trained and qualified personnel may install and maintain the system.
The system complies with the standards EN 60950-1 / IEC 60950-1; EN 60215 / IEC 60215 and
EN 60825-1/2. All equipment connected has to comply with the applicable safety standards.
The same text in German:
Wichtiger Hinweis zur Produktsicherheit
In elektrischen Anlagen stehen zwangslufig bestimmte Teile der Gerte unter Spannung. Einige Teile
knnen auch eine hohe Betriebstemperatur aufweisen.
Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Krperverletzungen und
Sachschden fhren.
Deshalb wird vorausgesetzt, dass nur geschultes und qualifiziertes Personal die Anlagen installiert und
wartet.
Das System entspricht den Anforderungen der EN 60950-1 / IEC 60950-1; EN 60215 / IEC 60215 und
EN 60825-1/2. Angeschlossene Gerte mssen die zutreffenden Sicherheitsbestimmungen erfllen.
Trademarks:
All designations used in this document can be trademarks, the use of which by third parties for their
own purposes could violate the rights of their owners.
Copyright (C) 2007 Siemens Networks GmbH & Co. KG / NEC Corporation
Issued by:
Siemens Networks GmbH & Co KG, Hofmannstrae 51, 81359 Mnchen, Germany
and
NEC Corporation, 7-1, Shiba 5-chome, Minato-ku, Tokyo, Japan
Technical modifications possible.
Technical specifications and features are binding only insofar as they are specifically and expressly agreed upon in a written contract.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
3
TED:UTRAN Common
Id:0900d80580103e52
Table of Contents
This document has 242 pages.
Reason for Update. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1 Brief Description of the Siemens/NEC UTRAN Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Who Should Read the TED:UTRAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3 Where to Look for Which Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4 Customer Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.5 Operation and Maintenance of UTRAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.6 Overview of the UTRAN Product Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.6.1 Macro FDD Node B (NB-440/NB-441). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.6.2 Macro FDD Node B (NB-420) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.6.3 Micro FDD Node B (NB-341) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.6.4 Macro FDD Node B (NB-530) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.6.5 Macro FDD Node B (NB-880/NB-881/NB-881 HR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.6.6 Macro FDD Node B (NB-860/NB-861). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.6.7 Macro Radio Server (RS-880) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.6.8 19 Micro Radio Server Slider Unit (RSSU-380) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.6.9 Micro Radio Server Carrier Unit (RSCU-380) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.6.10 Micro Radio Server (RS-381) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.6.11 Macro Remote Radio Head (RRH-m/RRH-mh) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.6.12 Micro/Pico Remote Radio Head (RRH-pi) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.6.13 Radio Network Controller (RN-750). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.6.14 Radio Network Controller (RN-880). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
1.7 2G/3G Co-Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2 UTRAN Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.1 The UMTS Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.1.1 The UMTS PLMN Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.1.2 Layers and Protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.1.3 The Radio Network Subsystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.1.4 Area Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.2 Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.2.1 Interface Protocol Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.2.2 Uu Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.2.2.1 Radio Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.2.2.2 Physical Layer (L1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
2.2.2.3 Data Link Layer (L2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
2.2.2.4 Network Layer (L3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.2.3 Iub Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.2.3.1 Iub Interface Protocol Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.2.3.2 NBAP Signaling on Iub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2.2.4 Iur Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2.2.4.1 Iur Interface Protocol Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
2.2.4.2 RNSAP Signaling on Iur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
2.2.5 Iu Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70


4 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580103e52
2.2.5.1 Iu CS Interface Protocol Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2.2.5.2 Iu PS Interface Protocol Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2.2.5.3 RANAP Signaling on Iu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
2.2.5.4 Iu User Plane Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2.2.5.5 Iu BC Interface Protocol Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
2.2.5.6 CBS Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
2.2.5.7 SABP on Iu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
2.2.5.8 Broadcast/Multicast Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
2.2.5.9 Broadcast/Multicast Interworking Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
2.3 Transport Network Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
2.3.1 Circuit Emulation Service (CES) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
2.3.2 Overbooking on Iub. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
2.3.3 AAL2 Ownership. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
2.3.4 Bandwidth Optimization During BRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
2.3.5 DL Silent Mode on Iub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
2.3.6 Automatic Protection Mechanism for Faulty ATM Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
2.3.7 Support of AAL2 Switching in CN for Iur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
2.3.8 Extended SS7 Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
2.3.9 Modifications for HSDPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
2.3.10 HSDPA Traffic Separation and UBR+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
2.3.11 IP/Ethernet at Iub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
2.4 UTRAN Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
2.4.1 Channel Coding/Decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
2.4.1.1 Transport Channel Coding/Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
2.4.2 Signal Flow in Node B/Radio Server and Remote Radio Head . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
2.4.2.1 Uplink Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
2.4.2.2 Downlink Path. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
2.4.3 HSDPA Iub Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
2.4.4 HSDPA Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
2.4.5 Diversity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
2.4.5.1 Receiving Diversity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
2.4.5.2 Macro Diversity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
2.4.6 Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
2.4.6.1 Open Loop Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
2.4.6.2 Inner Loop Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
2.4.6.3 Outer Loop Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
2.4.6.4 Power Balancing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
2.4.6.5 HSDPA Power Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
2.4.7 Remote Electrical Antenna Tilt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
2.4.7.1 Remote Tuning During Initial Network Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
2.4.7.2 Remote Re-configuration During Network Expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
2.4.7.3 Remote Re-configuration due to Node B Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
2.4.7.4 Re-configuration During Network Optimization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
2.5 UTRAN Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
2.5.1 Cell Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
2.5.2 Cell Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
2.5.3 Supported FDD Frequency Bands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
5
TED:UTRAN Common
Id:0900d80580103e52
2.5.4 Cell Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
2.5.5 Adjacent Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
2.5.6 Cell Individual Offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
2.5.7 Master Cells. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
2.5.8 HSDPA Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
2.5.9 Indication of HSDPA Capable Cells. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
2.5.10 Cell Specific Handover Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
2.6 Relocation and Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
2.6.1 Classification of Handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
2.6.2 SRNS Relocation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
2.6.2.1 Inter-Frequency Inter-PLMN Relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
2.6.2.2 Intra-Frequency Intra-PLMN Relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
2.6.2.3 Intra-Frequency Inter-PLMN Relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
2.6.3 Compressed Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
2.6.4 Inter-System Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
2.6.4.1 UMTS-GSM Handover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
2.6.4.2 UMTS Cell (Re-)Selection to/from GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
2.6.4.3 GSM-UMTS Handover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
2.6.4.4 UMTS Cell Change Order to GSM/GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
2.6.4.5 Handling of E911 Emergency Calls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
2.6.4.6 UMTS Handover to/from GSM850/1900 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
2.6.5 Inter-RNC Handover (Soft Iur Handover) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
2.6.6 Intra-Node B/Intra-RNC Handover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
2.6.7 Hierarchical Cell Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
2.6.8 Inter-Frequency Handover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
2.6.9 IMSI Based Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
2.6.10 Service Based Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
2.6.11 Load Based Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
2.6.12 IMSI Based Forced Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
2.7 Overload Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
2.8 Ciphering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
2.8.1 Security Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
2.8.2 Location of Ciphering Function in UTRAN Protocol Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
2.8.3 Input Parameters to the Ciphering Algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
2.9 Quality of Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
2.9.1 UMTS QoS Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
2.9.2 UMTS Bearer Service Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
2.9.3 IETF Differentiated Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
2.10 Bearer Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
2.10.1 Radio Access Bearer (RAB) Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
2.10.2 RAB Pre-emption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
2.10.3 Data Rate Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
2.10.3.1 Transport-Channel-Type Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
2.10.3.2 Bit Rate Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
2.10.3.3 Load Based Bit Rate Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
2.10.4 Higher Layer Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
2.10.5 HSDPA Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145


6 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580103e52
2.10.6 RAB Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
2.10.6.1 PS Streaming RAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
2.10.6.2 CS Streaming RAB for Remote Modem Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
2.10.6.3 PS C + PS I/B RAB for Realtime Gaming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
2.11 Radio Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
2.12 Handling of Special UEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
2.12.1 RAB Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
2.12.2 Measurement Control Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
2.12.3 Handling of Transport Channel Information at RAB Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
2.12.4 Handling of RNS Relocation on Cell_DCH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
2.12.5 UE Support of HSDPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
3 Operation and Maintenance of the UTRAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
3.1 Tool Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
3.2 Function Split of OAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
3.3 Configuration Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
3.4 Software Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
3.5 Fault Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
3.6 Test Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
3.7 Performance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
3.7.1 Performance Management on the Radio Network Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
3.7.2 Performance Management on the Transport Network Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
3.8 Alarm Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
3.9 Security Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
3.9.1 Security in the OMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
3.9.2 Security in the LMT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
3.10 State Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
3.11 Relationship Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
3.12 UTRAN-specific Transport Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
3.12.1 Configuration Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
3.12.2 Fault Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
3.12.3 Performance Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
3.12.4 Quality of Service for ATM traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
3.13 Call Tracing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
3.14 Remote Antenna Downtilt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
3.15 Remote Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
3.16 License Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
4 UTRA Network Element Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
4.1 Iu, Iub, and Iur Interface Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
4.2 Iub Interface Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
4.3 Iur Connection Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
4.4 Iu Connection Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
4.5 UMTS/GSM Co-Location Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
4.6 Transcoder Free Operation in CN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
4.7 ATM/Multiservice Switch Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
4.7.1 Support of Iu, Iur Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
4.7.2 Support of Iub Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
7
TED:UTRAN Common
Id:0900d80580103e52
4.7.3 Node B Hubbing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
4.7.4 RNC Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
4.7.5 Sharing of Transport Resources with TDM Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
5 Quality Standards / Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
5.1 Legal Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
5.2 Industrial Standards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
5.3 Quality Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
5.4 Telecommunication Link Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
5.5 Jitter and Wander Standards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
5.6 Surge (Lightning) Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
5.7 Environmental Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
5.7.1 Environmental Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
5.8 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
5.8.1 Reliability Calculations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
5.8.2 Maintainability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
5.8.3 Built-in Self-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
5.9 List of Norms and Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
6 Appendix - Message Sequence Charts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
6.1 External Inter-RNC and Inter-PLMN Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
6.2 Inter/Intra-Frequency Inter-PLMN Relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
6.3 Intra-Frequency Intra-PLMN Relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
6.4 UMTS-GSM Handover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
6.5 GSM-UMTS Handover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
6.6 Compressed Mode and GSM Measurement Activation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
6.7 Compressed Mode and GSM Measurement Deactivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
6.8 UMTS Cell (Re-)Selection to/from GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
6.9 Soft Handover - Radio Link Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
6.10 Soft Handover - Radio Link Deletion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
6.11 Softer Handover - Radio Link Addition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
6.12 Softer Handover - Radio Link Deletion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
6.13 Inter-Frequency Handover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
6.14 IMSI Based Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
6.15 Pre-emption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
6.16 Cell Change Order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242


8 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580103e52
List of Figures
Figure 1 The UMTS Radio Access Network (UTRAN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figure 2 NB-440 indoor cabinet and NB-441 outdoor cabinet (base rack/shelter, REP-TRX-LPA concept) . 22
Figure 3 NB-420 indoor cabinet (REP-TRX-LPA concept) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 4 NB-341 outdoor cabinet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figure 5 NB-530. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 6 NB-880 indoor cabinet and NB-881 base frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 7 NB-881HR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 8 NB-860 indoor cabinet and NB-861 base frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figure 9 Radio Server RS-880. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figure 10 Radio Server Slider Unit RSSU-380 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figure 11 Radio Server Carrier Unit RSCU-380 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figure 12 Radio Server RS-381. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figure 13 Macro Remote Radio Head . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figure 14 Micro/Pico Remote Radio Head . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Figure 15 RN-750 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figure 16 RNCi (RN-880) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figure 17 Subsystems of the PLMN and their Network Elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figure 18 Layers and Protocols within AS and NAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figure 19 The Radio Network Subsystem (RNS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figure 20 Logical Roles of the RNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figure 21 UE Registration and Connection Setup for 3G MSC and 3G SGSN. . . . . . . . . . . . . . . . . . . . . . . . 47
Figure 22 Connection of UEs and MSs to CN and Mobility Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figure 23 Area Concepts (Cells Are not Shown) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figure 24 Interfaces within UMTS for Multipoint to Multipoint Communication . . . . . . . . . . . . . . . . . . . . . . . . 50
Figure 25 Interfaces within UMTS for Unidirectional Point to Multipoint Communication . . . . . . . . . . . . . . . . 51
Figure 26 Protocol Stacks in the Radio Network and the Transport Network Layer . . . . . . . . . . . . . . . . . . . . 52
Figure 27 Voice Communication (C Plane) Protocol Stack in M-L Link. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figure 28 Voice Communication (U Plane) Protocol Stack in M-L Link. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figure 29 HSDPA Protocol Stack within UTRAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figure 30 Protocol Stack within the RNC on HSDPA Traffic Route. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figure 31 Protocol Stack of the Iu Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figure 32 Protocol Stack of the Iur Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figure 33 Protocol Stack of the Iub Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figure 34 SMS Cell Broadcast Service Protocol Stack of Direct ATM Connection . . . . . . . . . . . . . . . . . . . . . 55
Figure 35 Uu Interface Protocol Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figure 36 Channel Concepts in UTRAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figure 37 Structure of the DPCH in Downlink Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figure 38 Structure of the DPCH in Uplink Direction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figure 39 Structure of the DPDCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figure 40 Mapping of Transport Channels to Physical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figure 41 Mapping of Transport Channels to Physical Channels with HSDPA. . . . . . . . . . . . . . . . . . . . . . . . 60
Figure 42 Structure of Transport Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figure 43 Structure of Logical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Figure 44 Mapping between Logical Channels and Transport Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figure 45 RRC Connection States. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
9
TED:UTRAN Common
Id:0900d80580103e52
Figure 46 Iub Interface Protocol Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Figure 47 Iur Interface Protocol Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Figure 48 Iu CS Interface Protocol Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Figure 49 Iu PS interface protocol structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Figure 50 Iu BC Interface Protocol Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Figure 51 ATM Multiplexing and ATM Cell Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Figure 52 ATM Virtual Paths and Virtual Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Figure 53 Coding/Multiplexing Steps for Uplink and Downlink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Figure 54 Uplink and Downlink Signal Flow in Node B (REP-TRX-LPA Concept) . . . . . . . . . . . . . . . . . . . . . 83
Figure 55 Uplink and Downlink Signal Flow in Node B (DRIC-CAT Concept) . . . . . . . . . . . . . . . . . . . . . . . . 84
Figure 56 Uplink and Downlink Signal Flow in Node B (RRH/CAT Mixed Mode). . . . . . . . . . . . . . . . . . . . . . 85
Figure 57 Uplink and Downlink Signal Flow for a RS/RRH Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Figure 58 Signal Flow in the External Amplifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Figure 59 Low Noise Amplifying and Power Splitting of the RX Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Figure 60 Uplink Signal Flow in the Receiver Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Figure 61 Uplink Signal Flow in the Digital (A/D) Conversion and Demodulation Part . . . . . . . . . . . . . . . . . . 89
Figure 62 Uplink Signal Flow at Channel Decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Figure 63 Uplink Signal Flow in the Interpolator Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Figure 64 Uplink Signal Flow in the Searcher Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Figure 65 Uplink Signal Flow in the Finger Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Figure 66 Uplink Signal Flow in the CODEC Part. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Figure 67 Downlink Signal Flow in the CHC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Figure 68 Allocation Strategy for Scrambling and Channelization Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Figure 69 Basic Code Allocation Strategy (Code Tree) for HSDPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Figure 70 Spreading of the Downlink Signal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Figure 71 Downlink Signal Flow in the Modulation and D/A Conversion Part . . . . . . . . . . . . . . . . . . . . . . . . 94
Figure 72 Downlink Signal Flow in the Transmitter Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Figure 73 Mapping of U-/T-Plane Functions to Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Figure 74 Receiving Diversity via the RAKE Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Figure 75 Handover Controlled by Macro-Diversity Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Figure 76 Closed Loop Power Control in the FDD Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Figure 77 DL Power Drift Between Radio Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Figure 78 UE with Multiple Established Radio Links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Figure 79 Node B Failure and Controlled Coverage Increase with Adjacent Cells. . . . . . . . . . . . . . . . . . . . 105
Figure 80 Optimized Coverage Area and Reduced Interference at Adjacent Cells . . . . . . . . . . . . . . . . . . . 105
Figure 81 Cell Load-Sharing Deployed in Inhomogeneous Load Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 106
Figure 82 Critical CPICH Area (Schematic) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Figure 83 Cells in the Active Set and in the Monitored Set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Figure 84 UE Handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Figure 85 UTRAN Handovers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Figure 86 Intra-Frequency Intra-PLMN Relocation (UE not Involved) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Figure 87 Intra-Frequency Inter-PLMN Relocation (UE Involved) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Figure 88 Intra-PLMN Intra-Frequency Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Figure 89 Intra-PLMN Intra-Frequency Handover (Iur Configured) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Figure 90 Intra-PLMN Intra-Frequency Handover (Iur not Configured) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Figure 91 Compressed Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Figure 92 Inter-System Handover of Different CN/UTRAN Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125


10 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580103e52
Figure 93 Hierarchical Cell Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Figure 94 Network Traffic Sharing Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Figure 95 Overview of the Security Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Figure 96 Ciphering Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Figure 97 UMTS QoS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Figure 98 Mapping of the IETF and RAB QoS Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Figure 99 Admission Control and Radio Bearer Control/Translation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Figure 100 Structure of the Protocol Layers for Bidirectional Streaming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Figure 101 Logical Overview on Radio Resource Management Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Figure 102 Radio Resource Management Functions in the SRNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Figure 103 Radio Resource Management Functions in the CRNC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Figure 104 The OAM concept of the UTRAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Figure 105 Tool Interworking Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Figure 106 Telecommunications management network model of a Siemens/NEC UTRAN system. . . . . . . . 162
Figure 107 The benefit of traffic shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Figure 108 Overview of the feature remote inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Figure 109 Overview of the Node B HW CAL concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Figure 110 Iu, Iur, and Iub across a possible ATM network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Figure 111 Node B star configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Figure 112 Node B hub configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Figure 113 Node B cascade configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Figure 114 Node B loop configuration with E1/J1/T1 interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Figure 115 Node B loop configuration with STM-1/OC-3 interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Figure 116 Example for Iub configuration with overbooking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Figure 117 External ATM configuration with IMA dynamic bandwidth adaptation. . . . . . . . . . . . . . . . . . . . . . 192
Figure 118 Example of IMA dynamic bandwidth adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Figure 119 Iur direct connection configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Figure 120 Iur indirect connection configuration (ATM VC switching) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Figure 121 Iur indirect connection configuration (ATM link termination) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Figure 122 Iu connection configuration for a uniform core net architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Figure 123 Iu connection configuration for a split core net architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Figure 124 Iu connection configuration for SMS CBC architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Figure 125 Transmission re-use for UMTS GSM co-location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Figure 126 Concatenation of time slots for UMTS GSM co-location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Figure 127 IMA/CES Application for Abis/Iub Configuration of BTS/RSCU. . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Figure 128 Basic Architecture for UMTS to UMTS TrFO Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Figure 129 Mobile transport network optimization using ATM/multiservice switches . . . . . . . . . . . . . . . . . . . 202
Figure 130 Support of flexible Iu/Iur connections using ATM/multiservice switches . . . . . . . . . . . . . . . . . . . . 202
Figure 131 All Iub Traffic over Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Figure 132 Mixed Traffic over both ATM and Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Figure 133 Node B Co-located with GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Figure 134 Node B hubbing using ATM/multiservice switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Figure 135 RNC optimization using ATM/multiservice switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Figure 136 TDM traffic sharing using ATM/multiservice switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Figure 137 MSC: External Inter-RNC and Inter-PLMN Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Figure 138 MSC: Inter/Intra-Frequency Inter-PLMN Relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Figure 139 MSC: Intra-Frequency Intra-PLMN Relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
11
TED:UTRAN Common
Id:0900d80580103e52
Figure 140 MSC: UMTS-GSM Handover (Part1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Figure 141 MSC: UMTS-GSM Handover (Part2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Figure 142 MSC: GSM-UMTS Handover (Part1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Figure 143 MSC: GSM-UMTS Handover (Part2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Figure 144 MSC: Compressed Mode and GSM Measurement Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Figure 145 MSC: Compressed Mode and GSM Measurement Deactivation . . . . . . . . . . . . . . . . . . . . . . . . . 233
Figure 146 MSC: UMTS Cell (Re-)Selection to/from GPRS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Figure 147 MSC: Soft Handover - Radio Link Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Figure 148 MSC: Soft Handover - Radio Link Deletion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Figure 149 MSC: Softer Handover - Radio Link Addition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Figure 150 MSC: Softer Handover - Radio Link Deletion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Figure 151 MSC: Inter-Frequency Handover (Generic Procedure) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Figure 152 MSC: IMSI Based Handover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Figure 153 MSC: Pre-Emption (Overall Procedure) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Figure 154 MSC: Cell Change Order (Successful Scenario Procedure) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242


12 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580103e52
List of Tables
Table 1 Highlights for world market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Table 2 AS/NAS Division of UMTS Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Table 3 UTRA/FDD Frequency Bands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Table 4 Handover Functions in UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Table 5 Supported Scenarios for SRNC Relocation on Cell_DCH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Table 6 Supported Scenarios for SRNC Relocation on Cell_DCH and HS-DSCH . . . . . . . . . . . . . . . . . . 118
Table 7 Triggers for SRNC Relocation on Cell_FACH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Table 8 FCC Compliant Positioning Accuracies for Emergency Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Table 9 UMTS Bearer Service Attributes for Traffic Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Table 10 Single RAB Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Table 11 Multi-RAB Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Table 12 Supported Signaling Radio Bearers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Table 13 Criteria for the Identification of Early UEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Table 14 Rate Combinations Supported by Early UEs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Table 15 Maximum number of VPs/VCs supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Table 16 Use cases for Node B HW licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Table 17 Applied european directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Table 18 Applicable US legal directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Table 19 Applicable US industrial standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Table 20 Quality standards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Table 21 Telecommunication link interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Table 22 Jitter and wander requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Table 23 Surge (lightning) protection standards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Table 24 Environmental standards for stationary use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Table 25 List of applied norms and standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
13
TED:UTRAN Common Reason for Update
Id:0900d80580118dd4
Reason for Update
Issue History
Details
Issue
Number
Date of Issue Reason for Update
1 02/2007 First issue for new release.
Chapter/Section Reason for Update
All First issue for new release.


14 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dd4
Reason for Update


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
15
TED:UTRAN Common Introduction
Id:0900d80580118dd7
1 Introduction
g This document is prepared as a standard edition that may include descriptions not applying to your system.
Today users expect the same communication services regardless of whether they are sitting in their offices,
staying at home or on the move. The third-generation Universal Mobile Telecommunications System (UMTS) sat-
isfies these user expectations with regard to multimedia services, m-commerce and global mobility.
Siemens and NEC offer a comprehensive and mature product portfolio to meet customer expectations in all
phases of the operation of an UMTS network. The reliable base of this strategy is Siemens extensive GSM expe-
rience and NECs early market entry in Japan. Moreover, Siemens is ahead of the competition having shown
complete UMTS functionality in various pilots on customer premises.
Standard compliance is the key to a multi-vendor environment and guarantees interoperability between different
network components. Siemens and NEC have strongly influenced the standardization of UMTS by 3GPP and
support the maintenance and further development of this project. Their products provide interfaces which are fully
compliant with the 3GPP standard.
With the growing speed of UMTS deployment and upcoming refarming scenarios (i.e. utilization of existing cellular
bands for deployment of UMTS e.g. UMTS@900 MHz) the need for a fast and cost effective deployment of UMTS
is growing.
Siemens existing GSM and GPRS networks can easily be upgraded to the third generation and permit both GSM
and UMTS services simultaneously. Seamless 2G to 3G network communication becomes a reality.


16 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dd7
Introduction
1.1 Brief Description of the Siemens/NEC UTRAN Solution
The UMTS Terrestrial Radio Access Network (UTRAN) consists of Radio Network Controllers (RNCs) and
Node Bs, as standardized by 3GPP.
Node Bs connect the User Equipment (UE) to the UTRAN via the radio interface. In turn, Node Bs link up to an
RNC, see Figure 1. Siemens/NEC FDD (Frequency Division Duplex) Node Bs are most favourable for providing
coverage and a large bundle of services at the beginning of the 3rd generation mobile network operation. The
Node B product portfolio includes macro- and micro-cells in solely 3G networks as well as mixed 3G/2G net-
works. The Siemens/NEC FDD Node B product portfolio supports the global IMT-2000 spectrum as commonly
used in Europe and Asia (including Japan and Korea). For countries where operators with 2G networks already
use this spectrum (such as the PCS band in Northamerica), Siemens/NEC offers solutions to implement 3G
services within the existing bands by replacing part of the spectrum with 3G systems (also known as reframing).
Figure 1 The UMTS Radio Access Network (UTRAN)
The RNC manages the UTRAN in respect of mobility and service quality. It supports a variety of handover mech-
anisms and includes functions to provide best Quality of Service to the users equipment. The Siemens/NEC
RNC can link up with hundreds of Node Bs via dedicated (E1/J1/T1) or multiplexed (STM-1/OC-3) Iub interfaces.
Different RNCs are interconnected through the 3GPP Iur interface.
The UTRAN is connected to the UMTS core network via a high-speed ATM interface (Iu interface). All network
elements and their individual configurations are administered by enhanced network management, which combines
the management of both 3G and 2G networks in one platform.
Siemens/NEC UMTS products are designed to be future-proof from the very beginning. For instance, Node Bs
and the Radio Network Controller can easily be upgraded from the current ATM-based standard to a future end-
to-end network that is entirely IP-based.
to
Network
Core
UTRAN
Iu
Interface
to
Network
Core
UE
Uu
Interface
Iub
Interface
Iub
Interface
Iub
Interface
Node B
Node B
Node B
Iu
Interface
Iur
Interface
RNC
RNC
UE
Uu
Interface
UE
Uu
Interface


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
17
TED:UTRAN Common Introduction
Id:0900d80580118dd7
1.2 Who Should Read the TED:UTRAN
This technical description is intended for anyone who would like to get an overview of:
Benefits of using the UTRAN
Technical capabilities of the UTRAN
1.3 Where to Look for Which Information
Chapter 1 of this manual offers a short introduction to the UTRAN including Customer Benefits, and Overview
of the UTRAN Product Range. and 2G/3G Co-Operation.
Descriptions of the interfaces used and the UTRAN functions are given in UTRAN Description. This is followed
by an overview of the Operation and Maintenance of the UTRAN.
Technical data and hardware architecture of the individual Node Bs and the RNC are described in separate
papers:
TED:UTRAN NB-440/NB-441
TED:UTRAN NB-420
TED:UTRAN NB-341
TED:UTRAN NB-530
TED:UTRAN NB-880/NB-881/NB-881HR
TED:UTRAN NB-860/NB-861
TED:UTRAN RS-880/RRHs
TED:UTRAN RS-381/RRHs
TED:UTRAN RSCU-380/RRHs
TED:UTRAN RSSU-380/RRHs
TED:UTRAN RN-750
UTRA Network Element Configurations summarizes how Node Bs and the RNC can be interconnected.
Data on quality specifications is provided in Quality Standards / Specifications.
The Appendix - Message Sequence Charts provides a collection of message sequence flows illustrating how
mobility of the user equipment is ensured by relocation and handover procedures.
A glossary and a list of abbreviations used in the UTRAN documentation are available as separate documents.


18 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dd7
Introduction
1.4 Customer Benefits
The Siemens/NEC UTRAN solution covers 3rd-generation radio equipment for a mobile communication network
in compliance with 3GPP Rel.5.
Siemens/NECs latest UTRAN release introduces a comprehensive set of new features and functionalities for
enhanced handling of HSDPA traffic and non-HSDPA traffic in a 3G W-CDMA network.
Focusing on the operational aspects of the 3G W-CDMA network, Siemens/NECs latest UTRAN release provides
an extended set of parameters and counters for network tuning, radio resource monitoring and transport network
management.
Based on the leading edge Common Public Radio Interface (CPRI) compliant versatile NB architecture new micro-
/pico-RRHs are available supporting dedicated solutions for indoor and outdoor scenarios including deployment
scenarios of extended RRH distance. The common Radio Commander applications for 2G and 3G introduce
usability improvements for the RC GUI, enhanced diagnostic capabilities and remote data handling.
Siemens/NECs latest UTRAN release provides the means to significantly increase utilization of Iub interface in
order to handle the strongly increasing traffic volume of high speed data services with the introduction of HSDPA
in a very cost efficient way.
With Siemens/NECs latest UTRAN release user/service prioritization and service specific 3G/2G HO is sup-
ported. This enables network operators to apply their service/pricing concept or release resources in case of over-
loaded 3G W-CDMA network.
Table 1 summarizes the highlights of Siemens/NECs latest UTRAN release.
New Features and Services Cost of Ownership Platform and Technology
HSDPA Evolution
HSDPA Mobility
Enhancements
HSDPA Resource and
Power Management
HSDPA Scheduler Evolu-
tion (QoS)
Cell-specific Handover
Parameters
Transport Network Optimization
HSDPA Traffic Separation
and UBR+
IP / Ethernet at Iub (PWE)*
Service & Load Based
Handover
Traffic steering / Load Balanc-
ing
Multistandard Network
2G/3G Basestation Radio
Server @ GSM (RSCU-
380)
2G/3G Radio Commander
RC/OTS
RNCi Rel. 1 (RN-880)
Outdoor Macro Radio Server
(RS-881)
High Power RRH (20W)
Pico RRH-pi
Extended Fiber Length for RRH
(40km)
3 Carriers / Sector
900 MHz
Table 1 Highlights for world market


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
19
TED:UTRAN Common Introduction
Id:0900d80580118dd7
1.5 Operation and Maintenance of UTRAN
The Siemens/NEC Operation & Maintenance Centre (OMC), known as Radio Commander (RC), introduces a new
concept for Mobile Network Element Management. One of its key advantages is its common platform concept,
allowing the management of both 2G and 3G networks on the same operation and maintenance platform.
Given a sufficient configuration, the whole network can be handled by just one RC. Equipment can be easily
grouped for specific OMCs to optimize the structure of the OAM landscape, 2G/3G operators can group all network
equipment for a certain area, regardless of the technology, into one RC.
The combination of Siemens/NEC Radio Commander, RNCs and Node Bs offers a self-contained UMTS solution
with maximum coordination between the individual network elements. As a result, Siemens/NEC UTRAN products
provide a convenient and reliable portfolio of UMTS radio access network elements that is easy for the operator
to handle.
Major new characteristics of the RC architecture for 3G UTRAN include common Operation and Maintenance
management for Node B and for RNC functionalities as well as capabilities for managing the ATM transport
network.
In spite of these specifics, due to the inherent technology characteristics of each technology, the utmost care has
been taken to provide:
Same functionality for all supported radio network technologies
Homogeneous representation to the operator
Common management for GSM and UTRAN equipment consists of the entire range of management functional-
ities, such as starting off from a similar display and handling of both GSM-BSS and UTRAN network alarms, and
extending to homogeneous configuration handling, e.g. display and handling of bi-technology network topologies.
Also covered are features such as common logs for all connected network elements with global search and
retrieval, common state management based on a comfortable maintenance state approach and common fault and
performance management facilities.
Network elements and RCs can be managed in different time zones in a consistent and simple way. For time zone
handling the UTC (Co-ordinated Universal Time) is consequently used and the NTP (Network Time Protocol) is
supported. Consistent denomination of time at GUI, database and files according to national specifics is ensured.
Finally, the RC also provides the unique entry point for data from both the GSM-BSS and UTRAN Radio Networks
and mediates it to an upper-layer Network Management Centre (NMC).


20 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dd7
Introduction
1.6 Overview of the UTRAN Product Range
Siemens/NEC UTRAN products provide a family of macro and micro FDD Node Bs and Radio Servers for area
coverage as well as hotspot cells and a corresponding RNC:
Macro FDD Node B (NB-440/NB-441)
Macro FDD Node B (NB-420)
Micro FDD Node B (NB-341)
Macro FDD Node B (NB-530)
Macro FDD Node B (NB-880/NB-881/NB-881 HR)
Macro FDD Node B (NB-860/NB-861)
Macro Radio Server (RS-880)
19 Micro Radio Server Slider Unit (RSSU-380)
Micro Radio Server Carrier Unit (RSCU-380)
Micro Radio Server (RS-381)
Macro Remote Radio Head (RRH-m/RRH-mh)
Micro/Pico Remote Radio Head (RRH-pi)
Radio Network Controller (RN-750)
Radio Network Controller (RN-880)
All network elements incorporate features for the optimum re-use of the existing 2G infrastructure, such as trans-
mission links, operational procedures, and operation and maintenance interfaces.
Versatile Node B architecture
A versatile Node B architecture is supported based on the DRIC-CAT concept, which enables up-to-date technol-
ogies in linear amplifier research such as digital predistortion. This features a noticeably higher efficiency resulting
in a lower power consumption of the whole Node B. The DRIC-CAT concept replaces the transceiver cards (TRX),
power amplifier (LPA) and repeater card (REP), For an illustration see Figure 54, Figure 55, Figure 56, Figure 57.
The modules DRIC (Digital Radio Interface Card) and CAT (Combined Amplifier and Transceiver) are connected
by a digital high-speed interface called the Common Public Radio Interface (CPRI). Now, sites can be flexibly
planned with configurations using Node B Radio Servers and Remote Radio Heads or the standard Macro or Micro
Node B scenario.
The CPRI interface is a unique radio driven interconnect point in radio base stations, which offers the following
benefits:
Varying Radio Base Station architectures for very flexible solutions,
e.g. distributed architectures and remote tower mounted radio concepts
Additional deployment scenarios
Efficient network deployment
Remote Radio Head (RRH) solutions offer the following benefits:
Feeder loss in the downlink direction is diminished by the short distance between RRH antenna connector and
RRH. The uplink quality is also improved superseding a TMA.
OPEX reduction due to reduced power consumption and optimizations in operation and maintenance
Flexible number of sectors and antenna sites
Easier site acquisition due to reduced requirements for Node B locations (flexible fibre optic cable, longer dis-
tances between Node B/Radio Server and antenna location possible, lower acoustic noise emission for radio
server)
Radio Servers provide the full functionality of Node Bs in conjunction with Remote RRHs. A complete base band
shelf with DC-Panel is mounted into a server rack reducing the acoustic noise emission and the necessary space
for installation. The RF functionality of the Node B is incorporated in a RRH. The RS/RRH configuration represents
a versatile Node B architecture for flexible site planning. RS and RRHs interact via the technology leading
Common Public Radio Interface (CPRI).


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
21
TED:UTRAN Common Introduction
Id:0900d80580118dd7
RS/RRH configurations offer the following benefits:
Flexible number of sectors and antenna sites
Multi-site configuration (with softer HO)
Reduced signaling and transmission costs due to softer HO
Baseband (resource) pooling to reduce CAPEX costs
Feeder loss in the downlink direction is diminished by the short distance between RRH and antenna. The
uplink quality is also improved superseding a TMA.
OPEX reduction due to reduced power consumption and optimizations in operation and maintenance
Easy site acquisition due to reduced requirements Radio Server locations (flexible fiber optic cable, long dis-
tances between Radio Server and antenna location possible, low acoustic noise emission for radio server)
Extended fibre optic length for RRH connections up to 40 km
Operation of several RRHs in chaining configuration due to sharing a common DRIC-CPRI interface (HW-pre-
pared)
Resources can be pooled in a hotelling concept providing maximum RS capacity and RRHs distributed in the
coverage area


22 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dd7
Introduction
1.6.1 Macro FDD Node B (NB-440/NB-441)
The Macro FDD Node B NB-440/NB-441 is specifically designed for the mass roll-out of the UTRAN. This Node B
is based on the 2
nd
-generation platform, providing 3
rd
generation features. It incorporates the latest market
demands derived from start-up experience with UMTS networks.
The Macro Node B NB-440 and its outdoor variant NB-441 feature compactness and flexible expansibility with
modular shelf configurations. This Node B can therefore be configured to meet market requirements from low to
high capacity with minimum impact on installation space.
The NB-440/NB-441 can be upgraded to the DRIC-CAT concept.
g Mixed configurations (DRIC-CAT with REP-TRX-LPA in one Node B) are not possible.
The Node B supports a maximum configuration of 2/2/2 in one rack/shelter. The NB-440/NB-441 is a fully self-
contained Node B including any provision for quick and easy outdoor deployment.
Figure 2 NB-440 indoor cabinet and NB-441 outdoor cabinet (base rack/shelter, REP-TRX-LPA concept)
Key features of the NB-440/NB-441 include:
Radio cell configuration: up to 2/2/2
Baseband capacity: up to 960 CE
High power: up to 20 W per carrier
RX diversity (strongly recommended)
HSDPA, see FD012249 Support of HSDPA
The NB-440/NB-441 can be upgraded to support the following features:
Radio cell configuration: up to 4/4/4
Output power: 40 W per cell (CAT40/ngCAT)
Macro Remote Radio Head (RRH-m/RRH-mh)
TX diversity
For a detailed description please see TED:UTRAN NB-440/NB-441.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
23
TED:UTRAN Common Introduction
Id:0900d80580118dd7
1.6.2 Macro FDD Node B (NB-420)
The indoor Macro FDD Node B NB-420 provides macro capacity in micro-sized housing (<245 l). The NB-420 and
the NB-440/NB-441 use the same base band and RF modules, which simplifies distribution of spare parts and
training of the maintenance staff if both Node B variants are used in the same network.
The NB-420 can be upgraded to the DRIC-CAT concept. For a detailed description please see TED:UTRAN NB-
420.
g Mixed configurations (DRIC-CAT with REP-TRX-LPA in one Node B) are not possible.
The NB-420 can be combined with a 6-carrier Siemens BTS for a UTRAN-FDD and GSM/DCS co-location solu-
tion. Furthermore, two NB-420s can be combined for site-sharing purposes.
Figure 3 NB-420 indoor cabinet (REP-TRX-LPA concept)
Key features of the NB-420 include:
Radio cell configuration: 1/1/1
Baseband capacity: up to 384 CE
High power: up to 20 W per carrier
RX diversity (strongly recommended)
HSDPA, see FD012249 Support of HSDPA
The NB-420 can be upgraded to support the following features:
Radio cell configuration: 2/2/2
Macro Remote Radio Head (RRH-m/RRH-mh)
Future CAT developments (e.g. ngCAT for higher power efficiency)
For a detailed description please see TED:UTRAN NB-420.


24 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dd7
Introduction
1.6.3 Micro FDD Node B (NB-341)
The outdoor MicroFDD Node B NB-341 is a smart and easy-to handle 1-carrier solution with a light weight and
small dimensions, with all modules integrated within one housing. It is designed for hierarchical cell structures,
hotspot areas, e.g., office buildings and entrance halls (e.g., inside advertising pillars), blackspot coverage (out-
door), underground locations, railways and highways. The NB-341 can be quickly and easily installed on indoor
and outdoor sites (e.g., on walls and poles), requiring no footprint. Because of its low-noise convection cooling and
low maintenance needs, it can operate in areas that require silence or where maintenance tasks are difficult to
perform (e.g., in hidden places in old towns). A variable power supply enables operation at almost all sites. Due
to the low output power (0.5 W), a government permission is not necessary in many countries. A booster for higher
output power demands is optionally available to increase the cell size and/or the capacity.
Figure 4 NB-341 outdoor cabinet
Key features of the NB-341 include:
Radio cell configuration: 1/0/0
Baseband capacity: up to 96 CE
High power: extended coverage with a 10 W booster
RX diversity (strongly recommended)
HSDPA, see FD012249 Support of HSDPA
Weight: less than 30 kg, W x D x H: 425 x 200 x 500 mm
For a detailed description please see TED:UTRAN NB-341.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
25
TED:UTRAN Common Introduction
Id:0900d80580118dd7
1.6.4 Macro FDD Node B (NB-530)
The Macro FDD Node B NB-530 is a well-established solution for the speedy introduction of UMTS. It benefits from
the experience gained from numerous trial systems all over the world. The NB-530 handles up to 480 AMR voice
channels, which can be flexibly combined for higher data rate bearer. Thus, this Node B is suitable for both area
deployments aiming for coverage and city deployments requiring capacity.
Figure 5 NB-530
Key features of the NB-530 include:
Radio cell configuration: up to 2/2/2
Baseband capacity: up to 480 CE
High power: up to 20 W per carrier
RX diversity and TX diversity (optional)
Core and base-band redundancy
For a detailed description please see TED:UTRAN NB-530.


26 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dd7
Introduction
1.6.5 Macro FDD Node B (NB-880/NB-881/NB-881 HR)
The Macro FDD Node B NB-880/NB-881/NB-881 HR is specifically designed to satisfy the real-world demands of
UTRAN operators. This Node B provides 3
rd
-generation functionality and incorporates economic-driven innova-
tions for todays UMTS networks.
The Macro Node B NB-880 and its outdoor variant NB-881 feature compactness and flexible expandability with
modular shelf configurations. This Node B can therefore be configured to meet market requirements from low to
high capacity with minimum impact on installation space. It is also backward-compatible with widespread NB-
440/NB-441 modules and designed to support the NB-440/NB-441 feature set. NB-881 HR is a height reduced
variant of NB-881. It has the same functionality and the same modules of NB-881, but it was rearranged in order
to span a lower height.
The NB-880/NB-881/NB-881 HR uses the DRIC-CAT concept. For a detailed description see TED:UTRAN NB-
880/NB-881/NB-881HR.
The Node B supports a maximum configuration of 3/3/3 in one rack/shelter.The NB-881 is a fully self-contained
Node B including any provision for quick and easy outdoor deployment. The highly-integrated cards/modules/com-
ponents (especially CHC96 and the DRIC and CAT modules) noticeably reduce the system complexity.
Figure 6 NB-880 indoor cabinet and NB-881 base frame


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
27
TED:UTRAN Common Introduction
Id:0900d80580118dd7
Figure 7 NB-881HR
Key features of the NB-880/NB-881/NB-881 HR include:
Radio cell configuration: up to 3/3/3 (CAT), 2/2/2,1/1/1 (mixed CAT-RRH), 1/1/1/1 (RRH-mh)
High power with RRHs: up to 12.5 W per RRH-m, up to 20 W per RRH-mh
Baseband capacity: up to 960 CE using 10 CHCs
Macro Remote Radio Head (RRH-m/RRH-mh)
HSDPA, see FD012249 Support of HSDPA
RX diversity supported by RRHs (strongly recommended)
Full functionality for 3 RF operation
Next generation CAT (ngCAT)
Support of UMTS900 (CAT900 + DUAMCO900)
The NB-880/NB-881/NB-881 HR is already HW-prepared for the following features:
Radio cell configuration: 4/4/4 (CAT)
High power: up to 40 W per sector/40 W per cell with TX-diversity
TX diversity
Future CHC developments
HSUPA
Operation with Smart Antennas
RRH chaining
For a detailed description please see TED:UTRAN NB-880/NB-881/NB-881HR.


28 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dd7
Introduction
1.6.6 Macro FDD Node B (NB-860/NB-861)
The Macro FDD Node B NB-860 provides macro capacity in micro-sized housing (<245 l). The NB-860 and the
NB-880/NB-881 use the same base band and RF modules, which simplifies distribution of spare parts and training
of the maintenance staff if both Node B variants are used in the same network.
The outdoor NB-861 is a UMTS macro base station, providing 3rd generation features of the Node B HW-platform.
It supports the complete configuration set of the NB-860 and covers the requirements according the fast roll-out
of the UMTS network.
The NB-860/NB-861 uses the DRIC-CAT concept. For a detailed description please see TED:UTRAN NB-
860/NB-861.
The NB-860 can be combined with a 6-carrier Siemens BTS for a UTRAN-FDD and GSM/DCS co-location solu-
tion. Furthermore, two NB-860s can be combined for site-sharing purposes.
The outdoor variant NB-861 provides an extendable battery backup time in combination with service shelters of
GSM BS-241.
The Macro Node B NB-860/NB-861 features compactness and flexible expandability with modular shelf configu-
rations.
Figure 8 NB-860 indoor cabinet and NB-861 base frame


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
29
TED:UTRAN Common Introduction
Id:0900d80580118dd7
Key features of the NB-860/NB-861 include:
Radio cell configuration: up to 2/2/2 or 1/1/1/1 (RRH)
Baseband capacity: up to 384/480 CE (NB-860/NB-861) using 4/5 CHCs
High power with RRHs: up to 12.5 W per RRH-m, up to 20 W per RRH-mh
Macro Remote Radio Head (RRH-m/RRH-mh)
RX diversity supported by RRHs (strongly recommended)
HSDPA
Next generation CAT (ngCAT)
For a detailed description please see TED:UTRAN NB-860/NB-861.


30 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dd7
Introduction
1.6.7 Macro Radio Server (RS-880)
The Macro Radio Server RS-880 provides the full functionality of the NB-880 in conjunction with Remote Radio
Heads (RRHs). A complete base band shelf with DC-Panel is mounted into a server rack reducing the acoustic
noise emission and the necessary space for installation.
The Radio Server RS-880 features compactness and flexible expandability with modular shelf configurations. This
Radio Server can therefore be configured to meet market requirements from low to high capacity with minimum
impact on installation space. The highly-integrated cards/modules/components (especially CHC96 and the DRIC
modules) noticeably reduce the system complexity.
Figure 9 Radio Server RS-880
Key features of the RS-880 RRHs include:
Radio cell configuration: up to 2/2/2 or 1/1/1/1/1/1 (RRH)
Baseband capacity: up to 960 CEs using 10 CHCs
High power with RRHs: up to 12.5 W per RRH-m, up to 20 W per RRH-mh, up to 0.5 W per RRH-pi
Macro Remote Radio Head (RRH-m/RRH-mh)
Pico Remote Radio Head (RRH-pi)
RX diversity supported by RRHs (strongly recommended)
TX diversity (HW-prepared, optional)
HSDPA, see FD012249 Support of HSDPA
For a detailed description please see TED:UTRAN RS-880/RRHs.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
31
TED:UTRAN Common Introduction
Id:0900d80580118dd7
1.6.8 19 Micro Radio Server Slider Unit (RSSU-380)
The Radio Server Slider Unit is a low cost and zero footprint scenario for operators who want to upgrade their
existing GSM equipment to UMTS. The RSSU-380 is a 19 module with a height of 3 HU which can be mounted
into an already existing GSM service rack by a minimum installation procedure. The RSSU-380 is based on the
RS-880 technology, sharing the following modules:
1 CC3
up to 2 CHC96
1 DRIC24_24oe
The Radio Server RSSU-380 provides medium capacity in conjunction with Remote Radio Heads (RRHs). The
RF functionality of the Node B is incorporated in a Remote Radio Head (RRH). The RS/RRH configuration repre-
sents a versatile Node B architecture for flexible site planning. RS and RRHs interact via the technology leading
Common Public Radio Interface (CPRI). Now, sites can be flexibly planned with Remote Radio Heads (RRH).
Figure 10 Radio Server Slider Unit RSSU-380
Key features of the RSSU-380 include:
Radio cell configuration: up to 1/1/1/1 or 2/0/0 (RRH)
Baseband capacity: up to 192 CEs using 2 CHCs
High power with RRHs: up to 12.5 W per RRH-m, up to 20 W per RRH-mh, up to 0.5 W per RRH-pi
Macro Remote Radio Head (RRH-m/RRH-mh)
Pico Remote Radio Head (RRH-pi, HW-prepared)
Low weight (< 15 kg)
RX diversity supported by RRHs (strongly recommended)
HSDPA, see FD012249 Support of HSDPA
For a detailed description please see TED:UTRAN RSSU-380/RRHs.


32 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dd7
Introduction
1.6.9 Micro Radio Server Carrier Unit (RSCU-380)
The Radio Server Carrier Unit provides an effective solution for operators which want to upgrade their existing
GSM equipment to UMTS without additional installation cost and a minimum installation procedure.
The RSCU-380 is a compact radio server unit for small to medium traffic which can be mounted into an already
existing GSM BTS (BS240, BS241, and BS240XL) occupying 2 CU slots.
The RSCU-380 is based on the RSSU-380 technology, comprising the following modules:
Mechatronics cage for UMTS modules
1 CC3
Up to 2 CHC96
1 DRIC24_24oe
Optional: 1 COREXT-R and 1 GSM OVPT
The RSCU-380 delivers the complete UMTS baseband functionality needed for a NodeB. The radio part is con-
nected via the CPRI-interface to the RSCU-380.
Figure 11 Radio Server Carrier Unit RSCU-380
Key features of the RSCU-380 with RRHs include:
Radio cell configuration: up to 1/1/1/1 or 2/0/0 (RRH)
Baseband capacity: up to 192 CEs using 2 CHCs
High power with RRHs: up to 12.5 W per RRH-m
Macro Remote Radio Head (RRH-m)
Pico Remote Radio Head (RRH-pi, HW-prepared)
Low weight (< 15 kg)
RX diversity supported by RRHs (strongly recommended)
HSDPA, see FD012249 Support of HSDPA
For a detailed description please see TED:UTRAN RSCU-380/RRHs.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
33
TED:UTRAN Common Introduction
Id:0900d80580118dd7
1.6.10 Micro Radio Server (RS-381)
The Radio Server RS-381 provides medium capacity in conjunction with Remote Radio Heads (RRHs). The RF
functionality of the Node B is incorporated in a Remote Radio Head (RRH). The RS/RRH configuration represents
a versatile Node B architecture for flexible site planning. RS and RRHs interact via the technology leading
Common Public Radio Interface (CPRI). Now, sites can be flexibly planned with Remote Radio Heads (RRH).
The outdoor Radio Server RS-381 also contains the baseband part of the NB-88x product line with same following
modules: Core Controller (CC), Channel Coding Card (CHC) and Digital Radio Interface Card (DRIC). It operates
with the macro Remote Radio Heads (RRH-m, RRH-mh) and micro and pico Remote Radio Heads (RRM-pi).
The RS-381 is a solution for requirements of small to medium capacity and for zero footprint locations. Therefore
it can be wall or pole mounted.
The power supply of the RS-381 can either be:
an AC-variant, feeding up to one RRH-m (optional backup battery available)
or
a DC-variant, where power may be provided by PSR (Power Supply Remote Radio Headt). The PSR performs
an AC/CD conversion and enables a battery backup time up to 1 h.
Figure 12 Radio Server RS-381
Key features of the RS-381 include:
Radio configuration: up to 2/0/0 (RRH-m/RRH-mh) or 1/1/1/1/1/1 (RRH-pi)
Baseband capacity: up to 192 CE using 2 CHCs
High power with RRHs: up to 12.5 W per RRH-m, up to 20 W per RRH-mh, up to 0.5 W per RRH-pi
Macro Remote Radio Head (RRH-m/RRH-mh)
Pico Remote Radio Head (RRH-pi)
RX diversity supported by RRHs (strongly recommended)
HSDPA, see FD012249 Support of HSDPA
For a detailed description please see TED:UTRAN RS-381/RRHs.


34 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dd7
Introduction
1.6.11 Macro Remote Radio Head (RRH-m/RRH-mh)
The macro Remote Radio Head (RRH-m) and its high power variant (RRH-mh) are outdoor units outside the
Node B/Radio Server representing a highly integrated future proven solution for RF functionality. Compared to the
RRH-m, the RRH-mh provides higher output power and acoustic noise level as well as increased DC power
cosumption.
The RRH-m and RRH-mh are fully compatible with the classic Node B architecture. They comprise the complete
RF functionality of one Node B/Radio Server sector in one unit. Their functionality is equal to the three modules
CAT, DUAMCO and TMARET.
The RRH-m and RRH-mh are placed between the Node B/Radio Server and two antennas. It provides two CPRI-
compliant optical interfaces for connection to the DRIC. This requires a DRIC of type DRIC24_24OE which
supports an optical interface in addition to the electrical one. The RRH-m and RRH-mh are controlled and moni-
tored by the CC via the CPRI interface.
Figure 13 Macro Remote Radio Head
The RRH-m/RRH-mh offers the following features:
Medium to high capacity
High mobility
One RRH serves one sector
RET functionality is supported
External alarms are supported
Up to 3 RF carriers for operation within a bandwidth of 15 MHz
RX-diversity
High scalability and upgradeability
(support of Remote Radio Heads, mixing of RRH and CAT in NB-880/NB-881)
CPRI 2.0 and DRIC-RRH HW IF CPRI compliance
HSDPA support
HSUPA support (HW-prepared)
TX-diversity using 2 RRHs per sector (HW-prepared)
CPRI cascading (HW-prepared)
The RRH-m/RRH-mh can be installed outside the Node B/Radio Server in the following ways:
Pole mounting, below or behind antenna
Wall mounting
Roof top
The RRH-m/RRH-mh allows the following operation modes:
Single carrier mode with 12.5 W per cell (RRH-m) and with 20 W per cell (RRH-mh)
Dual carrier mode with 10 W per cell (RRH-mh)
For a detailed description please see TED:UTRAN RS-880/RRHs, TED:UTRAN RSSU-380/RRHs,
TED:UTRAN RSCU-380/RRHs, and TED:UTRAN RS-381/RRHs.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
35
TED:UTRAN Common Introduction
Id:0900d80580118dd7
1.6.12 Micro/Pico Remote Radio Head (RRH-pi)
The RRH-pi is an indoor unit outside the Node B/Radio Server, which approximates the functionality of the CAT
with reduced power and one DUAMCO with external or integrated antennas. The RRH-pi provides two CPRI com-
pliant optical DRIF interfaces for connections to the DRIC or other RRH-pi and is controlled via the DRIF interface
by the CC.
The RRH-pi offers the following features:
Single sector, single carrier mode with 0.5 W per cell
Indoor usage
Wall or pole mounting possible
Optional integrated antennas
Support of remote RF update
RX-diversity
Compliant to medium range and local area base station
Figure 14 Micro/Pico Remote Radio Head
The RRH-pi enables configurations with up to 6 RRH-pi. Two optical connectors are supported by the RRH-pi:
The multi-mode 850 nm optical transceivers (500 m separation)
The single mode 1300 nm optical transceiver (10 km separation)
For a detailed description please see TED:UTRAN RS-880/RRHs, TED:UTRAN RSSU-380/RRHs,
TED:UTRAN RSCU-380/RRHs, and TED:UTRAN RS-381/RRHs.


36 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dd7
Introduction
1.6.13 Radio Network Controller (RN-750)
The Radio Network Controller (RNC) covers the following main functions of an UTRAN network:
Mobility management
Call processing
Radio resource management
Link maintenance
Hand-over control
Traffic concentration
Support of mobile services (e.g location based services)
The RNC (RN-750) uses a high-capacity ATM switching platform which supports up to 512 Node Bs at a single
RNC. Due to its modular and highly scalable architecture, the RN-750 is suitable for a smart, well-adapted migra-
tion from initially low-density to later highly loaded networks.
Figure 15 RN-750
The RN-750 offers the following key features:
High stability due to early field experience (1998)
Simple configuration by means of dedicated RNC configurations (model units) for all customer needs regard-
ing connectivity, throughput and interfaces
High flexibility in terms of processing power and number and type of interfaces
Modularity, due to a distributed architecture based both on a scalable ATM switching node and a standardized
network management interface
Designed to support FDD mode
High availability and reliability due to redundant RNC architecture:
dedicated redundancy concept for all HW modules (optional N+1 or 1+1)
Support of high Node B connectivity together with optimized voice/data throughput for low traffic demand (cov-
erage-driven scenario)
Independent voice/data capacity extensions according to traffic and service demand
Voice capacity extension (1.500 Erlang)
Data throughput extension (40 Mbps)


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
37
TED:UTRAN Common Introduction
Id:0900d80580118dd7
Outstanding scalability with respect to Node B connectivity and voice/data throughput from small to very large
values
Voice capacity:
up to 10000 Erlang
Throughput capacity:
up to 1200 Mbps (mixed traffic)
up to 600 Mbps (packet-oriented traffic)
External interfaces:
up to 32 STM-1/OC-3
up to 512 E1
Node B connectivity:
up to 512 Node Bs
For a detailed description please see TED:UTRAN RN-750.


38 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dd7
Introduction
1.6.14 Radio Network Controller (RN-880)
The Radio Network Controller (RNC) is the central network element in the UMTS Radio Access Network (UTRAN)
responsible for mobility management, call processing, radio resource management, link maintenance and
handover control. The RNCi (RN-880) is a trend setting world market product, that is highly innovative, software
defined, and best suited for current ATM/SDH based UTRAN infrastructure and future distributed IP based Radio
Access Networks.
Figure 16 RNCi (RN-880)
Innovative Server Blade Architecture
The RNCi is based on a superior state-of-the-art server blade architecture providing a dramatic improvement in
terms of both flexibility and processing capacity combined with optimized footprint. The modular, highly scalable,
and reliable architecture is characterized by the following:
Based on next generation telecommunication platform using
Server blades
ATCA (Advanced Telecommunication Computing Architecture) standard
World leading performance density
Optimized reliability/availability, best suited for radio applications
Logical separation of control, user and transport plane
Completely independent scalability
Intra shelf, inter shelf/rack communication via Gigabit Ethernet (GE) switches
ATM and IP capable


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
39
TED:UTRAN Common Introduction
Id:0900d80580118dd7
Key Values
The RNCi offers the following key values:
Revenue increase
Support of HSDPA
CAPEX savings
On demand allocation of installed capacity to voice or data traffic
(service independent throughput guarantees utmost flexibility)
Support of asymmetrical configurations (up-, downlink)
Support of very small configurations (1 shelf)
Outstanding scalability to very high performance (2 rack / 6 shelves)
CS/PO scalability by using the same blades for CS and PO services
Reasonable upgrade steps (pay-as-you-grow) by SW licensing and adding further boards
OPEX savings
Footprint reduction by 75% compared to eRNC
Significant reduction of power dissipation
Simplified operations and maintenance concept
Investment protection
Seamless deployment in existing UTRAN networks
Already prepared for future IP based RAN architecture (logical separation into control, user and transport
plane)
RNCi Roadmap
The RNCi will be introduced in two releases with the following highlights:
Release 1 (supporting 3GPP Rel5)
HSDPA
Support of all CS and PO traffic classes
ATM based Iub, Iur and Iu interfaces
IP based Iub, Iur and Iu via external converter
On demand allocation of capacity to voice or data
Release 2 (supporting 3GPP Rel6)
HSUPA
Support of non-real time ATM traffic classes
IP based Iub, Iur and Iu
Physical separation of control and user plane
Supported Services and Applications
The RNCi provides future-proof support of services which are attractive for both operators and end-users. The
RNCi is particularly suitable for applications with high requirements to data transfer volume or Quality of Service
such as:
Video streaming
Audio streaming
Real-time gaming
Multiple sessions (Multiple PDP contexts)
High Speed Data Package Access (HSDPA)


40 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dd7
Introduction
1.7 2G/3G Co-Operation
Nearly all operators doing 3G today are also operating 2G networks. UMTS is no longer considered as a separated
system with its own radio infrastructure and backhaul. Therefore, economical approaches are needed for deploy-
ing and operating the networks. A significant lever for reducing expenses is to use synergies between the installed
2G base and the new 3G equipment. One approach is the joint use of a site/mast, a Node B, or the Core Network
realized by the following main concepts:
Site Sharing
Civil works like equipment rooms or towers for different operators or different radio standards are reused.
Antenna Sharing
Existing antennas and feeders are reused.
Equipment Sharing
Common UMTS equipment (e.g. shelves and RF modules) is used between different operators.
Refarming
The GSM frequency spectrum for UMTS (e.g. 900 MHz frequencies) is used.
The Siemens/NEC UTRAN solution provides various opportunities for speedy and efficient deployment of a UMTS
network. For example, a site/mast for the Macro Node B NB-860 can be used more efficiently by combining it
with a BTS to a co-location solution
with a second NB-860 to a site sharing solution
For a detailed description see TED:UTRAN NB-860.
Transmission re-use for UMTS GSM Co-location (see also UMTS/GSM Co-Location Configuration) is realized
by two ways which are mutually exclusive:
Circuit Emulation Service (CES)
Fractional ATM (FRAC)
A more elaborate way of equipment sharing is the sharing of one Node B between two operators.
The Node Bs and Radio Servers are prepared to support this feature.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
41
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
2 UTRAN Description
The Siemens/NEC product portfolio comprises the full range of devices and solutions to satisfy the customers
needs when using UMTS:
UTRAN (UMTS Terrestrial Radio Access Network)
3G core networks
Transmission
Intelligent network services
Application platforms and software
Customer care and billing
This combination of products and solutions allows network operators to implement first-class 3G services on reli-
able, future-oriented and cost-effective platforms. It is possible to integrate UMTS, GSM and GPRS functionality
in the same network elements, such as the Core Network (CN) and the Telecommunications Management
Network (TMN). Roaming and handover between GSM, GPRS and UMTS are supported within the same
operator network.
A global broadband mobile communication standard has been designed with UMTS. Wideband Code Division
Multiple Access (WCDMA) is widely used as the air interface. UMTS supports services that provide data transfer
of up to 14.4 Mbps.
This chapter gives an overview of the UMTS Network and the position of the UTRAN in this network. Furthermore,
it provides short descriptions of the interfaces and the UTRAN functions.
2.1 The UMTS Network
The Universal Mobile Telecommunication System (UMTS) is a global broadband third- generation (3G) mobile
standard for a Public Land Mobile Network (PLMN) designed by 3GPP (3G Partnership Project).
This section gives an overview of the PLMN subsystems and shows the position of Node B and the RNC in this
system.


42 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
2.1.1 The UMTS PLMN Subsystems
UMTS implements a Public Land Mobile Network (PLMN). Figure 17 shows the subsystems of the UMTS public
land mobile network and their system units.
Figure 17 Subsystems of the PLMN and their Network Elements
The following sections summarize the subsystems of the PLMN. For an overall description, see also the System
Description UMTS Network System Concept.
UMTS User Equipment (UE)
The UMTS-UE provides user access to network services by supporting all the operating functions for subscribers.
UMTS Terrestrial Radio Access Network (UTRAN)
The UTRAN consists of one or more Radio Network Subsystems (RNS):
Radio Network Subsystem (RNS)
The RNS provides all the transmission and control functions that are necessary for radio coverage of the
service area. It includes
one or more base transceiver stations (Node Bs), distributed throughout the entire service area
the Radio Network Controller (RNC) to which Node Bs are connected
UMTS-UE
Radio Network Subsystem
(RNS)
UMTS user equipment
(UMTS-UE)
Radio Access Network (RAN)
UMTS radio interface
UMTS
SC
RC
Packet-switched Circuit-switched
Management
System (UMS)
Other networks
Core Network (CN)
X.25,
X.25,
GS interface
domain domain
Node B
RNC
GMSC
PSTN/ISDN
PLMN
3G MSC
GGSN
Packet data
networks
3G SGSN
TCP/IP
TCP/IP


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
43
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Core Network (CN)
The CN consists of a
Circuit-switched domain
The circuit-switched domain provides all circuit-switching functions for the UMTS PLMN, those specific to
mobile radio as well as those necessary for the fixed network. The circuit-switching functions are required for
independent operation of the UMTS PLMN
operation of the UMTS PLMN in conjunction with a fixed network (PSTN/ISDN)
another circuit-switched PLMN
The circuit-switched domain can also manage complex databases (subscriber data, network data) and handle
the various signaling protocols used for establishing and clearing down connections.
Packet-switched domain
The packet-switched domain provides all packet-switching functions for UMTS PLMN, those specific to
mobile radio as well as those necessary for the fixed network. The packet-switching functions are required for
independent operation of the UMTS PLMN
operation of the UMTS in conjunction with a fixed network (Internet)
another packet-switched PLMN
The packet-switched domain can also manage complex databases (network data) and handle the various sig-
naling protocols used for establishing and clearing down connections.
UMTS Management System (UMS)
The UMS provides all functions relevant for remote and local operation of the UMTS network and for recording
information about the performance of the UMTS system.
The UMS requires
Processing, memory and supervision equipment at a central location
Switch Commander (SC) or Radio Commander (RC)
Other local operation and maintenance equipment, either fixed or portable
The SC or RC represents the element management level. It may be complemented by a network management
level and a service management level.
2.1.2 Layers and Protocols
The UMTS network consists of two independent service layers, the Access Stratum (AS) and the Non-Access
Stratum (NAS), which correspond to the logical division of functions within the network.


44 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Figure 18 Layers and Protocols within AS and NAS
The Access Stratum comprises all functions relating to the access network of UMTS, which is, in compliance with
the 3GPP specifications, completely integrated in this layer. As shown in Figure 18 it also comprises a part of the
UE (the one, which manages the protocols of the radio interface) as well as a part of the CN (the Iu interface).
The Non-Access Stratum comprises all other functions of the UMTS network that are independent of the access
network, such as functions for:
Connection establishment, which correspond to the protocol layers CC (Call Control) for CS calls and SM
(Session Management) for PS services
Mobility management in standby mode, which correspond to the layer protocols MM (Mobility Management)
in CS mode and GMM (GPRS Mobility Management) in PS mode
Table 2 shows the division of UMTS functions to the separate layers.
UMTS functions Access Stratum Non-Access Stratum
Call Processing x
Authentication x
Handover x
Management of additional services x
Management of radio channels x
Ciphering x (x)
Compression x (x)
Billing functions x
Table 2 AS/NAS Division of UMTS Functions
R
a
d
i
o

p
r
o
t
o
c
o
l
s
R
a
d
i
o

p
r
o
t
o
c
o
l
s
I
u

p
r
o
t
o
c
o
l
s
I
u

p
r
o
t
o
c
o
l
s
Access Stratum
UTRAN CN UE
Radio
(Uu)
Iu
MM, CC, GMM, SM
Non-Access Stratum
GC Nt DC
GC Nt DC


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
45
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
The UMTS functions ciphering and compression are represented in both layers. In the standard they are described
as part of the Access Stratum, but they can alternatively belong to the Non-Access Stratum (in the table marked
in brackets).
The Access Stratum acts as a service provider for the Non-Access Stratum. A number of connections, so-called
Service Access Points (SAPs), are specified between the AS layers and the NAS layers in the UE and in the CN.
These SAPs allow for the classification of interactions between NAS and AS depending on the type of services
offered or requested. There are three such access points:
GC (General Control)
Nt (Notification)
DC (Dedicated Control)
For further details, please see section Network Layer (L3).
2.1.3 The Radio Network Subsystem
The RNS is divided into an intelligent, centralized controller part and several transceiver stations, see Figure 19:
One Radio Network Controller (RNC)
One or more base transceiver stations (Node Bs)
This structure is well adapted to both small-cell networks, as preferably used in urban areas, and large-cell rural
networks. The advantage of small-cell networks is the internal handover offered by the RNCs, the advantage of
large-cell networks is the coverage of large areas by Node Bs. With respect to operation and maintenance the
RNC is completely transparent on a logical level. For detailed information see Operation and Maintenance of the
UTRAN.
Figure 19 The Radio Network Subsystem (RNS)
RNC
Iu
Uu
Iub
Iub
Uu
3G MSC
RC
RNS
3G SGSN
Iur other
RNC
Itf-R
Itf-B
Itf-B
The RNC is compIeteIy transparent for Itf-B on IogicaI IeveI
CBC
/PEF#
/PEF#


46 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Base transceiver station (Node B)
Node B is a logical node and responsible for the radio transmission to the User Equipment (UE) and the radio
reception from the UE. Each Node B can serve a variable number of radio cells (e.g. a 2/2/2 configuration means
to support 6 cells). Node Bs are distributed throughout the entire radio service area. Each RNC supports at least
one Node B, though generally more Node Bs are supported. Node B terminates the Iub interface towards the
RNC.
Radio Network Controller (RNC)
The RNC controls Node B and is responsible for core processing in the UTRAN. The RNCs can be physically
grouped together at a central point on 3G-MSC or 3G-SGSN sites or remotely in a shelter or in a confined space.
Any physical RNC normally contains the functionality to act in different logical roles (see Figure 20):
Controlling RNC (CRNC):
The CRNC is responsible for the radio resources of its own cells.
Serving RNC (SRNC):
The SRNC handles the connection to one UE, and may borrow radio resources of a certain cell from the
CRNC.
Drift RNC (DRNC):
The DRNC is any RNC, other than the SRNC, that controls cells used by the UE.
Figure 20 Logical Roles of the RNC
Iub
Iub
Iu
Iur
Iu
SRNC
DRNC
CRNC
CRNC
/PEF#
/PEF#
Core
Network
6&


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
47
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
2.1.4 Area Concepts
Figure 21 shows the UE registration and connection principles within the UMTS.
Figure 21 UE Registration and Connection Setup for 3G MSC and 3G SGSN
Mobility management (MM) can be divided into the following functions:
Update of the UE location in the CS or PS domain
establish or delete an MM context for a UE in the network node
Page and search
Update the subscriber database
Protect against unauthorized service usage, e.g. authentication and service request validation, ciphering
Subscriber data delivered from the home location register (HLR) and mobility data delivered by MM functions are
temporarily stored in the visitor location register (VLR, CS domain) or the subscriber location register (SLR, PS
domain). The HLR contains data on subscription restrictions, services assigned to the mobile subscribers, and the
current subscriber status including information on the current location.
Figure 22 shows the connection of UEs and MSs to the core network and the mobility management.
UE
PS state CS state
UTRAN
CS state
3G MSC/VLR
CS service domain
PS state
3G SGSN/SLR
PS service domain
CS Iocation PS Iocation
HLR
Common
Two CN service domains
subscription
database
Two Iu signaIing connections
UTRAN with
distribution
functionaIity
One RRC connection


48 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Figure 22 Connection of UEs and MSs to CN and Mobility Management
Location areas and routing areas
For locating a subscriber, the network is divided into
location areas for CS services
routing areas for PS services
The location area or routing area is used, for example, during CN-initiated paging. A temporary identity is assigned
to the UE. This identity is unique within a location area or routing area.
The mapping between location area and RNC is handled within the MSC/VLR to which the location area is
assigned. The mapping between routing area and RNC is handled within the SGSN/SLR that owns this routing
area. The RNC handles the mapping between location area and cells and between routing areas and cells, see
Figure 23.
Figure 23 Area Concepts (Cells Are not Shown)
In addition, UTRAN registration areas and service areas are defined.
For a detailed description of the area concepts and the relationships between them, please see OMN:RN-750
Radio Network Configuration Basics.
Uu
RNS
SGSN/SLR
2G/3G
GGSN PDN
Um
BSS
MSC/VLR
2G/3G
GMSC PSTN
HLR
3G
2G
A
Iu
Iu
Gb
CS
PS
MS
UE
LA RA URA
LA1 LA2 LA3
RA1 RA2 RA3 RA4 RA5
RA handIed by one 3G SGSN
LA handIed by one 3G MSC/VLR


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
49
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Location area update and routing area update
A UE invokes a location area update procedure via the 3G-MSC if it changes the location area or if a certain timer
has expired. If a new location area is in an area served by another CN node, the location area update also triggers
the registration of the subscriber in the new CN node and a location update for CS services towards the HLR.
For a detailed description of Location Area Update and Routing Area Update procedure, please see OMN:RN-
750 Radio Network Configuration Basics.
UE service states and RRC connection states
Two service states are carried out irrespective of whether the PS and/or CS service is used. For both CS and PS
there are three different states:
DETACHED
IDLE
CONNECTED
The respective RRC connection sets are saved in the RNC.
For a detailed description of UE Service States and RRC Connection States, please see OMN:RN-750 Radio
Network Configuration Basics.
Paging
Paging information is transmitted to an individual UE in Idle mode using the paging control channel (PCCH). A
paging message to the RNC contains the paging area ID parameters, i.e. the information on the area in which the
paging message is to be broadcast. The location area or routing area is taken from a cell identifier list. If a UMTS
cell is paged, the cell identifier list contains only one dummy cell from which to derive the location area. The RNC
itself creates the list of cells to be paged in. Paging is completely independent for CS and PS services.
For a detailed description of the paging procedure, please see OMN:RN-750 Radio Network Configuration
Basics.
Location services
Location services (LCS) allow the geographical location of a UE to be determined. This information may be
requested by the UE itself or by a client within or attached to the CN. Location services are the basis for new
services such as:
Localized advertising, tracking services (e.g. fleet management), navigation
Location-dependent billing
Enhanced support of emergency calls (e.g. E.911) by determining the originators location
Support of legally required or sanctioned services such as lawful intercept


50 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
2.2 Interfaces
The Network Elements (NEs) within UMTS are connected via defined logical and physical interfaces based on
WCDMA and ATM.
Figure 24 and Figure 25 show the adopted interfaces between the User Equipment (UE) and the Radio Network
Subsystem (RNS), within the RNS, as well as between the RNS and the Core Network (CN).
For multipoint to multipoint communication, Figure 24 shows:
Intra-Mobile Communications Network Link (M-M Link)
Mobile Communications Network-Landline Telephone Network Link (M-L Link)
Figure 24 Interfaces within UMTS for Multipoint to Multipoint Communication
For SMS Cell Broadcast Services (CBS) an additional node in the Core Network, called Cell Broadcast Center
(CBC), is introduced. The Cell Broadcast Center is connected to the corresponding RNCs via IP connections that
may also be routed via the SGSN, see Figure 25. For a detailed description of the feature see FD012219a SMS
Cell Broadcast.
CBS is an unidirectional point to multipoint communication. One RNC can be connected to only one CBC, whereas
a CBC can be connected to multiple RNCs. The RNC might be connected as follows:
Directly to the CBC
Indirectly to the CBC through the SGSN which acts as the router (protocol converter)
CBCs that do not support the ATM/AAL5/IP/TCP interface according to 3GPP specification need the SGSN to be
connected to the RNC.
MSC/
Iub
Iu CS
Iu PS Iub
Uu
Uu
Intra-MobiIe Communications Network (M-M Link)
MobiIe Communications Network-LandIine TeIephone Network (M-L Link)
Iub
WCDMA ATM ATM
RNS CN
Iur
VLR
RNC
RNC
SGSN/
SLR
6&
6&
/PEF#
/PEF#
/PEF#


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
51
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Figure 25 Interfaces within UMTS for Unidirectional Point to Multipoint Communication
The following subsection Interface Protocol Structure introduce protocol stacks to illustrate the communication via
the interfaces between the network elements. Additionally, it provides short descriptions of the following interfaces:
Uu Interface
Iub Interface
Iur Interface
Iu Interface
2.2.1 Interface Protocol Structure
The interface protocol architecture consists of two horizontal layers, see Figure 26:
Radio Network Layer
The Radio Network Layer defines procedures relating to the operation of another node. All UTRAN-related
issues are visible in this layer.
Transport Network Layer
The Transport Network Layer defines procedures for establishing physical connections between other nodes
and the RNC. This layer provides transport-related technologies. It has no UTRAN-specific content. Please
also see Transport Network Layer.
Iub
ATM Iub
Uu
Uu
Iub
WCDMA ATM ATM
RNS CN
E
t
h
e
r
n
e
t
RNC
RNC directIy connected to the CBC
RNC indirectIy connected to the CBC via SGSN
Iu BC
CBC
SGSN
GGSN
ATM/
Ethernet
Converter
RNC
/PEF#
/PEF#
/PEF#
6&
6&


52 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Figure 26 Protocol Stacks in the Radio Network and the Transport Network Layer
In addition, the protocol stack of an interface consists of 3 vertical layers:
User plane
The user plane transports all user data including data stream(s) and data bearer(s). It supports:
circuit-switched domain data transport protocols
packet-switched domain data transport protocols
Control plane
The control plane provides UMTS-specific control signaling including the application protocols, i.e. RANAP,
RNSAP and NBAP, and the signaling bearer for transporting the application protocol messages. It supports:
Control signaling protocols
for circuit-switched/packet-switched service management, user management and resource management
Transport signaling protocols
for the allocation of the bearers between the RNC and the 3G-MSC in the case of a circuit-switched
domain.
Transport network control plane
The transport network control plane provides all control signaling within the transport network layer. This plane
mediates between the control plane and the user plane to keep the application protocol of the control plane
independent of the technology selected for the data bearer in the user plane.
Transport network user plane
The transport network user plane includes the data bearer(s) in the user plane as well as the signalling
bearer(s) for the application protocol. The data bearers are
directly controlled by the transport network control plane during real-time operation. To set up signalling
bearer(s) for the application protocol control actions by means of OAM commands are required.
Several protocol stacks reflect the data transfer via individual interfaces between the UMTS network elements.
These interfaces are defined by 3GPP technical specifications. For example Figure 27 shows the protocol stack
for the control plane of a voice communication in an M-L link, while Figure 28 shows the corresponding user plane.
Figure 29 and Figure 30 show the protocol stacks for HSDPA traffic.
Transport
Network
Layer
Radio
Network
Layer
Application
Protocol
Data
Stream(s)
PhysicaI Layer
Transport
Network
User Plane
User Plane
Signaling
Bearer(s)
Signaling
Bearer(s)
Data
Bearer(s)
ALCAP(s)
Transport
Network
User Plane
Control Plane
Transport
Network
Control Plane


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
53
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Figure 27 Voice Communication (C Plane) Protocol Stack in M-L Link
Figure 28 Voice Communication (U Plane) Protocol Stack in M-L Link
Figure 29 HSDPA Protocol Stack within UTRAN
RLC-C
RRC
ATM
AAL2
MAC
RLC-C
CC/MM
RRC
M-LI M-LI
ATM
AAL2 AAL5
SCCP
SSCF-NNI
MTP-3b
ATM
CC/MM
RANAP
SSCOP
AAL5
B-ISUP
SSCF-NNI
MTP-3b
ATM ATM
AAL5
SCCP
SSCF-NNI
MTP-3b
RANAP
SSCOP
UE Node B RNC 3G MSC
Uu Iub I u
MAC
SSCOP
AMR
Iu-UP
AAL2
ATM
AAL1
AMR
ATM ATM
AAL2
Iu-UP
UE Node B RNC 3G MSC
Uu Iub I u
-Iaw
PCM
ATM
AAL2
MAC
ML1 ML1 ATM
AAL2
MAC
RLC
PDCP
ATM
AAL2
MAC-hs
RLC
PDCP
MAC-hs
ATM
AAL2
ATM
AAL5
GTP-U
UDP
UE Node B RNC
Uu Iu Iu
Phy.
Phy. Phy.
HS-DSCH
FP
Phy. Phy.
HS-DSCH
FP
MAC-d
IP
MAC-d


54 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Figure 30 Protocol Stack within the RNC on HSDPA Traffic Route
While Wideband Code Division Multiple Access (WCDMA) is used for the air interface (Uu), Asynchronous
Transfer Mode (ATM) is used as the underlying network layer for the Iub and the Iu Interface. ATM provides trans-
port and signaling protocols for both circuit-switched and packet-switched connections. Figure 31, Figure 32 and
Figure 33 show the protocol stack of the Iu, Iur and the Iub interface. Figure 34 shows the same for the SMS Cell
Broadcast service.
Figure 31 Protocol Stack of the Iu Interface
Figure 32 Protocol Stack of the Iur Interface
ATM
AAL2
ATM
AAL2-d
CMP/WCMP
RNC
GMUX
UDP
HSDST
ATM
AAL2-d
ATM
AAL2-d
HSPRLC
ATM
AAL5
IP
MAC-d
HS-DSCH
InternaI
FP
FP
(HSDPA)
ATM
AAL2-d
InternaI
FP
(HSDPA)
GTP-U
RLC
PDCP
UDP
ATM
AAL5
IP
GTP-U
UDP
ATM
AAL5
IP
GTP-U
3G MSC
ControI signaIing Data transport
RANAP
SCCP
MTP3-B
SAAL (SSCOP+SSCF)
AAL2
ATM
SDH/PDH
AAL5
3G SGSN
GTP
UDP
IP
(PS) (CS)
RNC
Transport signaIing
ALCAP
STC
ControI signaIing Transport signaIing Data transport
RANAP
SCCP
MTP3-B
SAAL (SSCOP+SSCF)
AAL2
ATM
AAL5
RNC
PHYSICAL LAYER (SDH/PDH)
RNC
ALCAP
STC


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
55
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Figure 33 Protocol Stack of the Iub Interface
Figure 34 SMS Cell Broadcast Service Protocol Stack of Direct ATM Connection
2.2.2 Uu Interface
The UMTS air interface (i.e. Uu interface) is the radio interface between the UMTS terrestrial radio access
network (UTRAN) and the user equipment (UE). The Uu interface adopts the communication between Node B and
the UE. It comprises the control plane (C-plane) for signaling and the user plane (U-plane) for the transfer of user
data.
The Uu interface consists of three protocol layers:
Physical layer (L1/PHY)
Data link layer (L2)
The data link layer is divided into sub-layers:
Medium Access Control Protocol (L2/MAC)
Radio Link Control Protocol (L2/RLC)
Broadcast/Multicast Control Protocol (L2/BMC)
Packet Data Convergence Protocol (L2/PDCP)
Network layer (L3)
The radio resource control protocol (L3/RRC) is the only element of the network layer.
Figure 35 shows the Uu interface protocol architecture. Service Access Points (SAP) for peer-to-peer communi-
cation are marked with ellipses.
Data
Transport
Node
Synch.
Transport
Signaling
Control
Signaling
Impl.
Specific
OAM
NBAP
ALCAP
STC
I-S
OAM
F
T
P
AAL2
SSCF-UNI
SSCOP
AAL5
TCP/UDP
IP
ATM
PHYSICAL LAYER (E1)
Node B
RNC
AAL1
CES
E.R.
AAL5
GIC
CBC
SABP
PRU
RNC
TCP
IP
CIP
CPCS
SAR
ATM
PHY
AAL5 - AAL3/4
CPCS
SAR
ATM
PHY
CPCS
SAR
ATM
PHY
IP-Routing
IP
CIP
CPCS
SAR
ATM
PHY
LLC
MAC
PHY
IP
SABP
IP
LLC
MAC
PHY
TCP
AAL3/4
DCN
Interworking function
ATM/Ethernet
Converter
CeII
Center
Broadcast


56 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Figure 35 Uu Interface Protocol Architecture
The 3GPP Release 5 (Rel 5) RNC is able to interoperate with a UE of Rel 99, Rel 4, and Rel 5 via the Uu interface.
HSDPA support comprises minimum changes in the UTRAN for compliancy to the Rel 5 version of protocols at
the Uu interface. These changes impact on Uu layer 1 (L1), layer 2 (L2), and layer 3 (L3). For a detailed descrip-
tion see FD012249 Support of HSDPA.
2.2.2.1 Radio Channels
Radio channels offer transport services over the Uu interface between the UTRAN and the User Equipment (UE).
The channels are managed by the interface protocols of both UTRAN and UE.
Channel concepts
There are three separate channel concepts in the UTRAN (see Figure 36):
Physical channels
Define the exact physical characteristics of the radio channel.
Transport channels
Define how and with which type of characteristics the data is transferred
by the physical layer.
Logical channels
Define what type of data is transferred.
RLC
RLC
RLC
RLC
BMC
RRC
PDCP
PDCP
GC Nt DC
DupIication avoidance
GC Nt DC
C-pIanesignaIing U-pIane information
UuSboundary
controI
c
o
n
t
r
o
I
c
o
n
t
r
o
I
RLC
RLC
RLC
RLC
RLC
RLC
RLC
RLC
MAC
PHY
c
o
n
t
r
o
I
c
o
n
t
r
o
I
L1
L2/MAC
L3
L2/RLC
L2/BMC
L2/PDCP
Transport ChanneIs
LogicaI ChanneIs


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
57
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Figure 36 Channel Concepts in UTRAN
Physical channel
Physical channels are provided by the physical layer (L1/PHY) for data transfer between the UTRAN and UE.
Physical channels are defined by a specific carrier frequency, scrambling code, channelization code (optional),
time start & stop (giving a duration) and, on the uplink, relative phase (0 or /2).
In UMTS physical channels can be transmitted in two ways:
Normal mode:
Transmission is performed continuously without gaps.
Compressed mode:
Transmission is interrupted to allow the UE to monitor cells on other frequencies and from other RAT systems,
such as GSM.
Most physical channels have a two-layer structure consisting of radio frames and time slots. A radio frame is a
processing unit that consists of 15 time slots. A time slot consists of fields that contain bits. The number of bits per
slot depends on the type of physical channel. The configuration of the slots varies depending on the channel bit
rate of the physical channel.
As an example for a two-layer-structure, Figure 37 and Figure 38 show the physical channel architecture for the
Dedicated Physical Channel (DPCH). It consists of two physical sub-channels, the Dedicated Physical Data
Channel (DPDCH) and the Dedicated Physical Control Channel (DPCCH), which are I/Q code multiplexed within
each radio frame. The DPDCH itself has a three-layer structure with an additional superframe consisting of 72
radio frames with a total duration of 720 ms (see Figure 39).
RNC
UE
Node B
LogicaI ChanneIs
PhysicaI ChanneIs
Transport ChanneIs


58 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Figure 37 Structure of the DPCH in Downlink Direction
Figure 38 Structure of the DPCH in Uplink Direction
DPDCH for user data and DPCCH for control data of layer 1 are configured differently in uplink and downlink direc-
tion. In UL user data and control data are not time multiplexed on a single DPCH (as in DL), but transmitted sep-
arately. The reason is, that in case of DTX-Transmission (Discontinous Transmission) control data are transmitted
in uplink direction, but user data are not.
Slot #0 Slot #1 Slot #14 Slot #i
Tslot = 2560 chips
TFCI
NTFCI bit
DPDCH DPCCH
Data 1
Nd1 bit
TPC
NTPC bit
Data 2
Nd2 bit
Pilot
Np bit
DPDCH DPCCH
Frame (Tf = 10 ms)
DL-DPCH
Time slot
Data
Ndbit
Pilot
Np bit
FBI
NFBI bit
TPC
NTPC bit
Slot #0 Slot #1 Slot #14 Slot #i
Tslot = 2560 chips
Frame (Tf = 10 ms)
TFCI
NTFCI bit
DPDCH
DPCCH
UL-DPCH


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
59
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Figure 39 Structure of the DPDCH
Figure 40 shows the mapping of the transport channels to the physical channels.
Figure 41 shows the same for HSDPA.
Figure 40 Mapping of Transport Channels to Physical Channels
TPC
N
TPC
bits
TFI
N
TFI
bits
Slot #1 Slot #2 Slot #15 Slot #i
0.667 ms, 10*2
k
bits (k=0..6)
Frame #1 Frame #2 Frame #72 Frame #i
Superframe Ts= 720 ms
DPDCH
Data
Ndbit
Pilot
Np bit
Frame (Tf = 10 ms)
Transport ChanneIs PhysicaI ChanneIs
Paging Channel (PCH)
Dedicated Physical Data Channel (DPDCH)
Dedicated Physical Control Channel (DPCCH)
Physical RandomAccess Channel (PRACH)
Secondary Common Control
Acquisition ndicator Channel (ACH)
Paging ndicator Channel (PCH)
Physical Channel (S-CCPCH)
Dedicated Channel (DCH)
Random Access Channel (RACH)
Forward Access Channel (FACH)
Common Packet Channel (CPCH) Physical Common Packet Channel (PCPCH))
Broadcast Channel (BCH) Primary Common Control
Physical Channel (P-CCPCH)
Downlink Shared Channel (DSCH)
Common Pilot Channel (CPCH)
Synchronization Channel (SCH)
Physical Downlink Shared Channel (PDSCH)


60 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Figure 41 Mapping of Transport Channels to Physical Channels with HSDPA
The name and function of each physical channel is listed below:
Dedicated Physical Data Channel (DPDCH)
The uplink DPDCH carries the DCH transport channel. There may be zero, one, or several uplink DPDCHs on
each radio link.
Dedicated Physical Control Channel (DPCCH)
The uplink DPCCH carries control information generated at Layer 1. The Layer 1 control information consists
of known pilot bits to support channel estimation for coherent detection, Transmit Power-Control (TPC) com-
mands, Feedback Information (FBI), and an optional Transport-Format Combination Indicator (TFCI). The
TFCI informs the receiver about the instantaneous transport format combination of the transport channels
mapped to the simultaneously transmitted uplink DPDCH radio frame. There is only one uplink DPCCH on
each radio link.
Physical Random Access Channel (PRACH)
The PRACH carries the Random Access Channel (RACH).
Common Pilot Channel (CPICH)
The CPICH carries a predefined bit/symbol sequence in downlink direction.
Primary Common Control Physical Channel (P-CCPCH)
The P-CCPCH carries the BCH transport channel in downlink direction.
Transport ChanneIs PhysicaI ChanneIs
Paging Channel (PCH)
Dedicated Physical Data Channel (DPDCH)
Dedicated Physical Control Channel (DPCCH)
Physical RandomAccess Channel (PRACH)
Secondary Common Control
Acquisition ndicator Channel (ACH)
Paging ndicator Channel (PCH)
Physical Channel (S-CCPCH)
Dedicated Channel (DCH)
Random Access Channel (RACH)
Forward Access Channel (FACH)
Common Packet Channel (CPCH) Physical Common Packet Channel (PCPCH))
Broadcast Channel (BCH) Primary Common Control
Physical Channel (P-CCPCH)
Stand-alone SRB for PCCH (on S-CCPCH)
Downlink Shared Channel (DSCH)
Highspeed Downlink Shared
Channel (HS-DSCH)
Highspeed Physical Downlink
Shared Channel (HS-PDSCH)
HS-DSCH-related Shared Control
Channel (HS-SCCH)
Dedicated Physical Control Channel (UL)
for HS-DSCH (HS-DPCCH)
optional
Common Pilot Channel (CPCH)
Synchronization Channel (SCH)
Physical Downlink Shared Channel (PDSCH)
Access Preamble Acquisition ndicator
Channel (AP-ACH)
CPCH Status ndicator Channel (CSCH)
Collision-Detection/Channel-Assignment
ndicator Channel (CD/CA-CH)


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
61
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Secondary Common Control Physical Channel (S-CCPCH)
The S-CCPCH carries the Forward Access Channel (FACH) and Paging Channel (PCH).
Synchronization Channel (SCH)
The SCH is a downlink channel used for cell search and synchronization of the UE.
Acquisition Indication Channel (AICH)
The AICH carries the Acquisition Indicators (AIs).
Paging Indicator Channel (PICH)
The PICH carries the Paging Indicators (PIs). The PICH is always associated with an S-CCPCH to which a
PCH transport channel is mapped.
Highspeed Physical Downlink Shared Channel (HS-PDSCH)
HS-PDSCH is the DL data channel for HSDPA carrying the user data.
Highspeed Shared Control Channel (HS-SCCH)
The HS-SCCH is the DL control channel (e.g. HARQ, TRFI) for HSDPA. The information carried on this
channel enables UEs to receive the HS-PDSCH.
Highspeed Dedicated Physical Control Channel (HS-DPCCH)
The HS-DPCCH is the UL control channel for HSDPA carrying the channel quality information (CQI) and
ACK/NACK information of the corresponding UE.
Transport channel
Transport channels are provided by layer 1 to transfer the data between layer 1 and higher layers. Transport
channels are divided into two groups, common transport channels and dedicated transport channels. Common
transport channels address UEs by in-band identification, while dedicated transport channels exclusively allocate
a UE for a certain period of time. Figure 42 shows the structure of the transport channels.
Figure 42 Structure of Transport Channels
The name and function of each transport channel is listed below:
Common transport channel
The common transport channels use explicit addressing of UE.
Random Access Channel (RACH)
The RACH is an uplink transport channel that is used to carry control information from the UE. The RACH
may also carry short packets. The RACH is always received from the entire cell (e.g. for initial access or
non-real-time dedicated control or traffic data).
Forward Access Channel (FACH)
The FACH is a downlink transport channel that is used to carry control information to a UE when the
system knows the location cell of the UE. The FACH may also carry short user packets.
Paging Channel (PCH)
The PCH is a downlink transport channel that is used to carry control information to a UE when the system
does not know the location cell of the UE.
Common Transport
Channel
Dedicated Transport
Random Access Channel (RACH)
Forward Access Channel (FACH)
Paging Channel (PCH)
Dedicated Channel (DCH)
Transport
Channel
Channel
Broadcast Channel (BCH)
Downlink Shared Channel (DSCH)
Common packet Channel (CPCH)
HSDPA Downlink Shared Channel
(HS-DSCH)


62 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Broadcast Channel (BCH)
The BCH is used for transmission of network or cell specific information, e.g. the employed transmit diver-
sity method or available random access codes.
Downlink Shared Channel (DSCH)
The DSCH is a downlink transport channel that is used to carry dedicated user data and/or control infor-
mation to a UE. The DSCH can be shared by several users.
HSDPA Downlink Shared Channel (HS-DSCH)
The HS-DSCH is a downlink transport channel that is used to carry dedicated user data information to a
UE. The HS-DSCH can be shared by several users. It enables the throughput of higher peak data rates
compared to Rel 99 data rates.
Common Packet Channel (CPCH)
The CPCH is an uplink transport channel that is used to carry packet-based user data from the UE. The
CPCH is an extension to the RACH as transmission may last several frames instead of one or two frames
when RACH is used.
Dedicated transport channel
The dedicated transport channel uses inherent addressing of UE.
Dedicated Channel (DCH)
The DCH is a channel dedicated to one UE used on both the uplink and the downlink path.
Logical channel
Logical channels are provided by the MAC on layer 2 to transfer the data between L2/MAC and the higher layers.
Logical channels are divided into two groups, control channels and traffic channels. Figure 43 shows the structure
of the logical channels.
Figure 43 Structure of Logical Channels
The name and function of each logical channel is listed below:
Control channels
Broadcast Control Channel (BCCH)
The BCCH is a downlink channel for broadcasting system control information.
Paging Control Channel (PCCH)
The PCCH is a downlink channel that transfers paging information. This channel is used when the network
does not know the location cell of the UE, or the UE is in the cell connected state (utilising UE sleep mode
procedures).
Dedicated Control Channel (DCCH)
The DCCH is a point-to-point bi-directional channel that transmits dedicated
control information between a UE and the network. This channel is established according to the RRC con-
nection setup procedure.
Common Control Channel (CCCH)
The CCCH is a bi-directional channel for transmitting control information between the network and UEs.
This channel is commonly used by the UEs which have no RRC connection with the network and by the
UEs which use common transport channels when accessing a new cell after cell reselection.
Traffic channels
Logical Control Channel
(CCH)
Traffic Channel
Broadcast Control Channel (BCCH)
Paging Control Channel (PCCH)
Dedicated Control Channel (DCCH)
Common Control Channel (CCCH)
Dedicated Traffic Channel (DTCH)
(TCH)
Channel
Common Traffic Channel (CTCH)


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
63
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Dedicated Traffic Channel (DTCH)
A DTCH is a point-to-point channel, dedicated to one UE, for the transfer of
dedicated user information. A DTCH can exist on both uplink and downlink paths.
Common Traffic Channel (CTCH)
A CTCH is a point-to-multipoint unidirectional channel for transfer of user
information for all or a group of specified UEs.
Mapping between logical channels and transport channels
The mapping between logical channels and transport channels in uplink and downlink direction is illustrated in
Figure 44.
Figure 44 Mapping between Logical Channels and Transport Channels
2.2.2.2 Physical Layer (L1)
Layer 1 is the physical layer (L1/PHY). It supplies information transfer services between the User Equipment (UE)
and the L2/Medium Access Control (MAC) at network side.
The UE communicates with the physical layer via physical channels, while the physical layer communicates with
the MAC via transport channels. The physical layer maps the transport channels onto physical channels.
Layer 1 also has the following functions:
Macro-diversity distribution/combining and soft handover execution
Error detection on transport channels and indication to higher layers
FEC encoding/decoding and interleaving/deinterleaving of transport channels
Multiplexing of transport channels and demultiplexing of coded composite transport channels
Rate matching
Power weighting and combining of physical channels
Modulation and spreading/demodulation and de-spreading of physical channels
Frequency and time (chip, bit, slot, frame) synchronization
Measuring and indication to higher layers (FER, SIR, interference power, transmit power, etc.)
Closed-loop power control
RF processing
Dedicated Traffic Channel (DTCH) Dedicated Channel (DCH)
Transport Channels Logical Channels
Paging Channel (PCH)
Random Access Channel (RACH)
Forward Access Channel (FACH)
Common Packet Channel (CPCH)
Broadcast Channel (BCH) Broadcast Control Channel (BCCH)
Paging Control Channel (PCCH)
Dedicated Control Channel (DCCH)
Common Control Channel (CCCH)
Common Traffic Channel (CTCH)
Uplink
Downlink
Dedicated Channel (DCH)
Downlink Shared Channel (DSCH)
Common Control Channel (CCCH)
Dedicated Traffic Channel (DTCH)
Dedicated Control Channel (DCCH)
HSDPA Downlink Shared Channel
(HS-DSCH)


64 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Compared to 3GPP Rel 99, the functionality of the physical layer measurements on the Uu L1 (physical layer) are
changed by Rel 5 with respect to the following:
Received total wideband power (RTWP)
Signal to interference ratio (SIR)
For a detailed description see FD012249 Support of HSDPA.
For more information and an overall illustration of the processes in the physical layer, please see section Trans-
port Channel Coding/Multiplexing.
2.2.2.3 Data Link Layer (L2)
Layer 2 is the data link layer. It is split into the following sub-layers:
Medium Access Control (MAC)
Radio Link Control (RLC)
Broadcast/Multicast Control (BMC)
Packet Data Convergence Protocol (PDCP)
The individual sub-layers are described below.
Medium Access Control (MAC) Layer
The Medium Access Control (MAC) supplies information transfer services between the physical layer and the
Radio Link Control (RLC).
The physical layer communicates with the MAC via transport channels, while the MAC communicates with the
Radio Link Control (RLC) via logical channels. The MAC maps the transport channels onto logical channels.
The MAC layer also has the following functions:
Unacknowledged transfer of MAC Service Data Units (SDUs) between peer MAC entities
Re-allocation of radio resources and MAC parameters
Selection of the appropriate Transport Format for each Transport Channel depending on instantaneous source
rate
Priority handling between
data flows of one UE
different UEs by means of dynamic scheduling
Identification of UEs on common transport channels
Multiplexing/demultiplexing of higher-layer
Protocol Data Units (PDUs) into/from transport blocks delivered to/from the physical layer on common
transport channels
PDUs into/from transport block sets delivered to/from the physical layer on dedicated transport channels
Measuring of traffic volume on logical channels and reporting to RRC
Switching between common and dedicated transport channels based on a switching decision derived by RRC.
Ciphering to prevent unauthorized data acquisition
Access Service Class selection for RACH transmission
Radio Link Control (RLC) Layer
The Radio Link Control (RLC) supports the segmentation and re-transmission of user and control data. RLC is
affected by a Rel 5-compliant upgrade of the Uu interface. For a detailed description see FD012249 Support of
HSDPA.
Furthermore, the RLC has the following functions:
RLC connection establishment/release
Transfer of user data
Transparent data transfer of higher-layer PDUs
Unacknowledged data transfer of higher-layer PDUs without guaranteed delivery to peer entity


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
65
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Acknowledged data transfer of higher-layer PDUs with guaranteed delivery to the peer RLC entities
Controlling of data flow rate between the peer RLC entities
Sequence number check in unacknowledged data transfer mode
Error Control
Error correction by re-transmission in acknowledged data transfer mode
Notification of unrecoverable errors to higher layers
Protocol error detection and recovery
Quality of Service (QoS) setting
Acknowledged, unacknowledged and transparent data transfer controlled by QoS setting
Management of data
Concatenation of RLC SDUs into the RLC PU
Segmentation of variable-length higher-layer PDUs into RLC PDUs
Re-assembly of variable-length higher-layer PDUs from RLC PDUs
Filling of RLC PDUs with padding bits whenever concatenation is not applicable
In-sequence or out-of-sequence delivery of higher-layer PDUs
Detection and avoidance of duplicated transmission of RLC PDUs
Ciphering to prevent unauthorized data acquisition in RLC layer for non-transparent RLC mode
Suspension and resumption of data transfer as in LAPDM.
Packet Data Convergence Protocol (PDCP)
The Packet Data Convergence Protocol (PDCP) improves the spectral efficiency for the transmission of IP packets
by compression methods. Beside TCP/IP and UDP/IP also pure IP header compression is supported. The PDCP
is located in the user plane.
The PDCP has the following functions:
Transmission and receipt of Network PDUs in acknowledged, unacknowledged and transparent RLC mode
Mapping of Network PDUs from one network protocol to one RLC entity
Compression in the transmitting entity and decompression in the receiving entity of redundant Network PDU
control information (header compression/decompression)
Broadcast/Multicast Control (BMC)
The Broadcast/Multicast Control (BMC) provides broadcast/multicast transmission services in the user plane for
common user data in transparent or unacknowledged mode.
The BMC has the following functions:
Storage of cell broadcast messages received over the CBC-RNC interface for scheduled transmission
Traffic volume monitoring and radio resources request for CBS
Scheduling of BMC messages
Transmission of BMC messages to UE according to schedule
Delivery of cell broadcast messages to upper layers in the UE
2.2.2.4 Network Layer (L3)
Layer 3 is the network layer. It provides Uu stratum services. For an overview of the service layers, please see
Layers and Protocols.
Layer 3 has a Radio Resource Control (RRC) sub-layer. The RRC handles the control plane signaling of layer 3
between the UMTS Terrestrial Radio Access Network
(UTRAN) and the UE.


66 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Uu Stratum services
Uu Stratum services are divided into:
General Control SAP (GC SAP)
The GC SAP provides an information broadcast service. This service broadcasts information to all UEs in a
certain geographical area.
Notification SAP (Nt SAP)
The Nt SAP provides the paging and the notification broadcast services.
The paging broadcast service sends the paging information to (a) specific UE(s). The information is broadcast
in a certain geographical area but addressed to (a) specific UE(s).
The notification broadcast service broadcasts information to all UEs in a certain geographical area.
Dedicated Control SAP (DC SAP)
The DC SAP provides the establishment/release service and the information transfer service.
The establishment/release service establishes/releases the connection to the UE (both point connection and
group connection) in an early phase. Message transfer during the establishment phase is possible.
The information transfer service sends a message using the previously established connection. DC SAP
allows the QoS to be specified for each message.
Radio Resource Control (RRC)
The Radio Resource Control (RRC) messages contain a broad variety of control information for the communica-
tion between the UE and the UTRAN.
The RRC has the following functions:
Broadcasting on a regular basis
the higher layer (i.e. Core Network (CN)) information
the system information about access stratum
Scheduling the broadcasting of the higher layer information and the system information
Segmenting the higher layer information and the system information
Establishing, re-establishing, maintaining and releasing the RRC connection (i.e. the first signaling connection
for the signalling radio bearers) between the UTRAN and the UE
Establishing, re-configuring and releasing the radio access bearers in the user plane of layer 2 and layer 1
Assigning, re-configuring and releasing the radio resources for the RRC connection
Managing the transport and physical channels
Evaluation, decision-making and execution relating to RRC connection mobility (e.g. handover, cell re-selec-
tion, cell/paging area update procedures and so on) during an established RRC connection
Broadcasting the paging information and the notification information from the network to selected UEs
Performing the UE-side routing of higher-layer PDUs to the correct higher-layer entities
Performing the UTRAN-side routing of higher-layer PDUs to the correct Radio Access Network Application
Part (RANAP) entities
Controlling the QoS requested for the radio bearers (e.g. the allocation of a sufficient number of radio
resources)
Controlling the measurements performed by the UE (e.g. measurement item, measurement timing, the way of
reporting, measurement command to setup, modify, release, measurement type such as Intra/Inter-Fre-
quency, Inter-RAT, traffic Volume, object (EC/N0, RSCP, buffer...), timing, reporting criteria for measure-
ments, and so on.)
Reporting the UE measurements to the network
Supporting the DL outer loop power control by configuring and supporting the open loop power control by
transmitting initial power
Controlling the security functions like the ciphering (e.g. on/off) between the UE and UTRAN and the integrity
protection of signalling (adding and verifying the Message Authentication Code (MAC-I) to RRC messages).
Controlling the fast allocation of radio resources on uplink DCH, using a broadcast channel to send control
information to all involved users.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
67
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Selecting the most suitable cell based on the measurements performed by the UE in idle mode and the cell
selection criteria
Functions for CBS:
Performing the initial configuration of the L2/BMC
Allocating the radio resources and broadcasting the allocation as system information
Configuring layer 1 and layer 2 of the UE for discontinuous reception
In the Rel 5 RRC protocol, two new types of protocol extensions are supported.
Non-critical extensions:
allowed for both uplink (UL) and downlink (DL) messages
Critical extensions:
can only be applied in DL direction
These protocol extensions require enhanced functionality for the RNCs Rel 5 RRC decoder and encoder. For a
detailed description see FD012249 Support of HSDPA.
Radio Resource Control Connection States
There is only one RRC connection between the UE and UTRAN, regardless of the number of communication rela-
tions that exist between the UE and one or more other terminals during the connection. Within UMTS the RRC
manages all the frequencies assigned to a UE and the connection is always maintained regardless of the type of
the active service. For optimum adaptation of the UTRAN to all the supported service classes, four different states
of an RRC connection are defined in connected mode (Figure 45):
CELL_DCH
CELL_FACH
CELL_PCH
URA_PCH
These connection states correspond to certain levels of activity between the UE and UTRAN.
Figure 45 RRC Connection States
The IDLE state of the RRC corresponds to the standby mode of the UE. In the IDLE state no connection between
the UE and UTRAN is established. In general, the transition from one connection state to another is managed by
the UTRAN. However, the transition from the IDLE state to a connection state can only be initiated by the UE,
regardless of the direction in which the connection is established.
Inter-PLMN cell selection/re-selection in idle as well as in connected mode is performed based on the neighboring
cell measurements done by the UE. For operators who want to share their networks with other operators system
Cell_PCH
IDLE
UE
in non-connected mode
UE
in connected mode
Cell_DCH Cell_FACH
URA_PCH


68 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
information can be broadcast using SIB 18 (as specified in 3GPP TS 25.331). Supporting SIB 18 improves the cell
selection/re-selection procedure in a way that the PLMN ID is signaled for any configured neighboring cell to the
UE and only the relevant cells are measured by the UE (see FD012272 Support of SIB18).
For a detailed description of the individual states and the transition between them, please see OMN:RN-750
Radio Network Configuration Basics.
2.2.3 Iub Interface
The Iub interface is used for the communication between the Radio Network Controller (RNC) and its subordinate
Node Bs. It is based on an ATM connection.
The following information is transmitted via the Iub interface:
Radio Application Related Signaling
Iub Dedicated Channel (DCH) Data Stream
Iub/Random Access Channel (RACH) Data Stream
Iub/Forward Link Access Channel (FACH) Data Stream
Iub/Paging Channel (PCH) Data Stream
For example, the Iub interface allows the RNC and Node B to allocate radio resources. Cells that are controlled
by Node B can be added or deleted. These cells support the communication between the User Equipment (UE)
and the Serving Radio Network Controller (SRNC) via a dedicated connection.
Furthermore, the category of radio application-related signaling includes:
Information used to control the broadcast and paging channels
Information to be transmitted over the broadcast and paging channels
Logical Operation and Maintenance (OAM) connections between the RNC and Node B
Node B provides the UTRAN with the logical resources including the physical channel resources, i.e. the Dedi-
cated Physical Channels (DPCH).
2.2.3.1 Iub Interface Protocol Structure
Figure 46 Iub Interface Protocol Structure
Data
Transport
Node
Synch.
Transport
Signaling
Control
Signaling
Impl.
Specific
OAM
NBAP
ALCAP
STC
I-S
OAM
F
T
P
AAL2
SSCF-UNI
SSCOP
AAL5
TCP/UDP
IP
ATM
PHYSICAL LAYER (E1)
Node B
RNC
AAL1
CES
E.R.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
69
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
2.2.3.2 NBAP Signaling on Iub
The Iub interface signaling protocol (NBAP, Node B Application Part) consists of two essential components:
Common NBAP procedures
used for common channel signaling links that request initiation of a Node B Communication Context for a
specific UE in Node B or are not related to a specific UE. NBAP common procedures also incorporate logical
OAM procedures.
Dedicated NBAP procedures
used for dedicated channel signaling links that are related to a specific UE context Node B Communication
Context in Node B. This Node B Communication Context is identified by a Node B Communication Context
identity.
2.2.4 Iur Interface
The Iur interface is used to logically connect two RNCs within the UTRAN. It is specified as an open interface in
order to facilitate:
inter-connection of RNCs supplied by different manufacturers
support of continuation between RNSs of the UTRAN services offered via Iu
separation of Iur interface Radio Network functionality and Transport Network functionality to facilitate the
introduction of future technology
The Iur interface enables addressing of RNSs within the PLMN. In more detail, this means:
Radio links supported by cells belonging to any RNS within the PLMN can be added/deleted for an RRC con-
nection using a dedicated channel.
An RNC can address any other RNC within the PLMN for establishing a signaling bearer via Iur.
An RNC can address any other RNC within the PLMN for establishing user data bearers for Iur data streams.
The Iur interface can be implemented by different methods. The implementation can be chosen individually for
each adjacent RNC depending on the traffic load expected on a Iur instance.
Iur implemented as PVC
connection remains established even if not required
advantageous if handovers occur at a high rate
advantageous for Iur instances with constant high traffic load
inefficient if traffic load is low or varying, because bandwidth is allocated even if not needed
there is an upper bound on the number of adjacent RNCs connected via PVC
Iur implemented through AAL2 Switching in CN
Iur connections are routed through the CN, using existing Iu connections
connections are set up and deleted automatically as they are requested from one of the RNCs involved
requires connection setup at each handover (entails more signaling traffic)
efficient for low traffic Iur connections


70 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
2.2.4.1 Iur Interface Protocol Structure
Figure 47 Iur Interface Protocol Structure
2.2.4.2 RNSAP Signaling on Iur
The Iur signaling protocol (RNSAP, Radio Network Subsystem Application Part) is divided into different
modules with different sets of RNSAP procedures:
Basic inter-RNC mobility procedures
Mobility handling within UTRAN and for UTRAN/GERAN interworking.
Dedicated channel traffic procedures
Handling of DCHs between two RNSs.
Global resource management procedures
Resource management not related to a specific UE involving two peer CRNCs and for UTRAN/GERAN inter-
working.
2.2.5 Iu Interface
The Iu interface connects UTRAN to the CN. It is specified as an open interface that divides the system into radio-
specific UTRAN and CN which handles switching, routing and service control.
The Iu interface has different instances (as can be seen in Figure 24 and Figure 25):
Iu CS (Iu Circuit-Switched) for connecting UTRAN to circuit-switched CN
Iu PS (Iu Packet-Switched) for connecting UTRAN to packet-switched CN
Iu BC (Iu Broadcast Center) for connecting UTRAN to CBC
These instances provide different Transport Network Control Planes, which ensure fully optimized user plane
transport for CS, PS and SMS CB services.
Physical Layer
ATM

RNSAP
ALCAP
Transport Network
Control Plane
User Plane
Transport
Network
Layer
Radio
Network
Layer
Control Plane
Transport Network
User Plane
Transport Network
User Plane
AAL2 AAL5
SSCOP
SSCF-NNI
MTP3-B
SCCP
AAL5
SSCOP
SSCF-NNI
MTP3-B
STC
Iur user plane
protocol


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
71
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
2.2.5.1 Iu CS Interface Protocol Structure
Figure 48 Iu CS Interface Protocol Structure
2.2.5.2 Iu PS Interface Protocol Structure
Figure 49 Iu PS interface protocol structure
Physical Layer
ATM

RANAP
ALCAP
Iu user plane
Transport Network
Control Plane
User Plane
Transport
Network
Layer
Radio
Network
Layer
Control Plane
Transport Network
User Plane
Transport Network
User Plane
AAL2 AAL5
SSCOP
SSCF-NNI
MTP3-B
SCCP
AAL5
SSCOP
SSCF-NNI
MTP3-B
STC
protocol
Physical Layer
ATM

RANAP
Iu user plane
Transport Network
Control Plane
User Plane
Transport
Network
Layer
Radio
Network
Layer
Control Plane
Transport Network
User Plane
Transport Network
User Plane
AAL5
SSCOP
SSCF-NNI
MTP3-B
SCCP
AAL5
IP
UDP
GTP-U
protocol
Physical Layer
ATM


72 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
The transport network plane is not applied to Iu PS, because the GTP tunnel is set up only via a tunnel identifier
and the IP addresses for both directions, which are already included in the RANAP RAB ASSIGNMENT mes-
sages.
2.2.5.3 RANAP Signaling on Iu
The Iu signaling protocol (RANAP, Radio Access Network Application Part) contains all the control information
specified for the Radio Network Layer.
The RANAP protocol is implemented by various elementary procedures. One or more of these procedures may
be executed for supporting the following functions:
Relocating serving RNC
This function allows you to change the serving RNC functionality as well as the related Iu resources (RAB(s)
and signaling connection) from one RNC to another.
Overall RAB management
This function is responsible for setting up, modifying and releasing RABs.
Queuing the setup of RAB
This function allows you to place some requested RABs in a queue and to indicate the peer entity regarding
the queuing.
Requesting RAB release
While the overall RAB management is a function of the CN, the RNC can request the release of RAB.
Release of all Iu connection resources
This function is used to explicitly release all resources related to one Iu connection.
Requesting the release of all Iu connection resources
While the Iu release is managed by the CN, the RNC can request the release of all Iu connection resources
from the corresponding Iu connection.
SRNS context forwarding function
This function is responsible for transferring SRNS context from the RNC to the CN for intersystem change in
the case of packet forwarding.
Controlling overload in the Iu interface
This function allows the load to be adjusted in the Iu interface.
Resetting the Iu
This function is used for resetting an Iu interface.
Sending the UE Common ID (permanent NAS UE identity) to the RNC
This function makes the RNC aware of the UE's common ID.
Paging the user
This function provides the CN for the ability to page the UE.
Controlling the tracing of the UE activity
This function allows the trace mode to be set for a given UE. It also allows the deactivation of a previously
established trace.
Transport of NAS information between UE and CN
Transport of the initial NAS signaling message from the UE to CN
This function transfers the NAS information transparently. As a result, the Iu signaling connection is also
set up.
Transport of NAS signaling messages between UE and CN
This function transparently transfers the NAS signaling messages on the existing Iu signaling connection.
It also includes a specific service for handling signaling messages differently.
Controlling the security mode in the UTRAN
This function is used to send the security keys (ciphering and integrity protection) to the UTRAN, and to setting
the operation mode for security functions.
Controlling location reporting
This function allows the CN to operate the mode in which the UTRAN reports the location of the UE.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
73
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Location reporting
This function is used for transferring the actual location information from RNC to the CN.
Data volume reporting function
This function is responsible for reporting unsuccessfully transmitted DL data volume over UTRAN for specific
RABs.
Reporting general error situations
This function allows reporting of general error situations, for which function-specific error messages have not
been defined.
Location-related data
This function allows the CN to either retrieve from the RNC deciphering keys (to be forwarded to the UE) for
the broadcast assistance data, or request the RNC to deliver dedicated assistance data to the UE.
Information transfer
This function allows the CN to transfer information to the RNC.
2.2.5.4 Iu User Plane Protocol
The Iu User Plane protocol is located in the user plane of the Radio Network layer of the Iu interface. It is used to
carry user data associated with RABs over the Iu interface, with each RAB having its instance of the protocol. This
means that whenever an RAB requires transfer of user data in the Iu user plane, an Iu User Plane protocol
instance exists at each Iu interface access point. These Iu User Plane protocol instances are established, relo-
cated and released together with the associated RAB.
The Iu User Plane protocol has two modes of operation:
Transparent mode
This mode is applied for RABs that do not require features from the Iu User Plane protocol and assume fully
transparent operation. In transparent mode the protocol does not perform any framing or control.
Support mode for predefined SDU sizes
This mode is applied for RABs that do require particular features from the Iu User Plane protocol in addition
to transfer of user data. In support mode the protocol performs framing of the user data into segments of pre-
defined size, procedure control functions and Non Access Stratum Data Streams specific functions.
Two versions for the support mode for predefined SDU sizes are supported:
version 1 introduced with Rel. 99
version 2 introduced with Rel. 5
For a detailed description refer to 3GPP 25.415.


74 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
2.2.5.5 Iu BC Interface Protocol Structure
Figure 50 Iu BC Interface Protocol Structure
2.2.5.6 CBS Application
CBS Application acts on both, the UE side and the CBC side:
On the UE side CBS Application is responsible for decompressing the CBS
message and activating/deactivating the CBS messages.
On the CBC side CBS Application is responsible for compressing the CBS
messages.
2.2.5.7 SABP on Iu
The Iu SMS-CB protocol (SABP, Service Area Broadcast Protocol) between RNC and CBC operates via Iu BC.
The CBC uses the SABP to
send new messages for broadcasting
replace already existing broadcasted messages
stop broadcasting of messages
ask for the load status of broadcast channels or the broadcasting status of a message
reset the broadcast channels
The RNC uses the SABP to report
acknowledging messages, including the information about whether the received request will be served or
not
failures of broadcast channels or other entities that cause the interruption of CBS
recovery of broadcast channels
errors in the messages
CBC
CBS
Application
UE
RNC
AAL5
IP
TCP
SABP
Node B
AAL5
IP
TCP
SABP
Uu
Iu-BC or
direct CBC-connection
PHY
MAC
RLC
RRC
BMC
PHY
MAC
RLC
RRC
BMC
BM-IWF
CBS
Application


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
75
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
2.2.5.8 Broadcast/Multicast Control
A BMC protocol entity exists above the RLC layer on the Iu User Plane residing in the MHC card. For each cell
one CTCH exists. BMC receives message broadcast requests from BM/IWF including the repetition period and
the number of broadcast (finite or infinite) to be done.
BMC is responsible for
Storing the CB messages
Transmitting the messages to the UEs after each repetition period of requested times for number of broadcast
2.2.5.9 Broadcast/Multicast Interworking Functionality
The BM/IWF checks if the request for SMS-CB can be served and distributes the CB messages received from
CBC to the BMC entities within the RNC. The broadcasting and scheduling of the messages on the Uu interface
itself is handled by the BMC entities.
BM-IWF is responsible for
Informing the CBC of any failure or out of service of BMC entities
Maintaining information about all CB messages to be broadcasted in its cells including information necessary
to estimate current load on CTCH
2.3 Transport Network Layer
The Transport Network Layer is responsible for operating and maintaining the transport resources that are
provided to the Application Layers, i.e. the Radio Network Layer (see Figure 26).
According to the 3GPP Standards, the TNL covers all transport resources within a UTRA network. This includes
the communication paths as well as the communication and signaling protocols on the user and control planes.
The TNL only deals with general data transport issues; all UTRAN specific data and protocols are confined to the
Radio Network Layer.
UTRAN uses ATM as the basic data transportation means providing a frame-based transmission (ATM multiplex-
ing) for an efficient utilization of resources. ATM transports data in a fixed block size of 53 bytes, each block con-
sisting of a 5 byte header and 48 byte payload data. These blocks are called ATM cells (see Figure 51).
Figure 51 ATM Multiplexing and ATM Cell Format
Traffic is routed between ATM end-points along virtual paths (VP or VPC, virtual path connection). Within a virtual
path, traffic is split up into several virtual channels (VC or VCC, virtual channel connection) which correspond to
distinct services or applications inside the end-point of a VP (see Figure 52). Thus, VPs and VCs represent a point-
to-point connection. For instance, there is a VP set up between the RNC and each of the Node Bs, and further
VPs are set up between the RNC and the OMC, neighboring RNCs, MSC and SGSN.
ATM cell
user 1
user 2
Header Data
5 byte 48 byte
53 byte


76 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Figure 52 ATM Virtual Paths and Virtual Channels
Within the RNC, ATM cross connections are used for OAM purposes: the Itf-B interface (implementation specific
OAM traffic between OMC and Node B) is routed through the RNC by means of an ATM VC cross connection that
links a Node B interface with the RNCs interface to the OMC.
The Transport Network Layer can be divided into the following sublayers:
Physical Layer
Within UTRAN, the physical layer utilizes SDH/SONET technology (STM-1/OC-3 optical fibres) and digital
lines in PDH technology (E1/J1/T1) with or without CES, IMA or Fractional ATM. CES and Fractional ATM
provide the possibility for collocation of GSM and UMTS entities.
Note: support of CES at RNC side requires external equipment.
Note: J1 lines are not yet supported by the OMC.
ATM Layer
User traffic and signaling data is transported via ATM virtual connections (VCs) on the data paths to and from
other network entities (peer RNCs, Node Bs, 3G-MSC, 3G SGSN).
ATM Adaptation Layer
Depending on the type of traffic, this layer contains AAL2 or AAL5 protocols.
Packet Oriented Transport Layer
This layer comprises the GTP-U and UDP protocols in the user plane and SS7 in the control plane between
RNC and 3G SGSN.
MSC Transport Layer.
Operation and maintenance tasks related to the Transport Network Layer are described in the OMN:RN-750
Transport Network Configuration Procedures.
Network
node

Network node
VP
VC
VC
Application
Application
Application
Application
Application
Application
Application
Application
Application
VP
Interface 2
VP
VP
Interface 1
Network
node
Network
node
Network
node
VP
VP
VP
VP


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
77
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
2.3.1 Circuit Emulation Service (CES)
Circuit Emulation Services (CES) is a consolidated and reliable mechanism that carries UTRAN and GSM traffic
on a common ATM transport network. When using CES to connect a GSM base station to a Node B, the network
is capable of carrying both UMTS Node B and GSM base station traffic on a common ATM-based transport
network. CES is applied whenever a Node B and a GSM base station are co-located in connection with an ATM-
based transport network. A Node B PF2 can also be connected to the RNC via the GSM transmission network
using the fractional Asynchronous Transfer Mode (ATM) service.
For detailed information see UMTS/GSM Co-Location Configuration and FD0122212a Circuit Emulation Ser-
vice.
2.3.2 Overbooking on Iub
Overbooking on Iub allows for improved line efficiency. Bandwidth is set up as a pooled resource that is shared
among all ATM virtual paths (VPs) of a line. While the available physical capacity remains unchanged, overbook-
ing allows a total logical bandwidth allocation of up to twice that value. Therefore it is possible to connect more
Node Bs, provided that their actual aggregate bandwidth usage never exceeds 100% of the lines physical capac-
ity. Overbooking on Iub is available for STM-1 lines connected to an external ATM switch and used for the Iub
interface. STM-1 lines used for Iu and Iur interfaces cannot be overbooked.
For detailed information see OMN:RN-750 Transport Network Configuration Basics and FD012225a Over-
booking on Iub.
2.3.3 AAL2 Ownership
AAL2 user plane VCs can be shared between several calls. A calls data packets are identified by their call iden-
tifier, CID, which is an 8 bit value. According to the actual traffic demands, CIDs are automatically allocated and
de-allocated from both ends of the connection. This means it is possible that two network nodes could simulta-
neously allocate the same CID for different calls. Such collisions can be minimized by declaring one NE as the
owner of the VC.
For detailed information see OMN:RN-750 Transport Network Configuration Basics.
2.3.4 Bandwidth Optimization During BRA
Bit Rate Adaptation and Admission Control both provide means to adapt the capacity of a radio link to actual traffic
demands. Bandwidth Optimization during BRA extends this flexibility to the transport network layer of Iub inter-
faces. Bit Rate Adaptation and Admission Control both provide means to adapt the capacity of a radio link to actual
traffic demands. Bandwidth Optimization during BRA extends this flexibility to the transport network layer of Iub
interfaces. This is done by modifying the bandwidth allocated to AAL2 connections that carry signaling bearers or
the data packets for RABs containing PS BE.
When an AAL2 connection is set up by the RNC, its initial bandwidth is chosen according to the actual rate rather
than the required rate as indicated by the setup request. Each time Admission Control or Bit Rate Adaptation are
invoked and the bandwidth of the radio access bearer is changed, the bandwidth of the associated AAL2 connec-
tion is modified accordingly.
For detailed information see OMN:RN-750 Transport Network Configuration Basics and FD012235 Band-
width Optimization during Bit Rate Adaptation (BRA).


78 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
2.3.5 DL Silent Mode on Iub
In DL normal mode the RNC sends an ATM frame for every transmission time interval (TTI) regardless of the frame
contains user data or not (i.e. the frame is empty). In silent mode the RNC is not required to send any DL data
frame, if there is no DL user plane data available. Thus, transmission bandwidth on Iub is used more efficiently.
DL silent mode on Iub is supported as standardized in TS25.427. For detailed information see FD012256 DL
Silent Mode on Iub.
2.3.6 Automatic Protection Mechanism for Faulty ATM Path
Within ATM networks, line faults are indicated by AIS (Alarm Indication Signal) and RDI (Remote Defect Indication)
OAM cells:
AIS is used to inform the neighboring network element (NE) in the forward (i.e.: downstream) direction about
a failure that was detected in backward direction. AIS are forwarded by all NEs until they reach the NE which
terminates the link that is affected by the failure.
RDI is used by the node terminating the link to inform the other terminating NE in the backward (upstream)
direction about a failure that was detected in forward direction.
The automatic protection mechanism automatically blocks faulty ATM Paths, prohibiting new calls to be assigned
on the VPs and VCs of the faulty ATM path. The RNC automatically sets the state of the VPs and VCs on the faulty
physical line to fault and stops setting up new connections on this line. An alarm message is still sent to the
Operator for notification. Radio Bearers whose AAL2 connections have been established on the failed physical
line are also released.
When the RNC stops receiving OAM cells with AIS and RDI indications, the states of the affected VPs and VCs
are changed back to use and an alarm recovery notification is sent to the operator.
For a detailed description see OMN:RN-750 Transport Network Configuration Basics and FD012262 Auto-
matic Protection Mechanism for Faulty ATM Path.
2.3.7 Support of AAL2 Switching in CN for Iur
If the Core Network features an AAL2 switching capability and the Iur traffic load is rather low, it is possible and
advisable to combine several Iur AAL2 links into one VC. All ATM cells are then sent to the AAL2 switching node
in the Core Network.
Support for AAL2 Switching in the Core Network adds more flexibility to the assignment of resources for the Iur
interface:
Direct point-to-point connections are justifiable in case of persistent high traffic loads.
Less demanding requirements can be met by installing Iur PVCs that are routed through the CN, using existing
Iu connections. However, this resource allocation is also static, and all Iur PVCs between all RNCs must be
installed beforehand.
If AAL2 switching in the CN is applied, connections are set up and deleted automatically as they are requested
from one of the RNCs involved. AAL2 switching in the CN is recommended for low traffic Iur connections.
For a detailed description see OMN:RN-750 Transport Network Configuration Basics and FD012234
Support of AAL2 Switching in CN for Iur.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
79
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
2.3.8 Extended SS7 Signaling
The SS7 protocol stack is a part of the transport network layer and used for carrying bearer signaling. Some oper-
ators have deployed networks using 24-bit instead of 14-bit signaling, In order to be compliant to the equipment
of such networks on Iu and Iur, the standard implementation of the SS7 protocol stack according ITU-T (14-bit
signaling) can be modified by the operator at the RNC by means of LMT commands to support the following stan-
dards:
MTP-3b according to YDN 102-1998 (B-MTP)
SCCP according to YDN 122-1999 (B-SCCP)
For a detailed description see OMN:RN-750 Transport Network Configuration Basics.
2.3.9 Modifications for HSDPA
HSDPA provides for higher data throughput per UE and per cell. In comparison to Release 99, HSDPA
allows user throughput of more than 384 kbit/s
increases the maximum cell data throughput from 1 Mbit/s to a theoretical maximum of 14.4 Mbit/s
Such increased data rates require either E1/J1/T1 IMA groups or STM-1/OC-3 lines for the Iub interface. The
maximum throughput is only achievable using STM-1/OC-3 lines. Using IMA, the cell data throughput is limited to
some 12 Mbit/s. On the Iub interface, HSDPA data is carried through the same AAL2 user plane VCs as is con-
ventional Rel 99 traffic. On the Iu interface, HSDPA data uses the same AAL5 user plane VCs as conventional
user plane traffic. HSDPA is not supported over Iur.
HSDPA is used for interactive and background traffic classes. This traffic is expected to exhibit pronounced bursts
that might use an Iub interface to full capacity. A flow control mechanism (see below) in combination with QoS
differentiation is introduced to allow for maximum Iub usage while at the same time providing that HSDPA traffic
does not interfere with Rel 99 traffic. In the event of congestion, HSDPA traffic is discarded first.
HSDPA is carried on the same ATM AAL2 VCs as is conventional traffic. Therefore, on the transport network layer
there are no configuration changes for HSDPA in comparison to conventional Release 99 networks. However,
because of the increased bandwidth requirements and the limited number range of call identifiers inside an AAL2
VC, it is necessary to configure more AAL2 user plane VCs on the Iub interface.
AAL2 user plane VCs can be shared between several calls. To facilitate this, the VC carries several AAL2 links
which each are associated with an individual call. AAL2 links are identified by their CID (call identifier) that is trans-
ported as an additional header byte of an ATM cell.
Each HSDPA user requires 3 CIDs to be allocated, which are used for UL DTCH (A-DCH), DCCH, and HS-DSCH.
Thus, HSDPA support adds the requirement for 1 additional CID to each call. If there are 64 HSDPA users to a
radio cell, and 3 radio cells to a Node B, the CID requirements add up to 576 CIDs per Node B. Since the CID is
an 8 bit number (ranging from 0 to 255; not all values are available for usage), at least 3 AAL2 VCs must be allo-
cated just to provide enough CIDs for a fully equipped HSDPA capable Node B.
For a detailed description see FD012249 Support of HSDPA.
2.3.10 HSDPA Traffic Separation and UBR+
With the introduction of HSDPA the PS interactive/background traffic will increase significantly. In order to maintain
the network and service quality and at the same time reduce the transmission cost for the network operator, the
features traffic separation and support of UBR/UBR+ at the Node B are introduced for the Iub interface. These
features focus on the traffic separation between the real-time and non-real-time traffic (e.g. R99 and HSDPA
traffic) and the support of Unspecified Bit Rate (UBR/UBR+) at the Node B.
Traffic separation on VP layer provides the functionality for the network operator to separate the Iub traffic based
on the quality criteria requirements with respect to delay and cell loss for R'99 and HSDPA traffic. The traffic sep-
aration mechanism, applies high statistical multiplexing to the bursty HSDPA data traffic inside the network while


80 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
for the R'99 traffic low delay paths are used. Thus, the network operator is able to exploit the ATM resources that
are not used by the higher QoS traffic by assigning them to be used for the best effort HSDPA traffic.
Together with the support of Unspecified Bit Rate (UBR/UBR+) in the Node B, the network operator is able to
reduce the transport cost due to the multiplexing gain in the intermediate ATM network and Node B. In general, it
is possible to separate not only HSDPA and R'99 traffic; but moreover, rt and nrt traffic can be separated (e.g.
OAM traffic can be put in the nrt VP). Of course the HSDPA traffic will be routed via an nrt traffic VP.
Earlier releases only support Constant Bit Rate (CBR), which is used for real-time services such as CS and PS
Streaming and Conversational traffic as well as for the R'99 best effort PS services. On the Iub the whole traffic
has to be treated as real-time, since the scheduling function is located inside the RNC. With the introduction of
HSDPA in the network, the best effort traffic (Interactive/Background) can be mapped to the Unspecified Bit Rate
(UBR/UBR+) service class. UBR provides an ATM bandwidth allocation service that does not guarantee any
throughput levels and uses only the available bandwidth, hence it becomes relevant for HSDPA traffic use. UBR+,
as an extension, provides a minimum guaranteed bit rate for the traffic assigned to it.
For a detailed description see FD012268 HSDPA traffic separation and UBR+.
2.3.11 IP/Ethernet at Iub
By means of the Pseudo Wire Emulation (PWE) mechanism the essential attributes of a service such as ATM over
a PSN are emulated. The required functions of PWs include encapsulating service-specific PDUs which arrive at
an ingress port. The PDUs are transparently carried across a path or tunnel, their timing and order and any other
operation required to emulate the behavior and characteristics of the service is managed by the PW functions.
ATM over PWE allows for the expansions of Iub bandwidth without the need to add expensive native ATM lines.
The following deployment options are supported:
Installation of new Node Bs, using only ATM over PWE for the Iub
Replacement of existing ATM connectivity of installed Node Bs with ATM over PWE
Expansion of existing ATM connectivity of installed Node Bs with ATM over PWE for additional Iub capacity
(e.g. to provide further bandwidth on Iub for HSDPA services)
For more information see Support of Iub Interfaces.
2.4 UTRAN Functions
This section describes basic functions of the UMTS Terrestrial Radio Access Network (UTRAN) such as:
Channel Coding/Decoding
Signal Flow in Node B/Radio Server and Remote Radio Head
HSDPA Iub Flow
Diversity
Power Control
Remote Electrical Antenna Tilt
2.4.1 Channel Coding/Decoding
Transport channels are encoded to provide reliable and high-quality radio transport services over the air. The per-
formance is optimized by a combination of Cyclic Redundancy Checks (CRC) and Forward Error Correction
Coding.
This section describes Node Bs channel encoding/decoding applied to Transport Channels (TrCHs).


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
81
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
2.4.1.1 Transport Channel Coding/Multiplexing
Data arrives at Node Bs coding/multiplexing unit in the form of transport block sets once every transmission time
interval. The transmission time interval depends on the specific transport channel from the set (10 ms, 20 ms, or
40 ms).
The coding/multiplexing steps are as follows:
Add CRC to each transport block
Transport block concatenation and code block segmentation
Channel coding
Rate matching
Insertion of Discontinuous Transmission (DTX) indication bits
Interleaving
Radio frame segmentation
Multiplexing of transport channels
Physical channel segmentation
Mapping to physical channels
From Figure 53 it can be seen that most processes are equal for uplink and downlink channels. They can be
divided into three groups:
Processing on transport block level
These operations are performed independently of another on the transport blocks of each single channel.
Processing on CCTrCH level
These operations perform the common functions for the transport channels, which are multiplexed on the
same CCTrCH (Coded Composite Transport Channel).
Processing on physical channel level


82 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Figure 53 Coding/Multiplexing Steps for Uplink and Downlink
Transport
channels
Physical
channels
CCTrCH
CRC attachment
TrBk concatenation/
Code block segmentation
Channel coding
Rate matching
1
st
insertion of DTX
indicating
1
st
interleaving
Radio frame segmentation
Spreading
2
nd
interleaving
Physical channel
segmentation
TrCH multiplexing
Processing on
transport block
level
Processing on
CCTrCH
Processing on
physical channel
level
level
Physical channel mapping
2
nd
insertion of DTX
indication
Spreading
2
nd
interleaving
Physical channel
segmentation
TrCH multiplexing
Physical channel mapping
downlink channel uplink channel
CRC attachment
TrBk concatenation/
Code block segmentation
Channel coding
Equalization
Radio frame segmentation
Rate matching
1
st
interleaving


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
83
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
2.4.2 Signal Flow in Node B/Radio Server and Remote Radio Head
Node B handles the uplink and downlink Radio Frequency (RF) signal. This section provides an overview of the
signal flow and a short description of the procedures involved.
Figure 54 and Figure 55 summarize the uplink and downlink signal flow in Node B. Figure 56 and Figure 57 show
the same for a Radio Server/Node B with Remote Radio Head.
Figure 54 Uplink and Downlink Signal Flow in Node B (REP-TRX-LPA Concept)
Tower Mounted
AmpIifier
Node B
DupIexer
Low
Noise
AmpIifying
Linear
Power
AmpIifying
Down-
conversion,
DemoduIation
SignaI
Distribution
(Broadcast)
Spreading,
ScrambIing
Despreading,
DescrambIing
(RAKE
SignaI
Distribution
(Routing)
A/D
Deinter-
Ieaving,
FEC
Decoding
A
T
M

S
w
i
t
c
h
i
n
g
,
I
u
b

P
r
o
t
o
c
o
I

H
a
n
d
I
i
n
g
,
N
o
d
e

B

C
o
n
t
r
o
I
Inter-
Ieaving,
FEC Coding
Up-
ModuIation
Receiver)
DupIexer/
AmpIifier/
MuItiCoupIer
(DUAMCO)
L
P
A
Transceiver (TRX) Repeater (REP) ChanneI Card (CHC)
Core
ControIIer
(CC)
Uu
interface
Iub
interface
(optionaI)
D/A
conversion,
AmpIifying
DL UL
DL UL
DL
UL
6&
RNC


84 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Figure 55 Uplink and Downlink Signal Flow in Node B (DRIC-CAT Concept)
Node B
Linear
Power
AmpIifying
Down-
conversion,
DemoduIation
SignaI
Distribution
(MuIticast)
Spreading,
ScrambIing
Despreading,
DescrambIing
(RAKE
SignaI
Distribution
(Routing)
A/D
Deinter-
Ieaving,
FEC
Decoding
A
T
M

S
w
i
t
c
h
i
n
g
,
I
u
b

P
r
o
t
o
c
o
I

H
a
n
d
I
i
n
g
,
N
o
d
e

B

C
o
n
t
r
o
I
Inter-
Ieaving,
FEC Coding
Up-
ModuIation
Receiver)
DigitaI Radio Interface Card (DRIC)
ChanneI Card (CHC)
Core
ControIIer
(CC)
Iub
interface
D/A
conversion,
DL UL
DL
UL
DigitaI
eIectr. IF CPRI
Radio IF
Tower
AmpIifier
(optionaI)
DL UL
Mounted
Low
Noise
AmpIifying
DupIexer/
AmpIifier/
MuItiCoupIer
(DUAMCO)
AmpIifying
DupIexer
Combined
AmpIifier and
Receiver (CAT)
D
i
g
i
t
a
I

e
I
e
c
t
r
.

I
F
C
P
R
I
R
a
d
i
o

I
F
Uu
interface
6&
RNC


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
85
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Figure 56 Uplink and Downlink Signal Flow in Node B (RRH/CAT Mixed Mode)
Node B
Down-
conversion,
DemoduIation
SignaI
Distribution
(MuIticast)
Despreading,
DescrambIing
(RAKE
SignaI
Distribution
(Routing)
A/D
Deinter-
Ieaving,
FEC
Decoding
A
T
M

S
w
i
t
c
h
i
n
g
,
I
u
b

P
r
o
t
o
c
o
I

H
a
n
d
I
i
n
g
,
N
o
d
e

B

C
o
n
t
r
o
I
Inter-
Ieaving,
FEC Coding
Up-
ModuIation
Receiver)
DigitaI Radio Interface Card (DRIC)
ChanneI Card (CHC)
Core
ControIIer
(CC)
Iub
interface
D/A
conversion,
DL UL
DL
UL
CPRI
Tower
AmpIifier
(optionaI)
DL UL
Mounted
Low
Noise
AmpIifying
DupIexer/
AmpIifier/
MuItiCoupIer
(DUAMCO)
AmpIifying
Combined
AmpIifier and
Receiver (CAT)
D
i
g
i
t
a
I

e
I
e
c
t
r
.

I
F
C
P
R
I
R
a
d
i
o

I
F
Interface & ControI
LNA
Remote
Radio
Head
LNA
PA
DupIexer FiIter
Ant 1 Ant 0
Transceiver
DigitaI Radio IF
eIectr.
IF
opt.
IF
CPRI
Spreading,
ScrambIing
opt. IF
DigitaI
Radio
IF
CPRI
Linear
Power
AmpIifying
DupIexer
Uu
interface
6&
RNC
Uu
interface
6&


86 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Figure 57 Uplink and Downlink Signal Flow for a RS/RRH Configuration
An overview of the procedures involved in the receiving and transmitting of signals is given below. The following
sections provide brief descriptions of individual procedures.
Radio Server
Spreading,
ScrambIing
SignaI
Distribution
(Routing)
Deinter-
Ieaving,
FEC
Decoding
A
T
M

S
w
i
t
c
h
i
n
g
,
I
u
b

P
r
o
t
o
c
o
I

H
a
n
d
I
i
n
g
,
N
o
d
e

B

C
o
n
t
r
o
I
Inter-
Ieaving,
FEC Coding
DigitaI Radio Interface Card (DRIC)
ChanneI Card (CHC)
Core
ControIIer
(CC)
Iub
interface
DL UL
DL
UL

Interface & ControI
LNA LNA
DupIexer FiIter
Ant 1 Ant 0
Transceiver
PA
Remote
Radio Head
(RRH)
opt. IF
DigitaI
Radio
IF
CPRI
Despreading,
DescrambIing
(RAKE
Receiver)
SignaI
Distribution
(MuIticast)
Uu
interface
6&
RNC


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
87
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Uplink signal flow
Amplifying (tower mounted amplifier; optional)
The RF signals received from the User Equipment (UE) are amplified before they enter the Node B.
Splitting
Within the Node B, the uplink RF signals are separated from the downlink signals by the duplexer of the
DUAMCO or the RRH-m.
Low noise amplifying
The RF signals are amplified before they are split into four identical outputs for the transceiver card by the
DUAMCO/RRH-m.
Downconversion and demodulation
The RF signals are converted first into Intermediate Frequency (IF) signals and then into digital baseband
signals by the TRX or by the CAT/RRH-m.
Signal distributing
The digitized baseband signals are distributed to the channel cards by the REP or by the DRIC.
Channel decoding
Within the CHC card the signals are despread and descrambled. Afterwards, the signals are decoded by de-
interleaving and Viterbi-decoding, and transmitted to the Radio Network Controller (RNC) via the Iub interface.
Downlink signal flow
Interleaving and encoding
The signals are encoded by interleaving and Viterbi-coding.
Signal distributing
The baseband signals are distributed to the TRX cards by the REP or distributed within the DRIC.
Spreading and scrambling
The digital signals are spread and scrambled.
Upconversion and modulation
The signals are converted first into analogue Intermediate Frequency (IF) signals, and then into Radio Fre-
quency (RF) signals by the TRX or by the CAT/RRH-m.
Linear power amplifying
The RF signals are amplified to a specific level by the LPA or by the CAT/RRH-m.
Combining
The RF signals are combined by the duplexer of the DUAMCO/RRH-m before they leave the Node B. The
combined signals are transmitted to the User Equipment (UE) via the antenna.


88 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
2.4.2.1 Uplink Path
Amplifying (tower mounted amplifier; optional)
Duplexers (DUP) separate and recombine TX and RX signals. Only uplink signals are amplified by the Low Noise
Amplifier (LNA) to compensate power loss that occurs during the transmission via the coaxial cable between the
external amplifier and the rack.
Node B supports RX diversity and therefore receives RF signals through both branch 0 and branch 1 antennas.
Figure 58 shows the signal flow in the external amplifier without TX diversity. If TX diversity is applied, the RX
antenna and the connected units are substituted by a TX/RX antenna and the corresponding units.
Figure 58 Signal Flow in the External Amplifier
Low noise amplifying
The RF signal power is amplified and split into four identical signals to support the different carriers of the
TRX/CAT cards or the RRH, see Figure 59.
Figure 59 Low Noise Amplifying and Power Splitting of the RX Signal
Downconversion and demodulation
The receiver part of the RRH or of the TRX/CAT card converts the RF signals into IF signals, see Figure 60. The
input signals within a range of 1920 MHz to 1980 MHz are first converted into IF1 signals with 130 MHz. The Root
Nyquist filter restricts the bandwidth of the IF1 signals to the level of a roll-off factor of 0.22. The filtered IF1 signals
DUP
DUP
R
X
Separates carrier
signals
Separates uplink signals
from downlink signals.
Amplifies uplink signals to
compensate for power
losses during transmission
via a cable between tower
mounted amplifier and rack
Antenna
To Duplexer Amplifyer Multi-Coupler
T
X
/
R
X
LNA
LNA
RX
Filter
RX TX
Combines uplink signals
with downlink signals.
R
X
1
R
X
2
R
X
3
R
X
0
From
amplifying
tower
To
receiver
part


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
89
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
are converted into IF2 signals with 7.68 MHz. The Automatic Gain Control (AGC) function and the negative
feedback function perform power control for the received IF signals to keep each of them at the same level.
Figure 60 Uplink Signal Flow in the Receiver Part
The analogue to digital (A/D) conversion part converts the IF signals into digital signals of 10 bit length, see Figure
61. These digital signals are sent to the orthogonal demodulation part where they are separated to In-Phase (I)
signals and Quadrature (Q) signals. Both signals pass through the Low Pass Filter (LPF) for bandwidth limiting
and are multiplexed on TD basis and converted from parallel to serial (P/S conversion).
Figure 61 Uplink Signal Flow in the Digital (A/D) Conversion and Demodulation Part
Channel decoding
Uplink data is despread, descrambled, deinterleaved and decoded within the CHC card. Uplink signal processing
involves four steps, see Figure 62.
Figure 62 Uplink Signal Flow at Channel Decoding
To A/D
RF --> IF1
Root
Nyquist
filter
IF1 --> IF2 AGC
RX
1920 - 1980 MHz
--> 130 MHz
Bandwidth
restriction
130 MHz
--> 7.68 MHz

#0
#1
From
Power
restriction
conversion
splitting
A/D
A/D
Orthogonal
Demodulation
Orthogonal
Demodulation
MUX
To channel decoding
Analogue to
Digital conversion
From
receiving
Interpolator
Part
Searcher
Part
Finger
Part
CODEC
Part
To RNC
From
A/D conversion
Rake Receiver


90 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
The interpolator part sends uplink signals both to the searcher part and to the finger part. Before the signals are
transmitted to the finger part, they are accumulated for a certain time period and sent to an interpolator. In the
interpolator, missing parts in a wave of signals are compensated with adjacent signals, see Figure 63.
Figure 63 Uplink Signal Flow in the Interpolator Part
The searcher part receives Pilot (PL) spread codes generated by the Pseudo Noise (PN) generator and applies
this code to the correlation analyser, see Figure 64. The searcher part obtains the correlative power level of the
signals. The correlative power levels are used to calculate power peaks that indicate multi-path locations for each
signal. The multi-path location information obtained is reported to the finger part.
Figure 64 Uplink Signal Flow in the Searcher Part
The G/A in the finger part de-spreads the signals, see Figure 65. G/A refers to Gate Arrey, i.e. functions performed
by hardware. After the de-spreading, the DSP estimates the channel for each signal and performs a RAKE receiv-
ing. The DSP sets the multi-path signal synthesis in proportion to the power level of each signal by using multi-
path location information reported by the searcher part. It also detects Signal to Interference Ratio (SIR) values
necessary for power control within the Node B network.
From
INT
To
To
Delay Control Interpolator
RAM
G/A
A/D conversion
searcher part
finger part
PN code
generator
Delay
control
Dual
port
RAM
Peak
detection
Correlative
power
From
interpolator
part
To
finger
G/A
DSP
part
Correlation
analyzer


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
91
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Figure 65 Uplink Signal Flow in the Finger Part
The G/A of the CODEC part performs either the Viterbi-decoding or the Turbo-decoding, depending on the signal
types received from the finger part.
The DSP of the CODEC part counts errors in the PL part of each signal to judge the signal frame synchronization.
DSP refers to Digital Signal Processor. After the signal frame synchronization, the signal is de-interleaved with the
Multi-layer Stage Interleaving (MIL) patterns and the Cyclic Redundancy Check (CRC).
Finally, the signals are converted into ATM cells and transmitted to the RNC. Figure 66 shows the uplink signal
flow in the CODEC part.
Figure 66 Uplink Signal Flow in the CODEC Part
Selector
De-spreading
PN
generator
Delay
control
Channel
estimation
RAKE receiving
SIR detection
port
RAM
Dual
From
interpolator
part
G/A DSP
To
CODEC
part
From finger part
Dual
port
RAM
G/A
Data format
conversion
To RNC
Viterbi
decoding
Turbo decoding
DSP
Frame
synchronization
De-interleaving
CRC
CODEC part


92 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
2.4.2.2 Downlink Path
Interleaving and encoding
The CODEC part executes the carrier encoding, which includes:
Cyclic Redundancy Check (CRC) bit addition
encoding for error collection
interleaving
mapping to physical channels
Figure 67 shows downlink signal flow in each function part.
Figure 67 Downlink Signal Flow in the CHC
Scrambling and Channelization Codes
A downlink scrambling and channelization code is assigned by the Controlling RNC each time a new radio link is
set up. Downlink orthogonality is achieved by filling the first scrambling code set completely before starting with
the second scrambling code set.
The code allocation algorithm in the CRNC is called to:
Initialize the tree
Reserve codes
Block the tree
Allocate a code
Release a code
The code allocation and code release specify interactions with the call processing protocols.
The channelization code for a given scrambling code is selected by the basic code allocation strategy:
All allocated/reserved codes are marked as used.
All codes are marked as unavailable that are blocked by used codes.
The blocked codes are:
all codes following the path from the used code up to the root of the code tree (ascendants)
all codes that follow the used code up to the leaves of the code tree (descendants)
A new code of type x (SF 2x-2) is allocated from the right hand side of the tree, i.e., the code with the smallest
number is chosen.
Figure 68 shows the basic code allocation strategy where each code is described by a tuple consisting of code
type and code number.
CODEC part
CRC bit addition
Encoding for error collection
Interleaving
Mapping to physical channels
From
RNC
spreading
To


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
93
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Figure 68 Allocation Strategy for Scrambling and Channelization Codes
Figure 69 illustrates the distribution of channelization codes and their related spreading factors for HSDPA.
Figure 69 Basic Code Allocation Strategy (Code Tree) for HSDPA
For detailed information see OMN:RN-750 Radio Network Configuration Basics and FD012249 Support of
HSDPA.
Spreading and scrambling
The multiplexed signals are spread. A channelization code per user and a scrambling code per sector are applied
for the spreading of one signal frame. For detailed information see OMN:RN-750 Radio Network Configuration
Basics. A first/second search code is applied for the spreading of each perch channel (SCH; Synchronization
Channel).
The spread perch channels are synthesized and the spread signals are multiplexed, see Figure 70.
(6,3)
(5,1)
(7,7) (7,6)
(8,15) (8,14) (8,13) (8,12)
(6,2)
(7,5) (7,4)
(8,11) (8,10) (8,9) )
AvaiIabI e Code
UnavaiIabI e Code
Used Code
NewIy aIIocated Code
Type=4, SF=4
Type=5, SF=8
Type=6, SF=16
Type=7,
Type=8, SF=64
SF=32
16
X X X
UnavaiIabIe Code (SF = X)


94 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Figure 70 Spreading of the Downlink Signal
Upconversion and modulation
The signals are separated into In-Phase (I) signals and Quadrature (Q) signals, see Figure 71. I signals and Q
signals are sent to the Root Nyquist filter for bandwidth restriction and then to the orthogonal modulation part for
frequency conversion. After Digital to Analog (D/A) conversion the signals are transmitted to the transmitter part
of the RRH or of the TRX/CAT card.
Figure 71 Downlink Signal Flow in the Modulation and D/A Conversion Part
The transmitter part converts the frequency first from 7.68 MHz to 130/320 MHz, and then to the range between
1920 MHz and 1980 MHz, see Figure 72. The Power Level Controller (PLC) part in the transmitter stabilizes the
gain of Radio Frequency (RF) signals.
Figure 72 Downlink Signal Flow in the Transmitter Part
Spreading
Spreading
Perch channel
search code
Channelization
code
Scrambling
code
Spread
code
+
Perch
channel
Separating
spread
codes
From
interleaving
To
upconversion
and
encoding
and
modulation
I/Q
separation
Root
Nyquist
filter
Root
Nyquist
filter
Orthogonal
modulation
D/A
To
From
spreading
transmitting
PLC
Frequency
conversion
7,68 MHz ->
130 MHz
130 MHz ->
1920-1980 MHz
PLC stabilizes
transmission
gain.
TX
From
D/A conversion
To power
amplifying
Frequency
conversion


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
95
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
2.4.3 HSDPA Iub Flow
With the support of highspeed downlink packet access (HSDPA), a credit-based flow control mechanism was
implemented between RNCs and HSDPA-capable Node Bs. As it is the Node B rather than the RNC which
controls the transfer rate on the Iub interface for HSDPA traffic, the Node B maintains buffers (priority queues)
storing the user data until it is transmitted over the Uu interface.
For a more detailed description of the flow control mechanism, refer to the FD012249 Support of HSDPA.
Compared to the initial support of HSDPA, enhanced HSDPA Iub flow control provides improvements with regard
to the following aspects:
Continuous loop control
The Node B periodically sends messages to the RNC, thus requesting the allocation of capacity for the HS-
DSCH. The actual repeat cycle time from one request to the next is defined by the vendor and will be in the
range of 100 ms to 1000 ms.
Implementing a continuous loop control has the effect of smoothing both the data rates at the Iub interface and
the filling level in the Node Bs user priority queues.
Credit allocation algorithm
The credit allocation algorithm has been changed in such a way that it is now based on the provided bit rate
(PBR) per user priority queue in the Node B. In other words, the data rate at the Iub interface is controlled by
the drain rate (PBR of the drain) rather than by the UEs channel quality information (CQI).
The reason for this change is the following: the CQI provides only an indication of the maximum rate the UE
can support with predefined error detection during the first transmission. The PBR, in contrast, is the actual
rate currently supported by the UE.
These two enhancements result in a reduced burstiness of the traffic at the Iub interface leading to both less cell
losses in the event of congestions and better performance toward the UE with regard to throughput and delay.
For a detailed description see FD012269 HSDPA Iub Congestion and Flow Control.
The functional split of HSDPA Iub flow control comprises the following:
RNC
the flow control mechanism is located in the highspeed downlink shared trunk (HSDST) cards. It interacts with
the following:
Radio link control (RLC) protocol in the highspeed packet radio link controller (HSPRLC) cards
HS-DSCH frame protocol (FP) in the HSDST cards
For more information about modifications in the RNC which are necessary for the support of HSDPA, refer to
the relevant chapter in the FD012249 Support of HSDPA.
Node B
the flow control mechanism interacts with the HS-DSCH FP and the scheduler. The scheduler, like the priority
queues, are part of the MAC-hs layer. For more information about the MAC-hs layer in the Node B, refer to the
relevant section of the FD012249 Support of HSDPA.
Figure 73 provides the functional mapping of user plane (U-plane) and transport plane (T-plane) functions to the
relevant cards in the RNC and the Node B.


96 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Figure 73 Mapping of U-/T-Plane Functions to Cards
2.4.4 HSDPA Scheduler
The HSDPA scheduler has got a key role in the MAC-hs (see Figure 73). The scheduler for HSDPA traffic is imple-
mented in the Node B rather than in the RNC, where the scheduler for Rel 99 traffic is situated.
One of the main characteristics of HSDPA is the shared channel (HS-DSCH). By means of this channel, multiple
UEs can be served on the downlink. The Node Bs scheduler for HSDPA controls the access to the HS-DSCH.
Based on criteria such as quality of service (QoS) demands, channel qualities, and queue lengths, for example,
the HSDPA scheduler selects the UEs to be served and assigns transmit resources accordingly.
In general, the HSDPA scheduler is responsible for the following three major steps. The scheduler executes these
steps in the order provided:
1. Selecting a subset of UEs to be served in a specific transmission time interval (TTI)
The subsequent processing steps are only applied to the selected subset.
2. Deciding whether new data is initially transmitted to the selected UEs or whether HARQ retransmission is
applied for the selected subset of UEs
The scheduler takes the following parameters into account:
HARQ process to be selected
Redundancy version
Modulation scheme
Transport block size
HSDPA transmit signal power
TNL
Node B
Scheduler
MAC-hs
Priority
Queues
AAL2
RNC
Flow
Control
Flow
Control
HS-DSCH
FP
HS-DSCH
FP
RLC
HSPRLC
HSDST
WCMP
DHT
PRLC
CC
CHC
further
proceeding
to VC at Iub
VP
VC1
VC2
HS-PDSCH
Iub
PS traffic (HSDPA)
HS-DSCH FP
Capacity allocation
PS traffic
Control signals
(credits, etc.)
(non-HSDPA)


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
97
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
3. Managing the HSDPA air interface resources
This processing step includes the assignment of the following:
Channelization codes and transmit power for HS-PDSCHs
Channelization codes and transmit power for HS-SCCHs
Operators can specify the number of channelization codes via the RNCs LMT or via Radio Commander.
The HSDPA scheduler algorithms allow operators to control the trade off between maximization of system
throughput and user fairness. The following scheduling types are implemented in the Node B:
Max-CIR (maximum carrier- to interference-power ratio) scheduler
Proportional Fair scheduler
While the Max-CIR scheduler maximizes the cell throughput, the Proportional Fair scheduler provides a fair share
of the total throughput to each user, i.e. it optimizes the user throughput. Maximum cell throughput and maximum
user throughput are mutually exclusive, i.e. cell throughput and user fairness can not be optimized simultaneously.
In this context, user throughput, on the one hand, means the number of bits of the application packet transmitted
in the time between creation of the application packet and the end of transmission of all data, i.e. the ratio of all
information bits correctly received on one link by one user to the transmission time. Cell throughput, on the other
hand, is defined as the aggregate number of information bits correctly received in a cell, in which at least one UE
has waiting data, per TTI.
In addition, the Traffic Handling Priority (THP) scheduler algorithm allows differentiating between multiple sub-
scriber classes and the QoS levels. The THP scheduler is backwards compatible to the scheduler types of the
initial HSDPA implementation.
THP scheduling is provided from CN towards RNC. The RNC maps the THP to Scheduling Priority Indicator (SPI)
levels and provides information to Node B. SPIs are assigned to the priority queues in the Node B. For each SPI
a weighting factor may be configured. The THP scheduler respects weights for UE selection.
For a detailed decription see:
FD012249 Support of HSDPA
FD012251 Proportional Fair Scheduler for HSDPA
FD012298 HSDPA THP Scheduler
2.4.5 Diversity
This section describes the diversity functions in Node B. Diversity is a means of improving connection quality,
mobility and link susceptibility to interference.
The diversity functions are categorized as follows:
Receiving diversity
Macro diversity
2.4.5.1 Receiving Diversity
Node B implements receiving diversity via the RAKE receiver concept (see Figure 74). A RAKE receiver has a
number of RAKE fingers. Each of these RAKE fingers changes (by despreading) broadband signals with different
delays from the same source (i.e. with the same spreading code) back into user information by using the spreading
code. This can be done because the different RAKE fingers apply the spreading code with delays. The RAKE
receiver receives signals from many paths over the radio link. The path selector in the RAKE receiver selects the
(at the most) 8 best paths by using the delay profile information transmitted from the searcher part. The path
selector sends the signals from the selected paths into each finger in the finger part. The signal input to each finger
is despread using the Pseudo Noise (PN) code specified by the path selector. The channel estimator removes
fading vectors from the signals obtained by despreading. The Automatic Frequency Control (AFC) function adjusts
frequency shift. The signals input to each finger are synthesized according to their Signal to Interference Ratio
(SIR) value.


98 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Figure 74 Receiving Diversity via the RAKE Receiver
2.4.5.2 Macro Diversity
Within UTRAN, multiple radio links can be established simultaneously between a UE and Node Bs, e.g. a UE can
have three radio links carrying the same UMTS radio bearer. This allows smooth handover without any commu-
nication disconnection when the UE moves from one cell to another, see Figure 75.
Figure 75 Handover Controlled by Macro-Diversity Function
/PEF#
6&
MuItipIe Path Propagation
Path2
d2, a2
Path1
d1, a1
Path4
d4, a4
Path3
d3, a3
d = deIay
a = attenuation
/PEF#
/PEF#
/PEF#
/PEF#
/PEF#
/PEF#
/PEF#
6&
6&


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
99
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
2.4.6 Power Control
Fast power control is essential in Code Division Multiplex Access (CDMA) systems in order to:
Reduce interference
Maintain connection quality
Optimize system capacity
Maintain output power requirements
In the FDD mode two methods of power control exist:
Open Loop Power Control
Unidirectional power control mechanism that allows the transmitter, that is the UE in UL, to autonomously
control its transmit power. No feedback is sent by the distant end, that is the Node B on the DL side.
Closed Loop Power Control
Bidirectional power control mechanism, where the sender and the receiver send power control information to
each other and control their own transmit power according to the feedback from the distant end. The closed
loop power control mechanism is based on the Signaling-to-Interference Ratio (SIR). It consists of two stages:
Inner Loop Power Control
Outer Loop Power Control
The UE enquires the initial power by open loop power control. The closed loop power control, however, allows a
UE to determine the transmit power for setting up a call.
Figure 76 shows the principle of closed loop power control in the FDD mode.
Figure 76 Closed Loop Power Control in the FDD Mode
For a detailed description see OMN:RN-750 Radio Network Configuration Basics.
2.4.6.1 Open Loop Power Control
The power loss due to transmission distance increases with the distance between Node B and the UE.
In the uplink, the open loop power control allocates the initial transmission power of the UE when it attempts
random access to Node B. The UE automatically adjusts its output power according to the last power level
received.
In the downlink, the open loop power control adjusts Node Bs initial transmission power according to UE mea-
surements (if available) and service requirements.
This initial control can only be coarse because the UL and DL attenuations (for FDD) can differ.
For a detailed description see OMN:RN-750 Radio Network Configuration Basics.
S/Ndef
PC algorithm
SIR
estimate
Change
transmitting power
+
S+I
TPC
I
Outer Loop
Inner Loop
SRNC
Node B
UE


100 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
2.4.6.2 Inner Loop Power Control
The inner loop power control is essential for a CDMA system because CDMA is very sensitive to overpowering. It
requires signal balance within a tolerance of less than 1 dB.
The received power level at Node B is not simply proportional to the Signal-to-Interference Ratio (SIR) value
measured at the UE, and the received power at the UE is not simply proportional to the SIR value measured at
Node B. This is because the signal fading due to the UEs movement affects the received power level. In a mobile
scenario, signal fading due to the UEs movement can cause changes of more than 15 dB in the received power
level.
The inner loop power forces signals from the different UEs to arrive with a power level at Node B that is predefined
by the applied services.
Inner loop power control is set up between the Node B and the UE and takes a predefined signal-to-interference
ratio (SIR) as input (target SIR). It is performed every time slot. The receiver, that is the Node B in the uplink, first
measures the SIR of the received signals and compares the measured value with the target SIR. Based on the
comparison result, the receiver sends a power increase/decrease command to the sender, that is the UE in the
uplink. Due to this command, the sender can adjust the quality of the received signal closer to the target.
The inner loop power control determines:
UL DPCCH/DPDCH Tx Power Setting
DL DPCH Tx Power Setting
These instructions are contained in the TPC (Transmit Power Control) field in every radio slot. Therefore, the
power control interval is 0.667msec.
Multiple Radio Links (RLs) are established for each UE during diversity receiving or during handover processing.
The output power that is required for downlink transmission on an RL may differ from that of another RL. The
SRNC allocates Node B a reference value for downlink transmission to control such differences. Node B adds
higher and lower margins and keeps its output power level within the specified range.
For a detailed description see OMN:RN-750 Radio Network Configuration Basics.
2.4.6.3 Outer Loop Power Control
Outer loop power control (OLPC) maintains a predefined connection quality in terms of block error rate by setting
the target of the inner closed-loop power control appropriately. The SIR is kept at its optimum value, which serves
to maximize system capacity and to minimize power consumption in the hardware at both ends of the connection.
Furthermore, interference with other radio links that share the same cell and frequency channel is kept to a
minimum.
The process of outer loop power control includes:
The estimation of the target average BLER from the received signal quality measured over a rather long time
interval
The setting of the SIR to maintain this target
Outer loop power control is performed for each Dedicated Channel and the set SIR is then used in the Inner Loop
Power Control mechanism as the SIR target when performing feedback control. For FDD radio links, the OLPC
function itself is located in the SRNC.
For a detailed description see OMN:RN-750 Radio Network Configuration Basics.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
101
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
2.4.6.4 Power Balancing
When a UE is in soft handover state, the downlink transmission power of the Node Bs connected to that particular
UE is balanced, in other words power drifts should not occur. That is because the Transmit Power Control (TPC)
commands are common to all of the Node Bs connected to a particular UE. The transmitted TPC commands,
however, might be corrupted. This results in an imbalance in the DL transmission power of the UEs radio links,
see Figure 77. One of the Node Bs might increase or decrease the transmitted power resulting in an increase in
interference or in a loss of diversity gain. In both cases, a loss of traffic capacity in the DL will be incurred.
Figure 77 DL Power Drift Between Radio Links
The objective of DL power balancing is to gradually change the DL transmission power of the involved Node Bs
towards a certain reference value. Thus the drift in the DL transmitted powers of the Node Bs, resulting from the
erroneous TPC, is reduced without any interference to the Inner Loop Power Control procedure.
Power balancing is used for UE contexts that have multiple Node B communication contexts. It is activated,
however, as soon as one Node B communication context exists. This avoids power balancing being regularly
switched on/off when the UE context commences/ceases to have multiple Node B communication contexts (see
Figure 78).
No power i ncrease/decrease
DL transmission power
increase/decrease according
to the power control mechanism
Power drift
between
the radio links
TPCcommand
TPCerror
TPCcommand
X
6&
A
/PEF#
B
/PEF#


102 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Figure 78 UE with Multiple Established Radio Links
Power balancing is supported by both the SRNC and DRNC. The SRNC uses 3GPP Release 99 procedures. For
more information on the handling of 3GPP Release 5 IEs from other vendors SRNCs in the DRNC see FD012236
3GPP Baseline Change to Rel.5. Furthermore, this feature description provides information on the Node B
requirements for power balancing.
Power Balancing Algorithm
Downlink (DL) Power Balancing provides a method for balancing the DL transmission powers of the existing radio
links of a UE with multiple Node Bs. It allows the DL power level of one or more radio links to be adjusted in order
to eliminate the DL power drift problem between the radio links because of TPC errors. The power balancing pro-
cedure is used in conjunction with the inner loop power control procedure in the DL.
The status information about inner loop power control contained in the RL SETUP REQUEST message is always
set to inactive at the setup of a new radio link. The inner loop power control procedure is only activated by the
DL POWER CONTROL REQUEST message. DL power balancing is started simultaneously. The power drift
between a new link and any existing links is thus avoided.
For a detailed description see OMN:RN-750 Radio Network Configuration - Basics.
2.4.6.5 HSDPA Power Management
When HSDPA performance is degraded below a critical level, the RNC applies smart power resource manage-
ment to retain some DCH power resources (with interactive/ background QoS only) in order to stabilize the HSDPA
bearers.
HSDPA power management relies on the following parameters:
Power which can be used for HSDPA, P
usable
Pusable is the maximum power which can be used allocated to HSDPA users. This parameter is normalized by
the maximum downlink (DL) transmission power.
HSDPA power utilization, U
p
After having updated Pusable, the RNC recalculates Up, too. Up indicates the utilization ratio of Pusable taking
into consideration the threshold set for the usable power for admission control THR
AC_Pusable
.
For a detailed description, please see FD012267 HSDPA Resource and Power Management.
Node B#3 Node B#1
TPCCommands
Node B#2
6&


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
103
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
2.4.7 Remote Electrical Antenna Tilt
Antennas with a remote downtilt functionality are well known in RADAR systems. For mobile communication
systems such antennas can help to adapt the installed radio and baseband capacity to special traffic demands.
Demands for higher capacity can occur for instance as hot spots temporary within stadiums or public festivals.
Moreover such kind of antennas support a realtime network configuration in case of network expansion and net-
work/site failure.
Technical solution
An industrial standards has been produced by the Antenna Interface Standards Group (AISG) to ensure the basic
interoperability of antennas and control infrastructure. The Siemens/NEC solution complies to this standard and
consists of an RET module containing a stepper motor which adjusts a phase shift within the antenna. The stepper
motor is controlled via an RS485 interface connected to the TMA. Signaling and DC power from the DUAMCO to
the RET module via the TMA and vice versa is transported through the antenna feeder cable. The stepper is
located directly under the antenna.
For a detailed description of the technical solution please see:
TED:UTRAN NB-880/NB-881/NB-881HR
TED:UTRAN NB-860/NB-861
TED:UTRAN NB-440/NB-441
TED:UTRAN NB-420
TED:UTRAN RS-880/RRHs
TED:UTRAN RS-381/RRHs
TED:UTRAN RSSU-380/RRHs
TED:UTRAN RSCU-380/RRHs
Network performance enhancement
The reduction of interference for network performance enhancement requires careful adjustment of the vertical
antenna tilt during the following phases.
Remote Tuning During Initial Network Deployment
Remote Re-configuration During Network Expansion
Remote Re-configuration due to Node B Failure
Re-configuration During Network Optimization
During all these phases the antenna tilt must be adjusted not only at one site but also within a cluster of sites. The
corresponding workflows for the tilt adjustment are handled in offline planning steps. In addition to these offline
planning steps, adjustments of the antenna tilt will in future be required on short-term cycles. Short-term changes
of the vertical antenna tilt allow for flexible reaction to fluctuations in the inhomogeneous traffic distribution and
variations of the user behaviour. Traffic varies within one cell and/or within a cluster of cells (hotspots) during the
day. The relationship between interference, coverage and capacity can be exploited by online procedures to effi-
ciently deal with such inhomogeneous network situations.
The possibility of remote adjustment of the vertical tilts increases the flexibility during the different network deploy-
ment phases by offering the possibility of several fine-tuning cycles. This means:
Flexibility during the network tuning/optimization immediate change of configuration during the drive test
fast verification and interactive fine tuning
Regular adjustment of the antenna tilt due to network evolution and expansion without manual change at the
site
Fast redesign of cell layout in the case of Node B failure period of network unavailability in affected network
area is minimized by increasing the coverage of neighbouring cells
Regular adjustment of vertical tilts throughout a site cluster to cope with time-dependent traffic distribution and
subscriber behaviour resulting in possible network congestion (e.g. twice a day)
First step to automated network tuning with short update periods for tilt adaptations to cope with dynamic traffic
behaviour


104 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
All these application cases can be performed without access to the site, without service staff at the site and without
any time delay. Changes of the antenna tilt can be performed from the OMC and LMT-Node B without any addi-
tional costs and with maximum time efficiency. For more information on operation and maintenance aspects see
Remote Antenna Downtilt.
2.4.7.1 Remote Tuning During Initial Network Deployment
The rollout of UTRA-FDD will be performed in certain phases and begins typically in the dense urban, urban and
partly in suburban areas. Subsequent phases will enlarge the coverage area to suburban, rural and highway
areas.
The networks will be firstly driven by coverage demands and will not severely be limited by interference due to
high traffic situations. Therefore the need for the adjustment of the vertical tilt is not initially driven by the require-
ment for reduction of interference, but by the need especially to obtain maximum coverage at the coverage border
of each rollout cluster. The additional deployment phases require a careful adjustment of the transition areas
between existing Node B clusters and new Node B clusters. Several tilts have to be adjusted and re-tuned during
different deployment phases.
In general an optimization requires several iterations of re-adjusting the vertical tilt angles. Instead of visiting each
site several times, a remote adjustment shows benefits already for the initial tuning in low loaded networks.
2.4.7.2 Remote Re-configuration During Network Expansion
The network expansion in the sense of increasing the Node B density due to coverage and capacity reasons will
require also adjustments of the antenna tilts of the new cells and the neighboring cells. Depending on the site
heights, antenna alignments and topography, at least the first and second tier of neighboring cells will have to be
considered.
The vertical tilts are defined off-line with support of planning tools. The vertical tilts of the new Node B can be fixed
during the first installation. The tilt changes of existing Node Bs do not require any effort at the impacted sites if a
remote adjustment is available.
2.4.7.3 Remote Re-configuration due to Node B Failure
In case of a Node B failure, the lack of coverage within that spot can be easily reduced by remote change of the
vertical antenna tilt without any significant time delay, network unavailability and extra costs for service.
The change of the vertical tilt at neighboring sites reduces coverage problems as shown in Figure 79. Even for
short service interruptions of a Node B, fast compensation via neighboring cells is feasible due to the remote
control of the antenna tilts.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
105
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Figure 79 Node B Failure and Controlled Coverage Increase with Adjacent Cells
2.4.7.4 Re-configuration During Network Optimization
Cell shape Coverage enhancement
The cell shapes are defined by the antenna alignment of all adjacent cells. The main targets for the cell layout are:
Sufficient coverage at the cell borders for optimal grade of service and handover performance
Reduction of interfering signal level at horizon influence on neighboring cells
Figure 80 provides a schematical view of the optimized coverage area adjustment.
Figure 80 Optimized Coverage Area and Reduced Interference at Adjacent Cells
Load balancing Capacity enhancement
An obvious and straightforward load balancing method is to change the cell area depending on the offered traffic.
The antenna tilts are typically determined in a planning tool, in which simulations are carried out based on assump-
tions regarding traffic volume and traffic distribution. In live networks, the traffic sources and volume are distributed
inhomogeneously over time and area. If cells have to carry much higher traffic volumes than neighboring cells,
traffic redistribution can be achieved by adjusting he cell areas to the local traffic distribution. This relaxes possible
cell congestion.
Figure 81 shows the schematic cell layout adjustment with respect to different cell loads.
Failure of cell/site
Controlled cell size increase
via change of tilt
Interface reduction
at horizon by down tiIting
Optimized area coverage adjustment


106 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Figure 81 Cell Load-Sharing Deployed in Inhomogeneous Load Scenarios
Two neighbouring cells carry different traffic volumes (left part of the picture). If the cell area of the high loaded cell
is reduced, the traffic will be also reduced (assumption homogeneous traffic distribution within the cell). The area
of the neighbour-cell is increased and takes over traffic from the loaded cell. At the end the traffic in the high loaded
cell is reduced whereas the traffic in the former low loaded cell is increased.
Pilot Pollution - CPICH
The interfering signal power comprises several interfering cells. At the own cell side, the assigned output power
to the CPICH can be increased. But this reduces the available output power for traffic channels on the downlink
leading to a reduction of available capacity. An appropriate means will be the adjustment of the vertical tilt of the
serving antenna. For more information see UTRAN Cell.
Soft Handover Area
The SHO area between neighboring cells strongly depends on the cell layout plan. Typically, about 30%-50% of
users are in SHO in case of homogeneous traffic distribution. These users occupy additional HW resources in the
Node B. In live networks, the traffic will be distributed in-homogeneously within the cell area. Therefore even more
users might be in SHO (traffic accumulation in SHO area) and require additional HW at the Node B. The control
of the SHO areas can be performed by system parameters and with an appropriate design/tuning of the vertical
tilts of the antennas. The change of the tilt setting will significantly influence the SHO area (overlapping of cells)
and the location of the SHO area between the cells. For more information see Relocation and Handover.
2.5 UTRAN Cell
A UTRAN cell is a radio network element that can be uniquely identified by a UE from a cell identification that is
broadcast over a geographical area from one UTRAN access point, i.e., Node B. Cells are the basic elements of
the whole network. Depending on the traffic, a cell can cover a radius of up to several kilometers.
2.5.1 Cell Types
With respect to cell coverage and determined by maximum transmit power in each cell three types of cells have
to be considered:
Macro cells
are preferred for rural areas.
Micro cells
are preferred for urban zones, e.g. streets, commercial zones, stadiums.
Pico cells
mainly provide indoor coverage, e.g. for office buildings, hotels, airports.
With respect to the radiation pattern two types of cells have to be considered:
Omnidirectional cells
reach out in all directions from its hosting Node B.
high Ioad Iow Ioad medium Ioad medium Ioad
medium
intra
medium
intra
high
intra
low
intra


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
107
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Sectored cells
cover a sector of e.g. 120, seen from the Node B. In this example, a set of three cells is necessary to provide
access from all directions.
2.5.2 Cell Area
The cell area is basically defined by the CPICH coverage. The criterion for the CPICH quality is the received
Ec/N0. The CPICH quality to meet the required Ec/N0 for bit rate, kind of service and mobility of the user depends
on:
CPICH output power
Thermal and receiver noise
Path loss
Fading
Interference situation (affected by the cell load factor)
depending on number, bit rate and activity factor of the users
Antenna factors such as sensitivity, gain and possibility to soft HO, and antenna tilt
One can assume that e.g. Ec/No = -15dB ensures a good quality whereas lower requirements lead to decreased
quality and vice versa. The critical Ec/No area is at the cell border where the interference level is high and the
signal strength of the CPICH is week, see Figure 82.
Figure 82 Critical CPICH Area (Schematic)
Because a cell can only accommodate a limited number of subscribers and transport a limited amount of traffic, a
larger number of (smaller) cells must be used to cover areas where more traffic is expected. Traffic hot-spot areas
are highly populated areas, trade fare centers or railway stations. The number of cells per site is defined by the
number of cells per frequency and the number of available frequencies per operator.
Because of the comparably small size of UTRAN cells and high mobility of subscribers, a subscriber will not be
found dwelling in a certain cell for extended amounts of time. When reaching the end of the coverage area of a
cell, an ongoing call needs to be transferred to a neighboring cell. This transfer is known as a handover, see Relo-
cation and Handover.
Cell Service/
Critical CPICH area
Coverage Area
Antenna direction
CPICHi


108 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
2.5.3 Supported FDD Frequency Bands
2.5.4 Cell Sets
Three sets of cells can be distinguished:
Active set
Radio links are established between active set cells and the UE. All cells in the active set send user informa-
tion. In FDD, the cells in the active set are directly involved in soft handover. The maximum size of the active
set is configurable.
Monitored set
Cells in the monitored set are monitored according to a neighbor list assigned by the UTRAN.
Detected set
Cells in the detected set are detected by the UE but neither included in the active set nor in the monitored set.
Measurements of the detected set are only reported for intrafrequency measurements performed by UEs in
Cell_DCH state.
Figure 83 shows cells in the active set an in the monitored set.
Figure 83 Cells in the Active Set and in the Monitored Set
Reference Operating
Band
Area UL Frequencies
UE transmits,
Node B receives
DL frequencies
UE receives,
Node B transmits
TX-RX frequency
separation
(duplex distance)
FDD 2100 I World market
networks
launched
1920 - 1980 MHz 2110 - 2170 MHz 190 MHz
FDD 1900 II USA,
Latin America
1850 -1910 MHz 1930 -1990 MHz 80 MHz
FDD 1700/2100 IV USA 1710 - 1755 MHz 2110 - 2155 MHz 400 MHz
FDD 850 V USA,
Latin America
824 - 849 MHz 869 - 894 MHz 45 MHz
FDD 900 VIII Europe 880 - 915 MHz 925 - 960 MHz 45 MHz
Table 3 UTRA/FDD Frequency Bands
6&


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
109
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
2.5.5 Adjacent Cells
To provide effective support for network management and call handover, the spatial relationships between cells
must be specified. A cell must know which cells are its neighbors.
Adjacent UTRAN cells
An adjacent UTRAN cell (hereafter simply adjacent cell) is a cell that is a physical neighbor of another cell
in a network. For every cell, information about its adjacent cells must be provided. Adjacent cell information is
a result of network planning.
Adjacent GSM cells
Since some UMTS networks might be unable, at least initially, to provide universal coverage, a means must
be provided to hand over calls to neighboring GSM cells. Therefore, adjacent GSM cells need to be registered.
External cells
External cells must be configured to communicate with cells belonging to another RNC or GSM network, in
order to provide handovers if the user equipment (UE) leaves a coverage area during an ongoing call. External
cell relationships are specified at the RNC level as follows:
UTRAN cells are external cells if they belong to another RNC area.
GSM cells are always external within a UTRAN network.
For detailed information see OMN:RN-750 Radio Network Configuration Basics.
2.5.6 Cell Individual Offset
The load among neighboring cells can be balanced by the cell individual offset on adjacent cell level. Thus, unnec-
essary often soft handover in special areas, e.g. crossings, can be avoided by shifting the cell borders of a single
neighbor relation. The network is optimized on a single cell relation level by adapting the cell form according to
special geometric requirements on adjacent cell level.
The offset can be positive or negative, the UE will add this offset to the measurement quantity before it evaluates
whether an reporting event has occurred:
Decreasing the cell individual offset of a cell
UEs in this area will tend to moved to this cell.
Increasing the cell individual offset of a cell
UEs will move away or will not be invited to this cell.
For detailed information see OMN:RN-750 Radio Network Configuration Basics and FD012220d Cell Indi-
vidual Offset.
2.5.7 Master Cells
As part of restarting the measurements, the TRNC must determine the master cell for the Cell Individual Offset
and Cell Specific Handover Parameters features. It is defined as the cell for which UE has reported the highest
downlink CPICH Ec/N0 or CPICH RSCP or smallest path loss value in the latest RRC Measurement Report
received in the RRC Container. In case none of these quantities are reported by the UE then the selection of
master cell within TRNC is an implementation matter.
In order to determine the Cell Individual Offset and to choose the target cell when triggering Blind ISHO (see
FD012264 Service and Load Based Handover), TRNC must figure out the order in which the cells were added
to the active set. TRNC will decide this order based on the quality of each cell reported by the UE in the latest RRC
Measurement Report in the container.


110 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
2.5.8 HSDPA Mobility
The High Speed Downlink Shared Channel (HS-DSCH) is a common transport channel that is shared by several
UEs in the same cell. The MAC-hs functionality of the Node B performs scheduling of UEs on a per cell basis.
Therefore, the UE receives the HS-DSCH of one cell and can receive DCHs of multiple cells. The cell where the
HS-DSCH is currently established is called the serving HS-DSCH cell. The quality of the serving HS-DSCH cell
constantly varies due to the mobility of the UE. If the quality is degraded or the serving HS-DSCH cell is deleted,
the SRNC needs to move the serving function to another cell where the quality is good. Furthermore, the UE may
enter or leave the area where HSDPA is supported. In this case, the SRNC performs channel-type switching from
DCH to HS-DSCH or from HS-DSCH to DCH.
The following UE mobility scenarios are supported:
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
For a detailed description see FD012249 Support of HSDPA.
Compared to the initial introduction of HSDPA, enhanced mobility procedures are provided in order to increase
the chance of subscribers to have PS data communication on HS-DSCH. Furthermore, multiple frequencies with
HSDPA are supported and the capacity for HSDPA increases.
HSDPA mobility enhancements comprises the following:
Enhancement of the UE Differentiation Procedure
Blind Inter-Frequency Handover with HS-DSCH
Compressed Mode for Inter-Frequency Measurement with HS-DSCH
Inter-Frequency Handover with Inter-Frequency Measurement
Enhanced Mobility Procedures
For a detailed description see FD012266 HSDPA Mobility Enhancements.
2.5.9 Indication of HSDPA Capable Cells
From an operator's perspective it is very useful to show users that HSDPA coverage is provided in a specific cell.
This feature allows UEs to display HSDPA-related information of the cell it is camped on. In other words, the UE
can show the user whether or not the current cell is part of the HSDPA coverage area defined by the operator with
a sufficient level of reliability. The coverage area means the zone where HSDPA can typically be allocated to
HSDPA-capable UEs.
The HSDPA Cell Indicator IE is automatically configured for the following cell types:
Cells that are HSDPA-capable.
Inter-frequency cells being adjacent to an HSDPA-capable cell.
Adjacent inter-frequency cells are UMTS cells at the same antenna but on a frequency layer different from the
frequency used for HSDPA.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
111
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
The HSDPA Cell Indicator IE is applied for user notification purposes only, but cannot be used by the UE for any
other purpose.
The feature is 3GPP Rel. 6-compliant. Indicating the HSDPA capability of a cell is allowed for Rel. 5-compliant
UEs.
For a detailed description see FD012286 Support of HSDPA Capable Cell Indicator.
2.5.10 Cell Specific Handover Parameters
Cell specific handover parameters on cell level allow more flexible tuning of handover situations throughout the
network. Thus in the case that a cell carries traffic primarily along a motorway, the handover parameters in this
cell can be tailored to improve handover performance in a motorway environment whereas the neighboring cells
may be tailored to fit a rural scenario.
Currently, there is one HMI command per RNC defined for each of:
Intra-frequency handover
Inter-frequency handover
Inter-system handover
This means that parameters such as Hysteresis and Time to Trigger or thresholds for each measurement type
are fixed across the whole RNC.
The Cell Specific Handover Parameters feature allows an individual setting of some handover parameters on a
per cell basis via templates. Individual template types are available for intra-frequency, inter-frequency, and inter-
system handover. Each cell object contains a reference to one particular template of each type and uses the
referenced set of handover parameters.
As the DRNC does not receive these parameters from the SRNC via the Iur interface, a similar reference is
required per external UTRAN cell. If the master cell is reached via the Iur interface and is not included as an
external UTRAN cell, the handover parameter set identifier 0 is used for each template type.
For a detailed description see FD012261 Cell Specific Handover Parameters.


112 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
2.6 Relocation and Handover
In the Universal Mobile Telecommunication System (UMTS) the mobility of the user equipment is ensured by relo-
cation and handover procedures:
Relocation
is the change of the Iu (or Gn) instance through a changeover of the SRNC (or SGSN) function from one RNS
(or SGSN) to another.
Handover
is the transfer of a users connection from one radio channel to another (can be the same or a different cell).
2.6.1 Classification of Handovers
From the UE point of view, three different handovers (HOs) are implemented, see Figure 84:
In a hard handover, UE is always connected to only one Node B at a time.
The network services are handed over by hard switching from one frequency to another within the same
Node B. If the UE connection is established on common channels, utilizing multipath diversity for a soft
handover is not feasible and the call is taken up by the new cell at the same time as it is dropped from the old
cell.
In a soft handover, UE is connected simultaneously to more than one Node B (connected to the same RNC
or to a different RNC, belonging to the same or to a different CN). The signals are combined at the RNC.
The UE has access to up to three cells of different Node Bs at the same time. When the UE moves from one
cell to another, services are handed over softly without disconnection of communication. This is called a soft
handover because, while the UE can be reached from both Node Bs, its uplink and downlink data streams are
received (or transmitted) from both Node Bs simultaneously. Only after the UE has left the area of overlapping
coverage is the connection through the old Node B released. In the uplink direction, maximum ratio combining
is performed for the transport blocks of all links of the radio link set. In the downlink direction, selection com-
bining is performed for the links of a radio set.
The radio settings for soft handover are the same for all services.
In a softer handover, UE is connected simultaneously to two or more sectored cells, all belonging to the same
Node B. The signals are combined inside the Node B.
The UE has access to several sectored cells hosted by a single Node B at the same time. Selection combining
is performed for the links of a radio set. Softer handover connections are transferred only once over the Iub
interface.
Figure 84 UE Handovers
/PEF#
/PEF#
hard handover
/PEF#
/PEF#
6&
6&
/PEF#
6&
6&
6&
6&
softer handover
soft handover


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
113
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
From the UTRAN point of view, the following handover types are defined, see Figure 85:
Intra-frequency handover
Intra-Node B (softer handover)
Inter-Node B intra-RNC (soft handover)
Inter-Node B inter-RNC (hard handover)
Inter-RNC intra-CN (soft handover)
Inter-RNC intra-CN (hard handover; Relocation)
Inter-CN (soft handover)
Inter-CN (hard handover; Relocation)
Intra-PLMN (hard handover)
This kind of handover is triggered by radio condition (downlink quality) and can be performed when dedicated
channels are allocated to a UE and so while UE is in Cell_DCH.
Inter-frequency handover (hard handover)
Intra-Node B handover
Inter-Node B intra-RNC handover
Inter-RNC intra-CN handover
Inter-CN handover
Inter-PLMN (hard handover)
This kind of handover can be triggered by load, traffic characteristics, coverage and user mobility characteris-
tics. This procedure is used only in Cell_DCH state.
Inter-system handover
UMTS to GSM/GPRS
GSM/GPRS to UMTS
At the beginning, handover from UMTS to GSM/GPRS will be triggered mainly for coverage reasons.


114 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Figure 85 UTRAN Handovers
Based on these definitions, UMTS provides various combinations of HO functions within the system and with other
systems. Table 4 provides a matrix with the HO functions within UMTS and between UMTS and GSM/GPRS from
both the UE point of view and the UTRAN point of view.
UE HO Frequency HO Node B HO RNC HO PLMN HO System HO Remarks
Intrafrequency handover
Softer Intra Intra Intra Intra Intra HO between sectored cells
under the same Node B
with the same frequency
Soft Intra Inter Intra Intra Intra HO on the same frequency
between different Node Bs
under the same RNC (Iub
HO)
Soft Intra Inter Inter Intra Intra Internal HO between
different RNCs under the
same PLMN (Iur HO)
Table 4 Handover Functions in UMTS
B
C
H
Network
CN
Iu
Iub
RNC
B
C
H
Node B
B
C
H
Node B
B
C
H
Node B
RNC
B
C
H
Node B
B
C
H
Node B
B
C
H
Node B
Iub Iub Iub I ub Iub
Iu
CN
Iu
Iub
RNC
B
C
H
Node B
B
C
H
Node B
B
C
H
Node B
RNC
B
C
H
Node B
B
C
H
Node B
B
C
H
Node B
Iub Iub Iub I ub Iub
Iu
Intra-Node B
Handover
Inter-Node B Handover /
Inter-RNC
Handover
Inter-CN
Handover
Iur
Intra-RNC Handover


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
115
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Hard Intra Inter Inter Intra Intra External HO (relocation)
between different RNCs
under the same PLMN (Iu
HO)
Interfrequency handover
Hard Inter Intra Intra Intra Intra HO between cells under the
same Node B with different
frequencies
(blind handover/
time reinitialized handover)
Hard Inter Inter Intra Intra Intra HO between different
Node Bs with different
frequencies under the same
RNC (Iub HO)
(time reinitialized handover)
Hard Inter Inter Inter Intra Intra Internal HO between
different RNCs under the
same PLMN (Iur HO)
(time reinitialized handover)
Hard Inter Inter Inter Inter Intra Internal HO between
different RNCs in different
PLMNs (Iur HO)
(time reinitialized handover)
Intersystem handover
Hard Inter Inter Inter Intra Inter HO between different
systems (e.g.UMTS and
GSM/GPRS) under the
same PLMN
Hard Inter Inter Inter Inter Inter HO between different
systems (e.g.UMTS and
GSM/GPRS) in different
PLMNs
UE HO Frequency HO Node B HO RNC HO PLMN HO System HO Remarks
Table 4 Handover Functions in UMTS


116 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
In addition to the matrix given in Table 4, handovers can also be characterized according to the following:
Intersystem handover
A procedure to handover UEs to GSM by RRC protocol message.
Load-triggered handover
A handover that is triggered by the load control for certain events.
Coverage-triggered handover
An intersystem handover that is triggered by the limited coverage of a frequency
layer.
Blind handover
An intersystem handover that is performed to a cell on a different frequency without measurement information
of the target cell.
Directed Retry
A procedure applicable for a RAB assignment from CS domain if a target cell for blind handover can be found.
Timing maintained handover
A handover that does not change the uplink transmission timing and the CFN in the UE.
Timing re-initialized handover
A handover that allows a new physical channel timing for the UE and the involved Node Bs.
Adjacent cell interference triggered handover
A handover that is triggered by high interference levels from adjacent cells.
IMSI based handover
An intersystem handover to a second radio access network based on the subscriber identity and a subscriber
traffic sharing agreement between two networks.
handover
An intersystem handover initiated by receiving a request to establish a CS RAB with Service Handover IE =
Handover to GSM should be performed.
Load based handover
An intersystem handover initiated by receiving a request to establish a CS AMR RAB with Service Handover
IE = Handover to GSM should not be performed or with IE Service Handover IE = Not included.
IMSI based forced handover
An intersystem handover procedure for neighboring GSM cell filtering to be applied when constructing the
Neighboring GSM cell list for all types of ISHO (e.g. Service Based Handover, Load Based ISHO and
Coverage Based ISHO) and Cell Change Order.
For more information on handovers see also OMN:RN-750 Radio Network Configuration Basics.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
117
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
2.6.2 SRNS Relocation
SRNS relocation is the transfer of the SRNS role from one RNS to another. This also involves reconfiguring the Iu
connections from the original SRNS to the new target RNS. The SRNS relocation is initiated by the SRNC. The
handover from the SRNS to the TRNS is done using hard handover, i.e. all the old radio links in the UE are aban-
doned before the new radio links are established.
3GPP standards describe two types of SRNS relocation:
UE not involved
UE resources (radio bearer, active set etc.) are not reconfigured during the course of the procedure. The Iur
connection is required and the relocation procedure is performed on Cell_FACH combined with Cell
Update/URA Update or with soft handover (see Figure 86). The relocation procedure may also be performed
on Cell_DCH with the Iur used for triggering only.
UE involved
UE resources are necessary and therefore UE is notified via the Uu interface.
The Iur connection is not necessary and the relocation procedure is performed on Cell_DCH combined with
the hard handover (see Figure 87).
Figure 86 Intra-Frequency Intra-PLMN Relocation (UE not Involved)
Figure 87 Intra-Frequency Inter-PLMN Relocation (UE Involved)
PLMN1
Core Network Core Network
DRNC SRNC
Iu
Iur
SRNC RNC
Iu
Before SRNC ReIocation After SRNC ReIocation
CeII
PLMN1
6& 6&
PLMN2 PLMN1 PLMN2
Core
RNC SRNC
Iu
SRNC RNC
Iu
Before SRNC ReIocation After SRNC ReIocation
Network
Core
Network
Core
Network
Core
Network
PLMN1
6& 6&


118 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Table 5 provides an overview of the supported relocation scenarios.
SRNC relocation on Cell_FACH
The SRNC can receive RRC protocol messages sent on the CCCH logical channel, encapsulated in the RNSAP
message UPLINK SIGNALLING TRANSFER INDICATION over Iur. The possible RRC protocol messages that
can be encapsulated in UPLINK SIGNALLING TRANSFER INDICATION are CELL UPDATE or URA UPDATE.
SRNC Relocation is triggered by a CELL UPDATE or a URA UPDATE message which is received by the SRNC
via a DRNC after a UE has moved into the coverage area of the latter.
In case the UE is connected to a CS CN domain, SRNC Relocation is not initiated. In such a case, the SRNC
triggers the Preservation procedure, i.e. releasing the RRC Connection with cause Directed Signalling Connec-
tion Re-establishment.
For a UE in CELL_FACH state, a connection to a CS CN domain is possible in case where the UE has only a
signalling radio bearer established towards the CS domain (e.g. for an SMS transaction).
If the UE is connected to a CS CN domain and a CS RAB is established, then the UE will be in CELL_DCH
state. In CELL_DCH state SRNC Relocation is not triggered (in that state, the UE is allowed to initiate a CELL
UPDATE procedure only as a result of radio link failure or RLC unrecoverable error - and relocation is not ini-
tiated in these cases).
For a UE in CELL_PCH or URA_PCH state, a connection to a CS CN domain is not supported.
Handover Iur configured
(UE not involved)-
Iur not configured
(UE involved)
Intra-PLMN Intra-frequency Yes* Yes
Inter-frequency No** No
Inter-PLMN Intra-frequency No Yes
Inter-frequency No Yes
(*) Iur is used for triggering only. The feature can be switched off via patch.
(**) In this scenario the normal IFHO procedure will take place (HCS).
Table 5 Supported Scenarios for SRNC Relocation on Cell_DCH
Relocation Type Iur SRNS Relocation on
Cell_DCH
SRNS Relocation
on HS-DSCH
UE not involved Intra-PLMN Intra-frequency with Yes only possible if HS-DSCH
is supported over Iur
UE involved Intra-PLMN Intra-frequency with Yes No
Intra-PLMN Intra-frequency without Yes Yes
Inter-PLMN Intra-frequency Yes Yes
Inter-PLMN Inter-frequency Yes Yes
Intra-PLMN Inter-frequency Yes Yes
Table 6 Supported Scenarios for SRNC Relocation on Cell_DCH and HS-DSCH


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
119
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Depending on further conditions and events, SRNC Relocation on Cell_FACH is triggered and performed accord-
ing to Table 7.
Upon a decision to initiate SRNS Relocation, the SRNC determines the number of connected CN domains and
sends the RANAP message RELOCATION REQUIRED to the CN. The target RNC processes the received
RELOCATION REQUEST message and and determines whether to accept the SRNC Relocation or reject it.
The SRNC checks whether:
The UE state is Cell_FACH
There is only one CN domain and that is the PS domain
There is only one RAB requested
The RAB class is either interactive or background
The relocation type is UE not involved in Relocation
If the checks pass, the target RNC sends RELOCATION REQUEST ACKNOWLEDGE to the CN. After receiving
the RELOCATION COMMAND, the SRNC starts the Relocation Execution procedure. This is commenced by
sending RELOCATION COMMIT over Iur, which triggers the Target RNC to commence as the Serving RNC. After
receiving this message, the Target RNC sends a RELOCATION DETECT message to the CN and completes the
procedure to the UE. The UE is in a state of waiting for an RRC response, and the target sends CELL UPDATE
CONFIRM on CCCH.
RRC Message Cause UE State Relocate Action*)
Cell Update Cell Reselection CELL_FACH Y R
CELL_PCH N P
Periodic Cell Update CELL_FACH n/a**) -
CELL_PCH n/a**) -
Uplink Data Transmission CELL_PCH Y R
URA_PCH Y R
Paging Response CELL_PCH Y R
URA_PCH Y R
Re-entered Service Area CELL_FACH Y R
CELL_PCH N P
Radio Link Failure CELL_DCH N P
RLC Unrecoverable Error CELL_DCH N P
CELL_FACH N P
URA Update URA Reselection URA_PCH N P
Periodic URA Update URA_PCH n/a**) -
Re-entered Service Area URA_PCH N P
*) R = Relocation Preparation procedure, P = Preservation procedure
**) A periodic cell/URA update via a DRNC is not possible when the UE state is
CELL/URA_PCH, because in case such a UE makes an attempt to enter in the area
of a DRNC (e.g. cell reselection in CELL_PCH state) the SRNC releases the RRC con-
nection (via Preservation procedure).
Table 7 Triggers for SRNC Relocation on Cell_FACH


120 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
When the PHYSICAL CHANNEL RECONFIGURATION COMPLETE message is received, the Target RNC has
completed the Relocation Execution procedure and sends RELOCATION COMPLETE to the CN.
When the Iu Release Command is received from the CN, the Source RNC releases all resources previously allo-
cated to the UE.
For the corresponding message sequence chart, please see Figure 137, MSC: External Inter-RNC and Inter-
PLMN Handover in the appendix.
SRNC relocation on Cell_DCH
By means of SRNC relocation in Cell_DCH state it is possible to save transmission resources without losing
seamless handover abilities.
Relocation on Cell_DCH is triggered in the SRNC by intra-frequency and inter-frequency measurements. The
SRNC then selects the relocation target cell and performs relocation preparation consisting of:
sending RANAP RELOCATION REQUIRED
receiving RANAP RELOCATION COMMAND
receiving RRC UTRAN MOBILITY INFORMATION CONFIRM
sending RRC hard handover message
releasing the Iu connection(s)
The TRNC detects that it is the target for relocation upon reception of RANAP RELOCATION REQUEST. TRNC
then performs relocation resource allocation consisting of:
setting up the new radio link, ALCAP connections and firmware
calling the RBT and admission control algorithms
sending RANAP RELOCATION REQUEST ACKNOWLEDGE
Upon reception of NBAP RADIO LINK RESTORE INDICATION, the TRNC will perform relocation execution and
send RANAP RELOCATION DETECT.
Relocation completion is triggered by reception of RRC RADIO BEARER RECONFIGURATION COMPLETE. The
TRNC completes the procedure by sending RANAP RELOCATION COMPLETE and restarting the necessary
RRC measurements.
UE involved SRNS Relocation on Cell_DCH also comprises the following:
Operator configurable triggering
Support for Intra-PLMN Inter-frequency cases
Support for HS-DSCH.
For UE Not Involved SRNS Relocation, only Intra-PLMN intra-frequency with Iur connection is supported.
For detailed information see FD012263 Extension of SRNS Relocation.
For examples of the corresponding message sequence charts, please see Figure 138, MSC: Inter/Intra-Fre-
quency Inter-PLMN Relocation and Figure 139, MSC: Intra-Frequency Intra-PLMN Relocation in the appendix.
2.6.2.1 Inter-Frequency Inter-PLMN Relocation
Inter-frequency Inter-PLMN relocation is triggered upon coverage loss and is in principal the same at country
borders or for network sharing. Only UEs with a specific PLMN ID are allowed to handover to the cells belonging
to specific PLMNs (subject to roaming agreements). The principle behind this mechanism is that for each sub-
scriber PLMN ID (MCC and MNC), a list of neighboring UMTS PLMN IDs can be configured indicating which sub-
scribers are allowed to be handed over to which neighboring UMTS network. The neighboring cell PLMN IDs are
the PLMN IDs of those neighboring networks that a roaming subscriber can enter from the current network.
In order to perform an inter-frequency inter-PLMN handover, a mechanism for the selection of neighboring cells is
introduced that is very similar to the FD012244 - IMSI Based Handover feature. This mechanism enables the
RNC to filter those measured cells suitable for relocation.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
121
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Principally, the cells are selected as applied for hierarchical cell structures (HCS). For more information see
section Hierarchical Cell Structures.
Figure 88 Intra-PLMN Intra-Frequency Handover
Trigger mechanism
This type of relocation is triggered when an inter-frequency measurement event is reported and the best reported
cell belongs to a different frequency and PLMN to the existing active set. This enables operators with networks in
neighboring countries to retain the UE in their network when the UE crosses the border between the countries,
without the need for an Iur connection between RNCs belonging to different PLMNs.
For a detailed description, please see OMN:RN-750 Radio Network Configuration Basics and FD012239
Inter/Intra PLMN Relocation.
2.6.2.2 Intra-Frequency Intra-PLMN Relocation
The main goal of intra-frequency intra-PLMN relocation is to save transmission resources without losing seamless
handover abilities. This is realized by means of SRNS relocation in Cell_DCH state.
There are two types of relocation scenarios depending on the operators demands for configuration of Iur connec-
tions between RNCs of different PLMNs:
configured for 'streamlining' to reduce the use of Iur resources (see Figure 89)
not configured (see Figure 90)
PLMN1 is current network
PLMN2 is subscriber network
PLMN3 is reference network
PLMN3
UE PLMN D = PLMN2
PLMN1
6&


122 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Figure 89 Intra-PLMN Intra-Frequency Handover (Iur Configured)
Figure 90 Intra-PLMN Intra-Frequency Handover (Iur not Configured)
Trigger mechanisms
Two trigger mechanisms for the intra-frequency intra-PLMN handover are supported:
Triggering while the Iur interface is present
Intra-PLMN intra-frequency relocation is triggered, when the SRNC detects that at least the second succes-
sive active set update procedure has been successfully performed under the same DRNC and the resulting
number of active set cells is equal to one. That means the UE's whole active set fully remains within one DRNC
after completion of the SHO procedure. After the UE has moved towards the DRNC, an active set change is
reached when the UE is within the DRNC domain. The SRNC waits for further active set modifications to
trigger SRNC Relocation. The reason for that is to make sure that the UE has moved well into the DRNC
boundaries before performing the SRNS Relocation. This measure minimizes the 'ping pong' effect between
two RNCs and reduces the occurrence of the SRNS Relocation in Cell_DCH state.
SRNC DRNC
Node B Node B
Iur
SRNC DRNC
Iur
SRNC DRNC
Iur
RNC SRNC
Iur
Node B
Node B
Active Set cell
A: Before Relocation:
UE is moving towards DRNC
B: Before Relocation:
UE's AS is within DRNC Domain
(e.g. Reception of Event 1C)
C: Relocation Triggered:
UE's AS is WELL
D: After Relocation:
within DRNC Domain
(e.g. Reception of Event 1B)
6& 6&
Node B
6&
6&
Before Relocation
After Relocation
SRNC
6&
6&
Active Cell Set
Neighbor Cell in Same RNC
Neighbor Cell in Other RNC
DRNC SRNC
Node B Node B Node B


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
123
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Triggering while the Iur interface is not present
If an Iur interface is missing, the operator must administer the CIOs between the neighbor cell relations across
an RNC border. The modification of the CIOs must be done in such a way that the measured result of the cell
in the neighbor RNC is better than that of the cells in the active set. Thus, a hard handover (HHO) rather than
a soft handover (SHO) is triggered. As a consequence of the HHO, the old active set is deleted. To avoid the
'ping pong' effect between two RNCs, the TRNC cell must at least be better than the best cell of the currently
active set.
For a detailed description, please see OMN:RN-750 Radio Network Configuration Basics and FD012239
Inter/Intra PLMN Relocation.
2.6.2.3 Intra-Frequency Inter-PLMN Relocation
The intra-frequency inter-PLMN relocation procedure is only supported if no Iur connection is present. The same
approach and trigger conditions apply for the intra-frequency inter-PLMN relocation as do for the intra-frequency
intra-PLMN relocation without an Iur connection (see Intra-Frequency Intra-PLMN Relocation).
For a detailed description, please see OMN:RN-750 Radio Network Configuration Basics and FD012239
Inter/Intra PLMN Relocation.


124 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
2.6.3 Compressed Mode
In a CDMA system the UL and DL radio signals of a radio link are transmitted continuously without gaps. However,
measurements are necessary in order to prepare for inter-frequency or inter-system handover (please see Inter-
Frequency Handover and Inter-System Handover). UEs with a dual synthesizer can receive on two frequencies
simultaneously however the majority of the UEs have a single synthesizer. To allow measurements on other fre-
quencies, an operation mode is required where the transmission is periodically interrupted for short periods of time
creating gaps according to a defined pattern. During these transmission gaps, the UEs can tune to other frequen-
cies and perform measurements. Thus, the UE is enabled to simultaneously make measurements on a frequency
during an ongoing voice/data connection on a different frequency. This operation mode is called Compressed
Mode (CM) which is illustrated in Figure 91.
Figure 91 Compressed Mode
Compressed mode can be performed in asymmetric operation (i.e. simultaneous operation in UL and DL is not
required) and can be activated independently for uplink or downlink transmission or for both directions.
Compressed Mode Control and inter-frequency measurements
The compressed mode interrupts DL transmission for a short period of time, creating a defined pattern of gaps in
the transmission flow. During these gaps, the UEs can tune to another frequency and perform measurements that
can be used for interfrequency handovers. The success of inter-frequency measurements requires a specific com-
pressed mode pattern that has a very restrictive minimum gap density.
For a detailed description, please see OMN:RN-750 Radio Network Configuration Basics and FD012224a
Compressed Mode.
#1 #2 #3 #4 #5 #n
TG pattern 1 TG pattern 1 TG pattern 1 TG pattern 2 TG pattern 2 TG pattern 2
Tr ansmission
gap 1
Transmission
gap 1
Transmission
gap 2
Transmission
gap 2
TG pattern 2 TG pattern 1
TGL1 TGL1 TGL2 TGL2
TGPL2 TGPL1
TGD
TGD
TGSN TGSN
TGSN = Transmission Gap Sequence Number
TGL = Transmission Gap Length
TGD = Transmission Gap Distanc e
TGPL = Transmission Gap Pattern Length


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
125
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
2.6.4 Inter-System Handover
The inter-system handover is the handover between two different core networks. Two cases are possible for the
UMTS Terrestrial Radio Access Networks (UTRAN) involved:
The RANs have the same type, e.g. an inter-PLMN handover
This scenario is supported by UTRAN as a hard handover.
The RANs have different types, e.g. a UMTS-GSM/GPRS handover
This scenario is supported by UTRAN as a hard handover when it is assumed that there will be no direct
UTRAN Base Station Subsystem (BSS) interface.
A general overview of the UMTS-GSM/GPRS handover is given in Figure 92. Steps (i) and (ii) show the handover
from UMTS to GSM/GPRS, while steps (iii) and (iv) show the handover from GSM/GPRS to UMTS.
Figure 92 Inter-System Handover of Different CN/UTRAN Types
Node B
CN (UMTS)
SRNC
Node B
(i)
SRNS
UTRAN
Node B
RNC
Node B
(ii)
RNS
UTRAN
N/Ap1 N/Ap1 N/Ap1 N/Ap1
(iii)
Node B
RNC
Node B
(iv)
RNS
UTRAN
N/Ap1 N/Ap1
Node B
SRNC
Node B
SRNS
UTRAN
N/Ap1 N/Ap1
CN (GSM) CN (UMTS) CN (GSM)
CN (UMTS) CN (GSM) CN (UMTS) CN (GSM)
GSM/GPRS
BSS
GSM/GPRS
BSS
GSM/GPRS
BSS
GSM/GPRS
BSS
(i) Before
UMTS-GSM/GPRS
handover
(ii) After
UMTS-GSM/GPRS
handover
(iii) Before
GSM/GPRS-UMTS
handover
(iv) After
GSM/GPRS-UMTS
handover
6&
6& 6&
6&


126 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
At initial deployment, the coverage of UMTS will be incomplete and concentrated on certain areas, for example
cities and major roads. Outside these areas, no UMTS connections can be provided. In order to have a level of
service that is perceived by the user as being at least as good as that of existing GSM/GPRS networks, handover
mechanisms from UMTS to GSM/GPRS are necessary when a UE leaves the UMTS coverage area while having
an active connection.
For UMTS-GSM/GPRS handovers different services within the two CN domains must be considered:
Handovers between UMTS and GSM for CS calls based on hard handovers and triggered by UTRAN
Handovers between UMTS and GPRS for PS services
based on forward cell reselections and initiated by the UE
Handovers from UMTS to GSM/GPRS for PS services based on cell change order procedures and controlled
by UTRAN
2.6.4.1 UMTS-GSM Handover
Inter-system information must be exchanged to enable UTRAN to notify the UE of the existing GSM frequencies
in the area. Based on measurements taken by the UE, the RNC determines the need for a handover and coordi-
nates it, and compressed mode is used, if necessary, to allow time for these measurements. On completion, the
RNC sends a message to the Core Network (CN) node indicating the target GSM cell. If the relocation is possible,
the RNC receives a RANAP relocation command that triggers an inter-system handover command to the UE. After
the UE has successfully accessed the GSM cell, the RNC receives another message from the CN node and
releases all resources and contexts relating to the Iu connection for this UE.
For the corresponding message sequence chart, please see Figure 140, MSC: UMTS-GSM Handover (Part1)
and Figure 141, MSC: UMTS-GSM Handover (Part2) in the appendix.
Compressed Mode Control and GSM Measurements
When the UE is in an area where handover to GSM is possible or desired, the RNC can trigger compressed mode
and inter-system measurements in order to keep all active connections when the UE approaches the end of the
area covered by UMTS. By means of compressed mode, handover to GSM is supported without the need for UEs
with dual band receivers.
GSM measurement and compressed mode are only triggered for UEs with AMR service in the RAB combination.
For PS services, UE-controlled cell reselection is applied to a supplying GSM/GPRS cell for all RRC states except
CELL_DCH.
For the corresponding message sequence chart, please see Figure 144, MSC: Compressed Mode and GSM
Measurement Activation and Figure 145, MSC: Compressed Mode and GSM Measurement Deactivation in the
appendix.
Please also see Compressed Mode for an overview and OMN:RN-750 Radio Network Configuration Basics
for a detailed description.
2.6.4.2 UMTS Cell (Re-)Selection to/from GPRS
In the situation where the UE performs inter-system cell reselection to the GPRS system, the RNC is a passive
party. The only actions will be related to CN requests. The UE performs inter-system Routing Area Update and
accesses the GPRS system based on inter-system measurement results.
For the corresponding message sequence chart, please see Figure 146, MSC: UMTS Cell (Re-)Selection to/from
GPRS in the appendix.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
127
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
2.6.4.3 GSM-UMTS Handover
At initial deployment, early rollout scenarios will consist of UMTS islands embedded in an overall GSM network.
The GSM-UMTS HO provides seamless service coverage supporting incoming circuit-switched (CS) handovers
for voice and data calls coming from GSM. It is initiated by the GSM network and takes place during a call.
For the corresponding message sequence chart, please see Figure 142, MSC: GSM-UMTS Handover (Part1)
and Figure 143, MSC: GSM-UMTS Handover (Part2) in the appendix.
2.6.4.4 UMTS Cell Change Order to GSM/GPRS
The purpose of the cell change order procedure is to transfer a UTRAN PS RAB connection to a GSM/GPRS cell
under the control of the UTRAN. The UTRAN orders the UE to perform a cell change to a GSM/GPRS cell if the
radio condition quality measurements are below a certain threshold and the GSM measurement quality is above
a certain threshold.
The conditions for the cell change order procedure are
the UE is in CELL_DCH state AND
only PS RAB(s) exist AND
no signaling connection to the CS domain exists
For the corresponding message sequence chart, please see Figure 154, MSC: Cell Change Order (Successful
Scenario Procedure) in the appendix.
For a detailed description, see also OMN:RN-750 Radio Network Configuration Basics and FD0122332a
Cell Change Order.
2.6.4.5 Handling of E911 Emergency Calls
The purpose of E911 emergency call handling between UMTS and GSM is to achieve FCC compliant positioning
accuracy for such calls. The accurate position is retrieved from the GMLC (Gateway Mobile Location Center) by
the PSAP (Public Safety Answering Point -e.g. police and fire departments).
Provided the target GSM network supports the location service, the location of a UE can be identified within two
accuracies as shown in Table 8:
Emergency calls are handled depending on the state of the UE.
UE in idle state (no RRC connection)
The call is redirected to GSM.
UE in dedicated state (RRC connection exists)
The UE is forced to perform an inter - system handover provided the requisite
conditions are met.
The procedures are mutually exclusive. In both cases, however, fallback to UMTS will be conducted if there is no
suitable GSM coverage available.
Positioning method 67% of the E911 calls 95% of the E911 calls
handset based 50m 150m
network based 100m 300m
Table 8 FCC Compliant Positioning Accuracies for Emergency Calls


128 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
2.6.4.6 UMTS Handover to/from GSM850/1900
The purpose of the UMTS handover to/from GSM850/1900 is to enable the implementation of 3G services by
refarming 3G generation systems within an existing PCS spectrum as used in North America. This can be realized
by replacing part of the existing 2G frequencies with 3G systems, provided that no FDD2100 cells are configured
in such networks. The handover is supported for the CS (handover from UTRAN) and PS domain (cell change
order).
For a detailed description, see also OMN:RN-750 Radio Network Configuration Basics.
2.6.5 Inter-RNC Handover (Soft Iur Handover)
The inter-RNC handover is implemented as a soft HO. Unlike with the intra-RNC handover, the Node Bs involved
in the soft HO belong to different RNCs.
For the corresponding message sequence chart, please see Figure 147, MSC: Soft Handover - Radio Link Setup
and Figure 148, MSC: Soft Handover - Radio Link Deletion in the appendix.
2.6.6 Intra-Node B/Intra-RNC Handover
The intra-Node B/intra-RNC handover is implemented as a softer HO. One Node B that is controlled by one RNC
is involved in the softer HO.
For the corresponding message sequence charts, please see Figure 149, MSC: Softer Handover - Radio Link
Addition and Figure 150, MSC: Softer Handover - Radio Link Deletion in the appendix.
2.6.7 Hierarchical Cell Structures
The use of several overlapping cells in different frequency layers allows specific provision of air capacity to areas
of different expected traffic load and efficient use of the radio resources through a flexible radio resource assign-
ment to UEs. This is especially useful in areas of high traffic density, e.g. urban environment.
Hierarchical cell structures are composed of different layers using different frequencies, cell sizes, and cell priori-
ties. However, different frequencies and priorities can be used on the same hierarchical layer, e.g. to cope with
high load in the system.
By assigning hierarchical priority to cells, the operator creates a network with different layers. Each layer is
reserved for a clearly defined type of traffic. Handovers between the layers are possible if, for example, congestion
occurs.
Figure 93 shows an example of a hierarchical cell structure. The numbers describe the different layers in the hier-
archy. Number 1 is the highest hierarchical layer with the
highest priority, i.e. typically the smallest cell.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
129
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Figure 93 Hierarchical Cell Structures
For a detailed description of HCS and the impact of HCS scenarios on radio resource management procedures,
please see OMN:RN-750 Radio Network Configuration Basics and FD012224b Hierarchical Cell Struc-
tures.
2.6.8 Inter-Frequency Handover
In the second phase of deployment, rollout scenarios comprise mixed cell scenarios, especially mixed micro and
macro cell deployment. As most operators have licences for more than one frequency, they can start using one
frequency and enhance capacity by using further ones. Inter-frequency handover is used to manage different
mobility and QoS requirements through a Hierarchical Cell Structure (HCS). In addition, it is important in an envi-
ronment where some Node Bs support four frequencies and some Node Bs support only one frequency layer. Fur-
thermore, inter-frequency handovers are possible to cells of a different frequency residing on a different antenna
where the pathloss and timing relations are not known.
With HSDPA additional inter-frequency handover procedures that involve HS-DSCH are introduced in the form of
blind (timing-maintained) IFHO and IFHO with inter-frequency measurements. During the blind inter-frequency
handover procedure, the UE is handed over to an inter-frequency cell that belongs to the same sector as one of
the active set cells. In the event of an inter-frequency handover from an HSDPA cell to a non-HSDPA cell, CTS
from DCH + HS-DSCH to DCH is initiated in addition to the inter-frequency handover procedure. If an inter-fre-
quency handover from a non-HSDPA cell to an HSDPA cell occurs, the establishment of an HS-DSCH is initiated
in addition to the inter-frequency handover procedure. For details see FD012266 HSDPA Mobility Enhance-
ments.
See also Inter-frequency handover control.
For a generic message sequence chart, please see Figure 151, MSC: Inter-Frequency Handover (Generic Pro-
cedure) in the appendix.
2.6.9 IMSI Based Handover
An IMSI based handover (IBHO) is a handover to a second radio access network based on the subscriber identity
and a subscriber traffic-sharing agreement between two networks. Depending on the subscribers home PLMN ID,
the UE may be handed over to selected neighbor networks. GSM operators are enabled to share a common UMTS
network by extending the support of handover and cell re-selection to adjacent GSM networks as well as UMTS
networks. The UMTS network may not have its own subscribers, but are used by either national or international
roaming subscribers. The scenario for adjacent GSM networks is illustrated in Figure 94
1
2
3


130 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Figure 94 Network Traffic Sharing Configuration
For the corresponding message sequence chart, please see Figure 152, MSC: IMSI Based Handover in the
appendix.
For a detailed description see OMN:RN-750 Radio Network Configuration Basics and FD012244 IMSI
Based Handover.
2.6.10 Service Based Handover
Service Based Handover provides network operators with the means to define service differentiation between their
UMTS and GSM/GPRS networks by handing over calls between these networks based on the RAB ASSIGN-
MENT REQUEST message received from the Core Network. Depending on the IE received with this message a
CS RAB can be set up in GSM instead of UMTS. This allows network operators to optimize their network resource
usage and increase network capacity, e.g. the network operator may define that all voice calls are handed-over to
its GSM network whilst focusing its UMTS network for the offering of data services.
For a detailed description, see FD012264 Service and Load Based Handover.
2.6.11 Load Based Handover
The Load Based Handover provides network operators with a means to optimize their UMTS network depending
on the cell load. Certain service (RAB) types can be handed over to the GSM/GPRS network in case the load
threshold defined by the operator for such services is reached. Specific service calls (e.g. voice) are no longer
MNC = 01 MNC = zz
BTS
BSC
2G-SGSN
HLR
Network Operator 1
2G-MSC
2G-VLR
ISP etc.
PSTN/ISDN,
other PLMN etc.
2G-SGSN
HLR
Network Operator 2
2G-MSC
2G-VLR
ISP etc.
PSTN/ISDN,
other PLMN etc.
inter-PLMN
inter-system
handover
inter-PLMN
inter-system
handover
Node B
RNC BSC
GMSC GGSN STP
3G-SGSN
3G-MSC
3G-VLR
STP
GGSN GMSC STP
UMTS Network Sharing
Operator 1 / Operator 2
MNC = 02
BTS


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
131
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
rejected or dropped due to cell congestion. This increases customer satisfaction and call setup success and call
retention rates.
For a detailed description, see FD012264 Service and Load Based Handover.
2.6.12 IMSI Based Forced Handover
As an addition to the IMSI based Handover feature an inter RAT handover depending on the subscribers IMSI can
be triggered. The IMSI based Forced ISHO makes it possible to separate the inter RAT cell info list per IMSI of the
UE. When constructing the neighboring GSM cell list a neighboring GSM cell filtering procedure is provided that
can be applied for all types of ISHO (e.g. Service Based Handover, Load Based ISHO and Coverage Based ISHO)
and Cell Change Order.
For a detailed description, see FD012271 IMSI Based Forced Handover.
2.7 Overload Monitoring
The RNC monitors the RNC processor load in order to maintain service quality. If the overload or congestion level
exceeds the present threshold levels, an autonomous message is output to the OMC, see also Congestion con-
trol.
For a detailed description see OMN:RN-750 Radio Network Configuration Basics.
2.8 Ciphering
The ciphering function is a part of the security architecture. It is performed between the RNC and the UE on the
transport stratum.
2.8.1 Security Architecture Overview
The 3 G security architecture consists of 5 security feature groups. Each of these feature groups addresses
specific threats and accomplishes specific security objectives:
Network access security (I):
provides users with secure access to UTRAN services, and protects against attacks on the (radio) access link
Network domain security (II):
enables nodes in the provider domain to securely exchange signaling data, and protects against attacks on
the wireline network
User domain security (III):
enables applications in the user and in the provider domain to securely exchange messages
Application domain security (IV):
enables applications in the user and in the provider domain to securely exchange messages
Visibility and configurability of security (V):
enables the users to get information on whether
a security feature is in operation
the use and provision of services should depend on the security feature
Figure 95 provides an overview of the complete 3G security architecture.


132 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Figure 95 Overview of the Security Architecture
User (temporary) identification, authentication and key agreement will take place independently in each service
domain. The user plane traffic will be ciphered by using the cipher key agreed for the corresponding service
domain. The control plane data will be ciphered and integrity-protected by using the cipher and integrity keys from
either one of the service domains.
This may require that the cipher/integrity key of an already ciphered/integrity-protected ongoing signaling connec-
tion is changed. This change should be completed within five seconds.
2.8.2 Location of Ciphering Function in UTRAN Protocol Architecture
The ciphering function is carried out either in the Radio Link Control (RLC) sub-layer or in the Medium Access
Control (MAC) sub-layer, according to the following rules:
In the case of a logical channel that uses a non-transparent RLC mode (Acknowledged Mode, AM or Unac-
knowledged Mode, UM), ciphering is performed in the RLC sub-layer.
In the case of a logical channel that uses the transparent RLC mode, ciphering is performed in the MAC sub-
layer (MAC-d entity).
A logical channel that will be supported on a common transport channel should use the Unacknowledged
Mode (UM) RLC mode.
According to this model, ciphering is always performed in the Serving RNC (SRNC). The ciphering context, such
as Cipher Key (CK) and Hyper Frame Number (HFN), is only known in the SRNC.
2.8.3 Input Parameters to the Ciphering Algorithm
In the RLC sub-layer, ciphering performs the encryption/decryption of the data part of an RLC Protocol Data Unit
(PDU). The PDU is ciphered based on Exclusive OR (XOR) combining with a mask that is obtained as an output
of the ciphering algorithm.
In the MAC sub-layer, ciphering performs the encryption/decryption of the data part of a MAC Service/Signaling
Data Unit (SDU). The SDU is ciphered based on an XOR operation with a mask that is obtained as an output of
the ciphering algorithm.
User Application Provider Application
ME
HE
SN
AN
USIM
Application
stratum
Transport
stratum
AN = Access Network SN = Serving Network
Home
stratum/
Serving
stratum
UE
(IV)
(I)
(I)
(II)
(I)
(I)
(I)
(III)


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
133
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
The ETSI Security Algorithms Group of Experts has specified an encryption algorithm named KASUMI in TS
35.201, 35.202, 35.203 and 35.204. As described in TS25.331 the change of the ciphering algorithm is supported.
The following gives an overview of the parameters that are fed into the input of the Ciphering Algorithm, see Figure
96.
Figure 96 Ciphering Method
Count
COUNT will be at least 32 bits long. It is composed of
a long sequence number called HFN
a short sequence number, which depends on the ciphering mode
One ciphering sequence is provided for each logical channel using AM or UM mode. In addition, one ciphering
sequence is supported for all logical channels using the transparent mode.
Cipher Key (CK)
A Cipher Key (CK) is established between the UE and the SRNC during the authentication phase. In the two-key
solution, the CS-domain bearers, the PS-domain bearers and the signaling link are ciphered as follows:
CS-domain bearers
are ciphered with the most recent cipher key agreed between the user and the
Mobile Switching Centre (3G-MSC) (CK-CS)
PS-domain bearers
are ciphered with the most recent cipher key agreed between the user and the Serving GPRS Supporting
Node (3G-SGSN) (CK-PS)
signaling link
is ciphered with the most recent cipher key established between the user and the network, i.e. the youngest
of CK-CS and CK-PS
Bearer
This parameter indicates the radio bearer identities which are unique per radio bearer associated with the same
user. It is used as an input parameter of the ciphering algorithm to ensure that the same ciphering mask is not
applied twice to logical channels which have the same CK and the same COUNT. Each logical channel is ciphered
independently.
Direction
This parameter indicates the transmission direction (uplink/downlink).
Ciphering Algorithm
BEARER
DIRECTION
LENGTH
CK
KEYSTREAM
PLAINTEXT
BLOCK
CIPHERTEXT
BLOCK
BLOCK
COUNT-C
Sender
UE or RNC


134 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Length
This parameter indicates the length of the keystream block (mask) to be generated by the algorithm. It is not an
input to the keystream generation function.
2.9 Quality of Service
A bearer service with well-defined characteristics is set up between the source and the destination of a service to
provide a certain network Quality of Service (QoS). Network services are considered end-to-end, i.e. from one UE
to another UE.
There are two categories for traffic:
real-time traffic
non-real-time traffic
The characteristics for the quality of service depends on the category of traffic. The QoS is defined in terms of time
delay for real-time traffic, and in terms of bit errors for non-real-time traffic.
Different levels of QoS are provided to support an end-to-end QoS according to 3GPP TS.23.107. Figure 97 gives
an overview of the overall UMTS QoS layered architecture. Each bearer service on a specific layer offers individual
services using the services provided by the layers below.
Figure 97 UMTS QoS Architecture
As an example, the following sections introduce QoS classes and related attributes of the Iu interface.
CN
TE MT
UTRAN
CN Iu
EDGE
NODE
CN
Gateway
TE
UMTS
UE
End-to-End Service
ExternaI Bearer
Service
TE/MT LocaI
Bearer Service
UMTS Bearer Service
CN Bearer
Service
Radio Access Bearer Service
Radio Bearer
Service
Iu Bearer
Service
Backbone
Bearer Service
UTRA
FDD Service
PhysicaI
Bearer Service


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
135
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
2.9.1 UMTS QoS Classes
Four different QoS classes are defined by 3GPP TS 23.107 to describe the restrictions and limitations of the Iu
interface.
Conversational Class
The Conversational Class is used for real-time conversation such as telephony speech or voice-over-IP and video
conferencing. Real-time conversation is performed between human end users. Thus, the required characteristics
are strictly given by human perception.
The basic characteristics of QoS are
preserve time relation (variation) between information entities of the stream
conversational pattern, e.g. stringent and low delay
Streaming Class
The Streaming Class is used for multimedia applications, e.g. real-time video or audio. The real-time data flow is
always aimed at a human destination. It is a bidirectional transport and always used in combination with an inter-
active/background QoS class.
The basic characteristics of QoS are
preserve time relation (variation) between information entities of the stream
define a guaranteed bit rate and a maximum transfer delay
Interactive Class
The Interactive Class is used if either a machine or a human being requests online data from remote equipment
(e.g. a server).
The basic characteristics of QoS are
request response pattern
preserve payload content
Background Class
The Background Class is used if a computer sends and receives data files in the background.
The basic characteristics of QoS are
the destination does not expect the data within a certain time
preserve payload content
2.9.2 UMTS Bearer Service Attributes
The following traffic classes are supported for the PS domain and the CS domain:
PS domain:
conversational, streaming, interactive and background traffic classes
CS domain:
conversational traffic class


136 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Table 9 shows a complete list of available UMTS bearer service attributes according to the QoS Classes. Those
which will be supported in a later release are put in brackets.
2.9.3 IETF Differentiated Services
In order to provide the full solution of the Quality of Service (QoS) in the UTRAN network, IP-based Iu bearer
services offer DiffServ, which include 3 QoS classes identifying the prioritization for packet loss:
Expedited Forwarding (EF)
Assured Forwarding (AF)
Best Effort (BE)
The source/destination packet principle allows switching, routing and rerouting of packets that carry all the valid
information in their header. The expected QoS class is assigned to each packet in the Type Of Service (TOS) field
of the IP header. Software determines the DiffServ QoS class according to the traffic class defined in the RANAP
RAB assignment request message.
IETF differentiated states are specified by 3GPP TS 23.107 and IETF RFC2474.
Figure 98 shows the mapping of the IETF and RAB QoS classes.
Bearer
Service
Attribute
Traffic Class
Conversa-
tional
Streaming Interactive Background
Maximum bit rate X X X X
Delivery order X X X X
Maximum SDU size X X X X
SDU format
information
X X
SDU error ratio X X X X
Residual bit
error ratio
X X X X
Delivery of erroneous
SDUs
X X X X
Transfer delay X X
Guaranteed bit rate X X
Traffic handling
priority
(X)
Allocation/retention
priority (pre-emption)
X X X X
Table 9 UMTS Bearer Service Attributes for Traffic Classes


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
137
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Figure 98 Mapping of the IETF and RAB QoS Classes
The mapping of the DiffServ (specified in the TOS field) and the current UMTS QoS class (streaming, conversa-
tional, interactive or background), is performed using the office data stored in the RNC. This can be changed via
the Radio Commander. Initially Destination Code Points for the QoS classes Interactive/Background and Stream-
ing can be configured by the Radio Commander. The RNC marks the appropriate DiffServ Code Point in the TOS
field of the IP header for each packet of the uplink traffic. The SGSN marks the downlink traffic for the Iu-PS.
The QoS on the Iu-PS interface is configured via the ATM AAL5 link between the RNC and the PS CN during the
transport bearer setup. The TOS field in the IP header is used to distinguish between real-time and non-real-time
IP packets. A buffer control mechanism is used to avoid non-real time services to fill up the buffer when the air
interface rate is fixed and no rate control is allowed.
On the Iur interface the QoS depends on the link characteristics of the AAL2 connection (transport bearer) carrying
the user plane traffic between RNCs. No Iur-specific QoS differentiation exists because the highest QoS class is
used to accommodate all QoS classes including PS streaming, which helps to prevent cell loss or excessive
delays. It must be noted that QoS cannot be guaranteed on the DRNC Iub interface when external resources are
involved.
On the Iu interface the QoS is defined by the configuration of the transport channel, TFCS and physical channel
parameters of the PS RAB.
For more information see also OMN:RN-750 Radio Network Configuration Basics.
Uu
Iub
Conversational / Streaming / nteract ive / Background
RAB QoS cIasses
Expedited Forwarding / Assured Forwarding / Best Effort
IETF QoS cIasses
pri ority
highest Iowest
6&
Node B
RNC


138 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
2.10 Bearer Services
Bearers can be seen as specific combinations of properties and settings that make up an instance of a protocol
stack.
The properties of a bearer include:
maximum and guaranteed bit rate
delivery order
maximum transfer delay
tolerable bit error rate
UMTS offers a range of different bearer services and allows the operator to allocate available bandwidth efficiently
and map user services to the limited radio resources.
The UMTS bearer services consist of
Radio access bearer (RAB) services
Radio access bearer services provide confidential transport of signaling and user data between UE and the
CN Iu edge node.
The supported Quality of Service (QoS) for all types and speeds of traffic in the user plane and control plane
is adequate for
the negotiated UMTS bearer services and/or
the default QoS for signaling.
The RAB services are based on the characteristics of the radio interface and are maintained for a moving UE.
Core network bearer services
Core network bearer services connect the CN Iu edge node with the CN gateway to the external network.
These services control and uses the backbone network in order to provide the contracted UMTS bearer ser-
vices.
RABs for user plane traffic
Radio access bearer services consist of
Radio bearer services
Radio bearer services cover all aspects of the radio interface transport and use the UTRA FDD. There are two
types of radio bearer services:
Single RAB services (see Table 10):
Only one type of service is supported.
Multi-RAB services (see Table 11)
Multiple services such as Voice with simultaneous e-mail, download or web-browsing or Video confer-
encing with simultaneous e-mail, download or web-browsing with different combinations of UL/DL bit rates
(QoS) are supported.
Iu-bearer services
Iu-bearer services provide the transport between UTRAN and CN together with physical bearer services.
The RABs are based on the prioritized reference RABs depicted in 3GPP TS 34.108.
For a detailed description see the FD012231a Additional Bearer Services.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
139
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
RAB Traffic class CS/PS Max. rate, kbps
UL DL
AMR speech Conversational CS 12.2*) 12.2*)
UDI Conversational CS 64 64
28.8 28.8
32 32
Streaming Streaming CS 14.4 14.4
28.8 28.8
57.6 57.6
Packet
Interactive/Background
PS 8 8
16 16
32 8
32 32
32 64
32 HSDPA
64 8
64 64
64 128
64 144
64 256
64 384
64 HSDPA
128 128
128 384
128 HSDPA
144 144
384 64
384 128
384 384
384 HSDPA
*) optional: AMR speech codecs for single-mode AMR with 12.2, 7.95, 5.9, and 4.75
[kbps] supported (see FD012270 Support of Multiple Speech Codecs),
Table 10 Single RAB Services


140 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
RABs Traffic class CS/
PS
Max. rate, kbps
1 2
1 2 UL DL UL DL
AMR
speech
UDI Conversational +
Conversational (Unknown)
CS +
CS
12.2 12.2 64 64
AMR
speech
Paket Conversational +
Interactive/Background
CS +
PS
12.2 12.2 0 0
12.2 12.2 8 8
12.2 12.2 32 32
12.2 12.2 64 64
12.2 12.2 64 128
12.2 12.2 64 256
12.2 12.2 64 384
12.2 12.2 64 HSDPA
UDI Paket Conversational +
Interactive/Background
CS +
PS
64 64 8 8
64 64 64 64
64 64 64 HSDPA
Paket Paket Streaming +
Interactive/Background
PS +
PS
8 16 8 8
16 64 8 8
8 32 8 8
16 128 8 8
32 256 8 8
Paket Paket Conversational +
Interactive/Background
PS +
PS
8 8 8 8
16 16 8 8
Table 11 Multi-RAB Services


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
141
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Bearers for control plane traffic (signaling radio bearers)
RAB & RRC Establishment on the RACH/FACH
Signaling radio bearers (SRB) and radio access bearers (RAB) can be set up on common or dedicated transport
channels depending on the cause of the RRC connection establishment or traffic class of the RAB:
RRC connections for signaling
Mobility management only needs to transmit a small amount of data between the UE and the CN, e.g. for reg-
istration or location updates; thus, setting up dedicated channels/resources for these non RAB-related RRC
connections is not necessary.
Call-related RRC connections
Interactive/background RABs can be established on common channels. If more bandwidth is required,
channel type switching to a dedicated channel is triggered by traffic volume reports. A conversational or
streaming RAB must be set up on dedicated channels because of the guaranteed data rate and traffic delay
requirements.
For a detailed description see OMN:RN-750 Radio Network Configuration Basics and FD012220b
RAB/RRC Establishment on RACH/FACH.
HSDPA RAB Handling
HSDPA RAB handling comprises:
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 HSDPARAB type, since not all RABs are
suitable to be supported on HSDPARAB combinationActivity level of the RAB
The procedures and information elements that enable bearer management in an HSDPA system
For a detailed description see FD012249 Support of HSDPA.
HSDPA was initially introduced with a restricted set of Radio Access Bearers (RABs) and bearer combinations
limiting the usability of services and applications for the end user.
Single-RAB and multi-RAB configurations support DCH bearers combined with HS-DSCH in the downlink.
The CS + PS I/B RAB combinations are available with the PS I/B RAB mapped to the HS-DSCH. PS Streaming
+ PS I/B and PS Conversational + PS I/B RAB combinations are still supported with a DCH only configuration
because the PS I/B rate in the DL is only 8 kbit/s.
Signaling Radio Bearer
UL/DL Maximum
rate (Kbps)
Logical Channel Physical Channel
UL/DL 3.4 DCCH DPCH
UL/DL 13.6 DCCH DPCH
UL 16.6 CCCH PRACH
DL 24 PCCH S-CCPCH
DL 27.2 DCCH S-CCPCH
DL 30.4 CCCH S-CCPCH
DL 33.2 BCCH S-CCPCH
Table 12 Supported Signaling Radio Bearers


142 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
With this release all 12 HS-DSCH physical layer categories that are defined by 3GPP TS 25.306 UE Radio
Access Capabilities are supported. These include the introduction of categories 1 to 5 and 7 to 10 with this release
while categories 6, 11 and 12 were supported with the previous release.
For a detailed description see FD012265 HSDPA RAB Handling Enhancements.
2.10.1 Radio Access Bearer (RAB) Assignment
When a connection is requested, bearers are allocated by a bearer translation function. This function correlates
the requested attributes with the list of supported bearers and makes an appropriate choice.
A second function, Admission Control, checks whether there are resources available to create a bearer of the
chosen type. Admission control is called prior to each RAB assignment/reconfiguration procedure. Its function is
to estimate the capacity requirements of the requested bearer within a given cell in terms of soft load. This is
defined by the UL interference relative to the thermal noise and the total DL transmission power relative to the
common channel power. The admission control algorithm also provides enhanced handling of emergency calls by
additional operator-configurable thresholds. If the outcome of the admission control procedure is successful, the
SRNC can proceed with the RAB setup/reconfiguration procedure. For more information please see section
Radio Resource Management.
Figure 99 Admission Control and Radio Bearer Control/Translation
Radio Bearer
Control
Radio Bearer
Translation
Congestion
Indication
RRC Request
SRNC
Admission
Control
CRNC
Management
Control
Traffic Volume
Measurements
RAB Request
Activate/
Deactivate
Configure/
Activate
Radio Link
Setup/
Reconfiguration
Admission
Response
Congestion
Indication
Congestion
Control
O&M
Protocol
Functions


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
143
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
2.10.2 RAB Pre-emption
The operator can control UTRAN resource allocation to users and/or services by allocating priorities and pre-
emption properties to different RABs. If the core network requests the establishment of a RAB upon RAB estab-
lishment, SRNC relocation, or inter-RAT handover to UTRAN, it provides the allocation/retention priority attributes
of this RAB:
Priority level
There are 14 priority levels available from highest priority (1) to lowest priority (14). Furthermore, the value (15)
is available that indicates no priority.
Pre-emption capability
The pre-emption capability indicates whether the RAB may or may not trigger
pre-emption.
Pre-emption vulnerability
The pre-emption vulnerability indicates whether the RAB is or is not pre-emptable.
The SRNC maps the RAB allocation/retention priority attributes received from the core network onto dedicated
channel (DCH) allocation/retention priorities.
These priorities are then mapped onto radio link allocation/retention priorities which are used by the CRNC to
perform radio link pre-emption:
Radio link allocation priorities
Identify which radio links can pre-empt others
Radio link retention priorities
Identify radio links that can be pre-empted
The RNC-based radio link pre-emption frees codes and/or reduces the cell load in order to allocate resources to
high priority users.
The SRNC maps the RAB allocation/retention priority attributes received from the core network onto dedicated
channel (DCH) allocation/retention priorities. These priorities are then mapped onto radio link allocation/retention
priorities which are used by the CRNC to perform radio link pre-emption.
If pre-emption is required, the CRNC selects radio links for pre-emption and informs the SRNC. The SRNC deletes
these radio links based on the type of RAB:
Triggering RRC connection re-establishment to common channels
Releasing the RRC connection if the connection cannot be switched to CELL_FACH
The new resources are assigned if the deletion of the radio links is completed.
The pre-emption procedure interacts with the load based BRA procedure in a complex way. The operation is
mutually exclusive and operators cannot activate both procedures simultaneously. See also Load Based Bit Rate
Adaptation.
For the corresponding message sequence chart of the overall pre-emption procedure, please see Pre-emption
in the appendix.
For a detailed description see OMN:RN-750 Radio Network Configuration Basics and FD012243 Pre-Emp-
tion.


144 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
2.10.3 Data Rate Management
Data rates of PS services change dynamically. For interactive/background PS services only a maximum rate is
required. The data rate on the air interface is adjusted to the current need of a service by a 'best effort' approach.
The mechanisms for managing the resources on the air interface are:
Channel Type Switching (CTS)
Bit Rate Adaptation (BRA)
These algorithms are based on traffic volume measurements reported by the UE and measurements by the RNC
platform (e.g. buffer utilization) plus certain timers to trigger the transitions between the different traffic states.
2.10.3.1 Transport-Channel-Type Switching
Channel-type switching performs transitions between dedicated and common channels and is applied to the PS
I/B single-bearer. It includes the switching between the states RACH/FACH, DCH/DCH and DCH/HS-DSCH. This
procedure re-allocates resources from silent UEs towards active ones for efficient use of the available
resources on the air interface. Channel-type switching involves shifting of users who did not transfer data for a
given period of time from dedicated to common channels, and vice versa for active users. The initial rate is
assigned to the PS I/B when performing CTS from FACH to DCH and then the DCH rate may change according
to the BRA. These radio resource management states are defined in 3GPP TS 25.331.
Transport-channel-type switching can be invoked by
external triggers
traffic volume measurement report (inactivity traffic detection)
congestion control
cell update
time-outs that occur in the corresponding states
A RRC connection is either set up on a DCH or a CCH, in other words there is a transition from Idle Mode to
CELL_FACH or Cell_DCH state. An expiry of the traffic inactivity timer leads to a transition from Cell_DCH to
Cell_FACH.
For detailed information see OMN:RN-750 Radio Network Configuration Basics.
2.10.3.2 Bit Rate Adaptation
Bit rate adaptation is a mechanism that adjusts the data rate of dedicated channels to the current need of the
service and accounts for the radio link quality.
Bit rate adaptation performs the reconfiguration of the data rates for PS I/B RAB. It improves the dedicated radio
resource usage and the user QoS by adapting the dedicated rate to the need of the service. Additionally, bit rate
adaptation minimizes call drops due to poor radio link conditions and failures of PS interactive/background RAB
establishment.
Bit rate adaptation is also used in the case of multi-call services, which are only supported for dedicated channels.
The rate of the PS radio access bearer is achieved by reconfiguring the currently existing channels.
For detailed information see OMN:RN-750 Radio Network Configuration Basicsand FD012220a Bit Rate
Adaptation.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
145
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
2.10.3.3 Load Based Bit Rate Adaptation
A load based BRA handling on PS interactive/background RABs protects CS conversational calls from being
rejected. BRA to Minimum Rate for the multi-call (AMR/UDI + PS) and single PS call is triggered upon successful
admission control for the RAB establishment or HO handling and the reception of UL/DL periodic common mea-
surement report or UL measurement in RL setup/addition response if the BRA thresholds are exceeded. There is
a complicated interaction between Load Based BRA and Pre-emption. Therefore, only one of the features can be
enabled at a time. For more information see also RAB Pre-emption.
For detailed information see OMN:RN-750 Radio Network Configuration Basics and FD012248a Load
Based Bit Rate Adaptation.
2.10.4 Higher Layer Filtering
From radio resource management point of view, higher layer filtering is an important tool in order to improve the
Node B measurement accuracy and avoid unnecessary measurement reports.
The following features use Node B measurements and benefit from higher layer filtering:
Admission control
The cell load estimation is enhanced.
Congestion control
Congestion is more accurately detected.
Bit rate adaptation
The detection of poor/good radio link conditions is improved.
Outer loop power control
Call Trace
For detailed information see OMN:RN-750 Radio Network Configuration Basics.
2.10.5 HSDPA Resource Management
To maintain HSDPA performance and the quality of connected HSDPA UEs, it is controlled that not too many
HSDPA UEs will connect. This is achieved by an enhanced HSDPA admission control.
HSDPA resource management relies on the following parameters:
Bit rate which is available for HSDPA, Ravailable
This parameter implies the maximum bit rate which can be allocated to HSDPA users of a particular cell. The
HSDPA bit rate is provided in [kbit/s].
Number of H-RNTIs (radio network temporary identifiers for HSDPA)
H-RNTI is the unique identifier of an HSDPA user within a cell. It is used to scramble the control data on the
HS-SCCH. For more information about the allocation of H-RNTI, refer to the FD012249 Support of HSDPA.
For a detailed description, please see FD012267 HSDPA Resource and Power Management.
2.10.6 RAB Applications
This chapter describes the application and practical use of dedicated RAB services:
PS Streaming RAB
CS Streaming RAB for Remote Modem Access
PS C + PS I/B RAB for Realtime Gaming


146 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
2.10.6.1 PS Streaming RAB
The QoS mechanism on the Iu-PS interface differentiates between the traffic flow for various types of packet
switched services and thus helps to optimize business opportunities within the 3G market. It determines the
success of audio/video as well as other application data services and their market acceptance in general by guar-
anteeing a steady traffic flow inherent to the performance of such features.
It enables operators:
to provide audio/video streaming packet services and thus improve their market
position while generating profit from the new services
to enhance user perception by ensuring a guaranteed bit rate and reliable QoS while supplying applications
with asymmetrical bidirectional, realtime PS services, e.g. audio/video streaming
to differentiate between services and offer subscriber-friendly billing, based on the number of downloaded
bytes instead of billing the general online-time as used in the case of packet services downloaded via the CS
domain
to easily increase the number of newly offered services because of the high number of content providers in
the PS domain
PS streaming is only possible with the capability of IETF DiffServ in the Iu-PS interface (see IETF Differentiated
Services). The PS streaming RAB is bidirectional and always used in combination with an interactive/background
PS RAB. Both the media (Real-time Transport Protocol (RTP)) and the control (Real-time Transport Control
Protocol (RTCP)) flows are carried over a streaming bearer, while the signaling flow (Real-Time Streaming
Protocol (RTSP)) is multiplexed on the non-real time (NRT) interactive/background PS bearer (Figure 100).
Figure 100 Structure of the Protocol Layers for Bidirectional Streaming
Streaming PS establishment
The streaming server and UE streaming application negotiate the QoS required for the service, whereby the nego-
tiation is transparent to both UTRAN and the CN. The QoS parameters are transmitted to the UE via the Network
Application Signaling (NAS) layer, and the UE requests a secondary PDP context from the PS CN, which is sent
via NAS signaling transparently to UTRAN. The PS CN assigns a secondary PDP context for the streaming PS
and requests the RNC to set up the PS RAB. The RNC sets up the streaming PS RAB with the required QoS and
reconfigures the existing interactive/background PS to UL:8 DL:8 kbps. The
PS streaming + PS interactive/background combination is established during the Cell_DCH state.
Radio layers
Application layer
Mobility layer
NRT Application
(browser)
DCH (UL + DL)
Dedicated Physical Channel (UL + DL)
DCH (UL + DL)
Streaming PS RAB (UL + DL) Background PS RAB (UL + DL)
Primary PDP Context
Always-On QoS = Best Effort
Secondary PDP Context
RT QoS = Streaming
TCP/IP RTSP/TCP/IP
signaling
RTCP/UDP/IP
control
RTP/UDP/IP
media
Multimedia Application
(media player)


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
147
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Streaming PS active
During the lifetime of the streaming service the RNC does not reduce or increase the rate of the streaming PS.
The interactive/background PS rate is fixed to UL:8 DL:8 kbps.
When there is heavy congestion in the system that cannot be resolved by actions on the non-real-time RABs, the
RNC will release streaming RABs together with the associated interactive/background PS service. Streaming and
conversational RABs are treated in the same way during congestion. A streaming traffic inactivity detection allows
UTRAN initiated release of inactive streaming RABs.
Streaming PS release
Two different types of release procedure have to be distinguished
CN initiated release
The streaming PS release is negotiated between UE and PS CN via NAS signaling. The PS CN releases the
secondary PDP context, requests the RNC to release the streaming PS, and executes Channel Type Switch-
ing to Cell_FACH. The RNC
releases the streaming PS RAB and maintains the interactive/background PS.
UTRAN initiated release
When streaming user plane inactivity is detected the UTRAN requests the release of PS streaming.
2.10.6.2 CS Streaming RAB for Remote Modem Access
The CS Streaming RAB is needed for CS data services, which use the non-transparent data mode to enable sub-
scribers to access analogue modem servers via fixed networks (Remote Modem Access), e.g. for e-mail synchro-
nization and intranet access.
For CS Streaming class (Non-transparent mode) the application behind the Terminal Equipment (TE), e.g. PC
computer and/or User Equipment (UE) request is unknown. This RAB is mainly used to access the system via the
Radio Layer Protocols (RLP) and Layer 2 Relay (L2R) protocols where the changing requirements can be more
easily satisfied. Here the time delay is somewhat longer enabling missing data to be transmitted to the IWF of the
MSC upon request. The time delay involved is associated with the support mode and enables the MSC to acquire
missing information (retransmission of data) from the accessing entity in order to be able to ensure that the trans-
mitted bit rates match those supported by the requesting entities (TE/UE). Thus, all CS data services are mapped
to the User Plane in the non-transparent support mode that allows the RAB subflow streaming combination to
be adapted to the incoming data.
The establishment of the CS Streaming RAB (Single Call) is similar to that of the current single CS AMR RAB
establishment procedure. The Radio Bearer Translation (RBT) is invoked to determine the RB type and the Trans-
port Format Set (TFS) via the Initial Rate Allocation Mechanism. The CS Streaming RAB is requested when the
RAB parameters included in the RANAP: RAB ASSIGNMENT REQUEST message include the traffic class IE
Streaming and the source statistics descriptor IE Unknown. Since this is an optional feature a check is made
to inquire as to whether or not the service is enabled. If this is not the case, the RAB assignment is immediately
rejected with the cause Requested Traffic Class Not Available.
The RNC continues checking and storing the parameters included in the RAB assignment request and immedi-
ately rejects the CS Streaming RAB when its RAB asymmetry indicator IE is set to an incompatible value, which
is done to avoid UL/DL rates that may conflict with the Maximum Bit Rate (MBR) requested by the Core Network
(CN). The MBR can be either 57,6 kbps, 28,8 kbps or 14,4 kbps; otherwise the RAB assignment is rejected with
the cause Invalid RAB Parameter Value. The same rejection cause applies for the case of a maximum Signaling
Digital Unit (SDU) size other than 576 bits. If any of the RAB parameters are missing from the RAB ASSIGNMENT
REQUEST message, the RAB Assignment is rejected with the cause Semantic Error.
For a detailed description see the FD012231a Additional Bearer Services.


148 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
2.10.6.3 PS C + PS I/B RAB for Realtime Gaming
The Radio Access Bearer (RAB) combination, PS Conversational + PS Interactive/ Background supports the
transmission of only the minimum of realtime data required by an application. The PS conversational QoS class
is used for the first RAB of this multi-RAB because it provides the expedited forwarding Quality of Service (QoS)
inherent to realtime gaming that is presented via the user plane or more simply on the display of the User Equip-
ment (UE) or Personal Digital Equipment (PDA). Any incoming request for data volume reports directed to this part
of the multi-RAB is immediately rejected with the cause set to ''Requested Information Not Available. Should,
however, the data volume request report pertain solely to the PS I/B RAB, the usual request handling applies since
the PS Interactive and Background RAB for this release offers the same QoS on the Iu interface. A player access-
ing a game application is directed to the PS Conversational + PS Interactive/Background via the admission
control and the required connection is setup, giving the player access to the application server and enabling play-
time, acquisition of billing information, etc.
Any requests for data are immediately directed to the Interactive/Background RAB that handles messaging and
data change transmission. Behind all this, the initial rate allocation accounting for Core Network (CN) require-
ments, UE capabilities and the list of RNC supported rates, as well as the appropriate rate combination are used
as input for the Radio Bearer Translation (RBT) algorithm that determines the radio bearer type to be used for the
application being accessed via the gaming portal. Therefore, the final output from the rate allocation mechanism
produces a valid UL and DL rate combination for a particular RAB that fulfils the CN requirements and can be sup-
ported by both the UE and the RNC. The radio bearer translation mapping function then provides the correct type
that is used to derive the Iu/Iub and the radio link control parameters that remain the same for the duration of the
call. If the initial allocation fails due to admission control or signaling problems a single retry is performed.
After successful access to the application the player begins playing as usual, and all data related information,
which may be triggered from both the UE and the RNC side is transported between them via the interactive back-
ground radio access bearer. On the UE side, only game relevant information comes in and any data necessary for
further gaming is stored for the length of the session on the USIM. The information transmitted in the other direc-
tion UE->RNC is stored and evaluated there and when necessary reported back to the UE. All messaging pro-
cesses are triggered by either an action of the player requesting information or gaming accessories, e.g.
multiplayer scores, layer information, tokens, shields, or power-ups or by the RNC requesting specific information.
During a gaming session, any additional connection setup requests for a UE are immediately rejected.
The closing of a session is normally handled by the RNC by releasing the PS Conversational RAB; whereby the
PS I/B is reconfigured to the common channel and traffic volume measurements are restarted. In some cases it is
also possible that both RABs be released, in which case the RNC requests that the RBT retranslate the radio
bearer configuration to the standalone Signaling Radio Bearers. In this case the radio links are reconfigured
(NBAP/RNSAP) and the RRC Radio Bearer Release procedure notifies the UE that both PS RABs have been
released. A third option also exists since the RNC does not maintain the PS Conversational RAB alone: If a
request for PS I/B RAB release comes in, then the RNC sends a request to the CN to be allowed to release both
RABs.
For a detailed description see the FD012229a Realtime Gaming.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
149
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
2.11 Radio Resource Management
The radio resource management (RRM) functions reside in either the UE, the Node B, the Serving RNC or the
Controlling RNC (see Figure 101). The CRNC has the overall control of the logical resources of its UTRAN access
points (i.e. Node Bs), while the UE has access to the CN via the Serving Radio Network Subsystem (SRNS). The
SRNS is represented by the node that holds the current subscriber profile and establishes a link whenever the
subscriber requests communication.
Figure 101 Logical Overview on Radio Resource Management Functions
SRNC CRNC Node B UE
Outer Loop
Power Control
Radio Bearer
Translation
Radio Bearer
Control
Load Control
Admission
Control /
Code Allocation
Congestion
Control
Dedicated
Measurements
ntra-Frequency
Measurements
Traffic Volume
Measurements
OAM Data
Measurement
Control
Handover
Control
RAB assignment,
release, ...
RL setup
RL addition/
removal ...
Transport/physical
channel
reconfiguration ...
RL addition/
removal ...
Common
Measurements
Traffic Volume
Throughput
Measurements
OAM Data


150 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
RNC responsibilities
The SRNC is responsible for the functions relating to a specific radio link (see Figure 102), whereas the CRNC is
responsible for the functions relating to a particular cell, (see Figure 103).
Figure 102 Radio Resource Management Functions in the SRNC
Figure 103 Radio Resource Management Functions in the CRNC
For a detailed description on radio resource management functions see OMN:RN-750 Radio Network Configura-
tion Basics.
Radio bearer translation
The radio bearer translation function maps the Radio Access Bearer (RAB) parameters to the Radio Bearer (RB)
parameters in order to establish a radio access bearer between UE and Core Network (CN). This mapping has to
be performed for each new incoming bearer request. The mapping function is called Radio bearer translation and
provides the following set of parameters:
RLC Mode & Parameters
Radio Bearer MappingPhysical Layer Parameters
Transport Format Set Definition
Transport Format Combination Set Definition
Transport Format Combination Subset Definition
For a detailed description see OMN:RN-750 Radio Network Configuration Basics.
Radio Bearer
Parameter ControI
Radio Bearer
TransIation
Radio Bearer
ControI
Transport ChanneI
Type Switching
Power ControI
Outer Loop Power
ControI
Handover ControI
Intra-frequency
Handover ControI
UE/Node B/SRNC
Measurem. ControI
Measurement
Reporting ControI
Bit Rate
Adaptation
InitiaI VaIues for
Power ControI
Inter-frequency
Handover ControI
Inter-system
Handover ControI
Resource
Admission
Load ControI
Inter-frequency
Congestion
Congestion
ControI
Node B Measurem.
Measurement
Reporting ControI
Power ControI
InitiaI VaIues for
Power ControI
Code AIIocation,
Restriction
ControI
AIIocation ControI ControI
ControI
ReIease
Load ControI
Preemption


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
151
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Radio bearer control
The set of radio bearer control functions aims to optimize the usage of radio resources by adapting the amount of
resources assigned to a UE depending on its traffic load. This is achieved by managing the bit rate adaptation of
the radio bearers to the source bit rate and quality of service (QoS) requirements. The mapping takes into account
the actual system load as well as the actual bit rate and quality of service requirements of the considered radio
bearer. The following set of control functions corresponds to this area:
Bit rate adaptation
Transport channel type switching
For a detailed description see OMN:RN-750 Radio Network Configuration Basics.
Power control
The power control function ensures good call quality by adjusting transmission powers in uplink and downlink. A
low interference among subscribers is an important issue, because some subscribers share the same frequency
band in W-CDMA technology.
The Node B controls the power of both the UE and its own transmission. It controls the output power by means of
inner-loop and outer-loop power control mechanisms.
The FDD mode requires stringent power control, which is based on the following set of functions:
Outer-loop power control (in RNC)
Closed-(inner-)loop power control (in Node B)
Open-loop Power Control (in Node B and UE)
Initialization of power control
DL Power Balancing
For a detailed description see OMN:RN-750 Radio Network Configuration Basics.
Intra-frequency handover control
This function is responsible for the initiation and decision on hard and soft handover within the same frequency.
The handover scenarios supported by intra-frequency handover control are
Intra-Node B (softer handover)
Inter-Node B intra-RNC (soft handover)
Inter-Node B inter-RNC (hard handover)
Inter-RNC intra-CN (soft handover)
Inter-RNC intra-CN (hard handover; Relocation)
Inter-CN (soft handover)
Inter-CN (hard handover; Relocation)
Intra-PLMN (hard handover)
For a detailed description see OMN:RN-750 Radio Network Configuration Basics.
Inter-frequency handover control
This function is responsible for the load distribution between the radio frequency layers and for the handling of
inter-frequency handover.
The handover scenarios supported by inter-frequency handover control are
Intra-Node B handover
Inter-Node B intra-RNC handover
Inter-RNC intra-CN handover
Inter-CN handover
Inter-PLMN (hard handover)
For a detailed description see OMN:RN-750 Radio Network Configuration Basics.


152 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
Inter-system handover control
This function is responsible for the initiation and execution of the inter-system handover and Cell Change Order.
The handover functions supported by inter-system handover control are
UMTS to GSM/GPRS hard handover
GSM to UMTS hard handover
For a detailed description see OMN:RN-750 Radio Network Configuration Basics.
Cell selection and reselection control
The cell selection and reselection functions are used by UEs in Idle mode. If a UE is switched on, it selects a
suitable cell to camp on. When camped on this cell, the idle UE regularly searches for a better cell. If a better cell
is found, that cell is (re)selected.
Two different cases can be distinguished:
Cell selection (in UE)
Cell reselection (in UE)
For a detailed description see OMN:RN-750 Radio Network Configuration Basics.
Hierarchical cell structure
Two different basic radio resource management mechanisms are provided for the support of hierarchical cell
structures:
Load Control
Load control distributes the load within the network. This function determines the frequency layer and cell to
which a UE with a dedicated channel is assigned.
Handover Control
Handover control decides on:
Intrafrequency soft and softer handover
Interfrequency handover
Intersystem handover to GSM
HCS scenarios apply to UEs which are in:
Idle mode or in Cell_ FACH via cell selection or reselection
Cell_DCH state after Connection Setup or CTS by Load Control or Handover control
For a detailed description see OMN:RN-750 Radio Network Configuration Basics.
Resource allocation
The resource allocation function decides whether a new radio link can be admitted in a particular cell or not. Fur-
thermore, it reserves capacity and code resources for the new radio link. So the following functions can be distin-
guished:
Admission Control
Code Allocation
For a detailed description see OMN:RN-750 Radio Network Configuration - Basics.
Admission Control
Basically, the admission control function decides whether or not a new or reconfigured radio link can be accepted
according to the cell load.
For a detailed description see OMN:RN-750 Radio Network Configuration Basics.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
153
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Congestion control
The congestion control function monitors, detects, and handles situations in which the system reaches an overload
situation with the users already connected. Event triggered periodic measurements speed up congestion control
by relieving the system of the signaling load based solely on the previously used periodic measurements.
The Congestion Control (CC) algorithm can be basically described in two stages:
Congestion Decision: Detection of a congestion when the received total wide band power, transmitted carrier
power exceeds a certain level.
Congestion Handling: Selection of the bearers that have to be bit rate adopted/switched/dropped.
For a detailed description see OMN:RN-750 Radio Network Configuration Basics and FD012220c Enhanced
Congestion Control.
HSDPA Iub Congestion Control
Although the flow control mechanism (see HSDPA Iub Flow) optimimizes the utilization of resources at the Iub
interface, it cannot completely prevent congestion. Congestion may occur if the user traffic at the air interface (Uu
interface) is greater than the transport capacity of the Iub interface.
Thus, when the RNC uses the total capacity allocated for all HS-DSCH MAC-d flows, congestion may occur at the
ATM layer (AAL2), with the following consequences:
Packet losses
ATM/AAL2 packets of different users frame protocol (FP) packet data units (PDUs) are lost.
Retransmissions
Retransmissions are initiated by upper layer protocols, such as the radio link control (RLC) and/or protocols
at the application layer. These retransmissions degrade the average throughput per HSDPA user accordingly.
In fact, retransmissions are the main cause for end user throughput degradation, rather than packet losses.
The HSDPA Iub Congestion Control mechanism is provided on top of the enhanced flow control mechanism. This
congestion control mechanism detects congestion situations and properly reacts by reducing the source U-Plane
traffic (FP data rate adaptation to available Iub bandwidth).
For a detailed description see OMN:RN-750 Radio Network Configuration Basics and FD012269 HSDPA
Iub Congestion and Flow Control.
Pre-emption
The pre-emption function allows the establishment of new higher-priority calls in the face of high load by degrading
lower-priority bearers. Basically in case of single PS BE RAB, this is achieved by Re-establishment on FACH. In
the other case, this is achieved by Call Release.
For a detailed description see OMN:RN-750 Radio Network Configuration Basics and FD012243 Pre-Emp-
tion.
Restriction control
This functions permits to restrict the available bit rates within a cell by restricting the allowed minimum spreading
factor:
Restriction of minimum SF on a cell basis
Restriction of cells for operator use only (for CELL_DCH state)
For a detailed description see OMN:RN-750 Radio Network Configuration Basics.
Measurement control
Measurement control is responsible for the configuration of measurements in the UE and the Node B. It must co-
ordinate the measurements performed for different radio resource management functions and for performance
management. Furthermore, it defines the reporting conditions (Measurement reporting control).
For a detailed description see OMN:RN-750 Radio Network Configuration Basics.


154 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
2.12 Handling of Special UEs
Some early UEs in the field do not support certain UTRAN mechanisms. However, the RNC provides specific
handling for early UEs such as:
RAB handling (see OMN:RN-750 Radio Network Configuration Basics)
Measurement control handling (see OMN:RN-750 Radio Network Configuration Basics)
Handling of Transport Channel Information at RAB Release
Handling of RNS Relocation on Cell_DCH
UE Support of HSDPA
The criteria for the identification of early UEs refer to the following UE capabilities (see Table 13) which are
received by the RNC during the RRC Connection Establishment procedure:
RLC capability
Transport channel capability
Physical channel capability
The RNC stores these criteria in the RNC system data to distinguish and identify early UEs (Type A, Type B, Type
C) in order to avoid incompatible configurations at the UE and UTRAN, data loss, and call releases.
UE capability Type A Type B Type C
RLC capability
(Total RLC AM Buffer Size)
10 kb 10 kb 50 kb
Transport channel capability
(Max turbo coded bits transmitted)
2560 bit 2560 bit 2560 bit
Physical channel capability
(Support of PCPCH)
TRUE FALSE FALSE
Table 13 Criteria for the Identification of Early UEs


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
155
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
Early UEs of type A, B, and C do not support all available PS BE rates both in single calls and in combination with
CS AMR/UDI services, see Table 14.
RAB combination RAB rate Special UE supported PS BE rate
RAB 1 RAB 2
RAB 1 RAB 2 UL DL UL DL Type A Type B Type C
Single call PS BE
8 8 -- -- Supported
16 16 -- -- --
32 8 -- -- --
32 32 -- -- --
32 64 -- -- --
64 8 -- -- --
64 64 Supported Supported Supported
64 128 Supported Supported Supported
64 144 -- -- --
64 256 -- -- --
64 384 Supported Supported Supported
128 128 -- -- --
144 144 -- -- --
Multi call AMR PS BE
12.2 12.2 0 0 -- -- Supported
12.2 12.2 8 8 -- -- Supported
12.2 12.2 32 32 -- -- --
12.2 12.2 64 64 Supported Supported Supported
12.2 12.2 64 128 Supported Supported Supported
12.2 12.2 64 256 -- -- --
12.2 12.2 64 384 Supported Supported Supported
UDI PS BE 64 64 8 8 -- -- Supported
64 64 64 64 -- -- --
Table 14 Rate Combinations Supported by Early UEs


156 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d8058010de8b
UTRAN Description
2.12.1 RAB Handling
Some early UEs in the field do not support certain PS BE RAB rates in combination with CS AMR RAB rates. This
is because they have problems to establish a second call in CELL_FACH state due to conflicts between the cell
update procedure and the call setup procedure. In order to reduce call blocking/dropping rate a special handling
is implemented, which identifies such early UEs and prevents assignment of non-supported rate combinations.
The RNC distinguishes different types of early UEs, which is stored in the UE context:
Type A
AMR + PS BE 0/0 kbps not supported, AMR + PS BE 8/8 not supported
Type B
AMR + PS BE 0/0 kbps supported, AMR + PS BE 8/8 not supported
Type C
PS BE 8/8 kbps supported, AMR + PS BE 0/0 kbps supported,
AMR + PS BE 8/8 supported, UDI + PS BE 8/8 supported
The assignment of non-supported rate combinations is prevented by performing call setup for multi-call services
in CELL_DCH state rather than in CELL_FACH.
For detailed information see OMN:RN-750 Radio Network Configuration Basics.
2.12.2 Measurement Control Handling
Some early UE do not support measurement control commands from UTRAN. They send an RRC MEASURE-
MENT CONTROL FAILURE message to the UTRAN due to an unknown measurement ID. As a consequence,
UTRAN initiates call release by sending the RRC CONNECTION RELEASE message to the UE.
In particular, the following handling is implemented for inter-frequency handovers:
If the RNC receives an RRC MEASUREMENT CONTROL FAILURE message from the UE in response to a
request to perform inter-frequency measurements the RNC checks the FAILURE CAUSE.
If the FAILURE CAUSE is unsupported measurement or configuration unsupported, the RNC will
perform the same handling as for normal UEs without releasing the call.
In any other failure cause value the RNC does not perform call release and further attempts to transmit
inter-frequency measurement for this UE are prevented.
If the RNC receives an RRC MEASUREMENT CONTROL FAILURE message from the UE in response to a
request to modify or release inter-frequency measurement, the RNC does not perform call release and further
attempts to transmit inter-frequency measurements for this UE are prevented.
For detailed information see OMN:RN-750 Radio Network Configuration Basics.
2.12.3 Handling of Transport Channel Information at RAB Release
Some early UEs do not support certain transport channel information contained in the RAB RELEASE message
in the CELL_FACH state. Instead, such UEs reply with a RAB RELEASE FAILURE message due to the FAILURE
CAUSE invalid configuration. In this case, the RNC sends the RRC CONNECTION RELEASE message to the
UE. As a result, the setup of a UDI call always would fail when these early UEs are in CELL_FACH and CELL_PCH
state. To avoid this, the RNC retains from setting the IE Deleted UL/DL TrCH information in the RAB RELEASE
message in the CELL_FACH state when an early UE is identified.
2.12.4 Handling of RNS Relocation on Cell_DCH
Some early UEs do not support SRNS Relocation on Cell_DCH. Therefore, an 'SRNS Relocation on DCH system
upgrade' flag is supported in order to allow the operator to switch the feature ON or OFF even if it has been pur-
chased. Additionally, if the RRC failure message is received with failure cause set to 'configuration unsupported',
the SRNC does not attempt another relocation on Cell_DCH for this particular UE.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
157
TED:UTRAN Common UTRAN Description
Id:0900d8058010de8b
2.12.5 UE Support of HSDPA
The SRNC uses the UE capabilities to determine whether or not the UE supports HSDPA and if so, which HS-
DSCH physical layer category it belongs to.
The SRNC determines the UE to be HSDPA-capable if the HSDPA feature is enabled and all of the following is
available:
RRC CONNECTION REQUEST message:
Access stratum release indicator: To be set to REL-5 for an HSDPA-capable UE
RANAP RELOCATION REQUEST message:
SRNS Relocation Info > UE radio access capability > Access stratum release indicator: To be set to REL-
5 for an HSDPA-capable UE
RRC CONNECTION SETUP COMPLETE message:
UE radio access capability > Physical channel capability > Support of HS-PDSCH > Supported -> The
RNC checks if this IE is present for an HSDPA-capable UE
The RNC stores the following information into the UE context that is sent in the UE Radio Access Capabilities IE
of the RRC CONNECTION SETUP COMPLETE message:
RLC capability:
Total RLC AM buffer size: Total receiving and transmitting RLC AM buffer and MAC-hs reordering buffer
capability in kBytes.
Maximum RLC AM Window Size: Maximum supported RLC TX and RX window in the UE
Physical channel capability > Support of HS-PDSCH:
HS-DSCH physical layer category
Otherwise, the SRNC considers the UE as non-HSDPA capable.
For a detailed description see FD012249 Support of HSDPA.


158 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dda
Operation and Maintenance of the UTRAN
3 Operation and Maintenance of the UTRAN
To meet the operators need to control the complexity of the UTRAN system in an efficient and cost-effective way,
an enhanced Operation and Maintenance (OAM) concept is provided. This concept combines OAM functionality
within the Siemens/NEC UTRAN System network elements and via the local maintenance terminals (LMT-
Node B, LMT-RNC), see Figure 104. The Operation and Maintenance Centre (OMC), called Radio Commander
(RC), offers full graphic monitoring and control. It is a software product for OAM network element management
based on an industry-standard SUN UNIX server/workstation platform.
Figure 104 The OAM concept of the UTRAN
The following features maximize revenues and minimize operator maintenance costs:
centralized Operation and Maintenance from the OMC via the operation and maintenance terminal (OMT) by
the Radio Commander (RC)
user-friendly Man-Machine Graphical User Interface (RC and LMT)
simple and effective fault location, fault isolation and recovery
advanced database handling
local OAM functionality on the LMT
The UTRAN OAM functions provide everything needed to operate and maintain the system with respect to the
elements OMC, LMT, RNC, and Node B.
The OAM concept of UTRAN fulfils the requirements of the 3GPP (3rd Generation Partnership Project) standard-
ization.
OMT
Node B #1
RNC
Iu
Iub
Iub 3G MSC
UTRAN
3G SGSN
LMT-RNC
LMT-
Iur
other
RNC
T-interface
Node B
T-interface
Node B
T-interface
RNC
Itf-R
Itf-B
Itf-B
The RNC is completely transparent for Itf-B on logical level
Node B #2
NMC
Itf-N
Node B
LMT-
Node B
RC


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
159
TED:UTRAN Common Operation and Maintenance of the UTRAN
Id:0900d80580118dda
Basic properties:
Multi-vendor architecture (RNC Node B) is supported.
The Node B implementation-specific OAM is removed from the Iub interface (Node B - RNC). The Iub interface
is independent of any vendor-specific procedures.
The implementation-specific OAM functionality in Node B is directly managed by OMC, via a transparent
transport channel through RNC.
RNC is not involved in the management of the Node B implementation-specific OAM.
RNC and Node B provide OAM functionality to manage their own implementation-specific OAM.
This comprises the equipment and functional (radio/transport) resources of a Network Element.
The application layer has two separate OMC interfaces:
OMC - RNC (=Itf-R), and OMC - Node B (=Itf-B)
The logical OAM of the UTRAN is shared between the RNC and its subordinate Node Bs.
According to 3G standardization, the logical OAM is defined by standardized procedures between Node B and
RNC. The operator has access to this OAM part via Itf-R.
The interfaces Itf-R, Itf-B and Itf-N (=OMC - NMC) are object-oriented interfaces that separate internal imple-
mentation from the behaviour and functionality presented externally.
The Radio Commander provides all the necessary OAM functions at the OMC and ensures parallel management
of both GSM and UMTS.
Principles
The primary objective of the Operation and Maintenance System of the UTRAN is to guarantee the availability of
the call-processing functions of the network elements.
Operation is the provision of the required system operability.
Maintenance is the provision of the required system reliability/maintainability.
Standardization
The OAM functionality of UTRAN is based on the following standards:
ATM standards (ATM Forum, ITU, Bellcore)
3GPP recommendations
OSI standards (X.700 series)
TMN standards (M series)
A Q3 interface is used between RNC and OMC and the OMC-NMC interface.
For the Node B implementation-specific OAM, a Qx interface is used between Node B and OMC - the ITU-T X.7xx
series and M.3010 are used on top of a CORBA interface.


160 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dda
Operation and Maintenance of the UTRAN
3.1 Tool Interworking
To meet the operators need to control the complexity of the UTRAN system in an efficient and cost-effective way,
a comprehensive set of tools for planning, operation and maintenance is provided. An overview is given in Figure
105.
Figure 105 Tool Interworking Overview
Radio Commander (RC)
The RC has the following characteristics:
User-friendly System Handling with Enhanced Operability
High flexibility in analysis and configuration via O&M ToolSet
Fast network rollout via multivendor bulk CM interface and O&M ToolSet bulk CM interfaces
Enhanced Network optimization via SCA 1
Optimizing operators workflows via Open interfaces
NMC interface with best in class features for FM, TM, passive CM, common interface for 2G and 3G networks
Within the Siemens/NEC UTRAN System (RNC + Node B + OMC-R + OMC-B + LMT(RNC) + LMT(Node B)), the
Node B NE manager, called OMC-B, is integrated with the RNC NE manager, called OMC-R. Both parts can also
be used independently. The Siemens integrated NE manager for Node B and RNC at the OMC is called Radio
Commander (RC).
Local Maintenance Terminal (LMT)
The LMT has the following characteristics:
Commercially available hardware is used
It has facilities for installation and maintenance visits for all on-site OAM actions, such as initialization, diag-
nosis or testing
All Siemens/NEC entities can be installed without available communications to other entities only by means of
the LMT
The same LMT hardware is used for all entities
LMT-Node B
Initial Software Load
Pre-configured
Node B Database
Radio Commander
Configuration Management
Fault Management
Performance Management
LMT-RNC
Initial Software Load
Pre-configured
RNC Database
CLI Script
Node B DB Editor
configure system
data file (equipment,
transport network,
radio access network)
Radio Network Planning Tool
ATM-Transport-Network
Planning Tool
Site List (Node Bs, RNCs
Radio Parameters (Cells)
Traffic Model
System Data File
IP Addresses
Node B Id
Sales Unique Name
Local Cell Ids
ATM Parameters
O&M Tool Set
Generation of RNC Database (equipment, transport, RAN)
Update/generate Node B Database
Transport Network Topology
VP/VC Mass Provisioning
DBs created by
MIB generator
Symbolic Names
Relationships
Inventory Data
RNC Database
Delta Configurations


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
161
TED:UTRAN Common Operation and Maintenance of the UTRAN
Id:0900d80580118dda
The LMT is designed to
perform operation and maintenance tasks such as data setting and alarm monitoring
act as a master control console to provide system status information
There are two types
the LMT-Node B
the LMT-RNC,
also known as the IMAT (Intelligent Maintenance and Administration Terminal)
For each network entity an appropriate application with GUI and CLI interfaces is available to perform OAM
actions. For a detailed description see:
OGL:RN-750 LMT
OGL:Node B LMT (Platform 1)
OGL:Node B LMT
OAM ToolSet (OTS)
The OAM ToolSet enhances the Radio Commander management functions for even better efficiency. It comple-
ments the Radio Commander with modules in the following management areas:
Configuration management for the Siemens radio network elements
Performance and traffic analysis
Alarm and event statistics and trend analysis
Trace analysis of IMSI traces and cell traffic records.
The OAM ToolSet offers tailored quality reporting through predefined and user-definable Key Performance Indi-
cators. It is a highly modular system with a modular toolbox tailored to the customers Telecommunication Man-
agement Network (TMN) environment.
Node B DB Editor
The Node B database editor is used to insert parameters into the standard configuration which are to be config-
ured individually in order to modify the database downloaded from the LMT to the Node B during installation.
3.2 Function Split of OAM
The operation and maintenance functions are based on the System Management Functions (SMF), which are in
accordance with OSI definitions. They cover various specific tasks such as Fault and State Management, Config-
uration, Performance and Security Management. The function split for the Siemens/NEC UTRAN system has
been chosen according to industry standards, such as those adopted by the Siemens GSM Base Station System.
UTRAN Management Functions (UTRAN-MF)
A UTRAN management function (UTRAN-MF) is a partition of the UTRAN OAM functionality.
UTRAN-MFs are based on 3GPP/ITU-T standards as far as possible; deviations are given for each MF. The
UTRAN MFs comprise the OAM functions for the Radio Network and the Transport Network (ATM) of the UTRAN.
g NOTE
The term UTRAN-MFs as used here should not be confused with expressions used in the standards such as
OSI Management Functional Areas (MFAs), etc.


162 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dda
Operation and Maintenance of the UTRAN
Figure 106 Telecommunications management network model of a Siemens/NEC UTRAN system
Figure 106 depicts the telecommunications management network (TMN) model of the Siemens/NEC UTRAN
System - consisting of the network entity OMC (RC) which comprises NE managers OMC-R (RNC NE manager)
and OMC-B (Node B NE manager), and the network elements, RNC and Node B.
The UTRAN Management Functions are described in more detail in the sections listed below:
Configuration Management
Software Management
Fault Management
Test Management
Performance Management
Alarm Management
Security Management
State Management
Relationship Management
UTRAN-specific Transport Network Management
Performance Management on the Radio Network Layer
(TMN-) Network elements
RNC / Node B
(TMN-) OS NMC
(TMN-)OS NEM OMC
System Management Functions
Q3-interface
RC-link
Q3 (RNC) Qx (Node B) - interface
Siemens/NEC
UTRAN System
F
a
u
l
t
RC
C
o
n
f
i
g
u
r
a
t
i
o
n
P
e
r
f
o
r
m
a
n
c
e
S
e
c
u
r
i
t
y
.
.
.
.
.
.
.
.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
163
TED:UTRAN Common Operation and Maintenance of the UTRAN
Id:0900d80580118dda
3.3 Configuration Management
Configuration management handles information about the network and site configuration of the UTRAN System,
relating to:
initial installation
extension
modification
monitoring.
Network configuration defines the call processing behaviour of the UTRAN.
In the UTRAN system, all resources which can be accessed by OAM are represented by managed objects (MO).
Depending on their properties, resources are divided into one or more of the following types of MO:
functional MOs for logical resources (e.g. cells)
hardware MOs for physical resources (e.g. interface cards, LAN equipment)
The primary task of configuration management (CM) is to define and modify the
configuration of the network entities of the Radio Network Subsystem for all supported and managed objects.
Each entity stores its own configuration data (RNC, Node B, OMC). The collection of all configuration data within
one entity is called the management information base (MIB). Configuration data can also be exported to additional
tools. New elements or changes to the current configuration are introduced via the Radio Commander.
Configuration management for the UTRAN System encompasses the following:
Creation, modification and deletion, and reading of the attributes of logical managed objects (LMO) and imple-
mentation-specific managed objects (I-S MO) from both OMC and LMT. Configuration management of the
Radio Commander allows the display of up-to-date configuration information on the graphical user interface,
which makes recurring configuration tasks for the operator as easy as possible.
Dynamic network optimization. Configuration changes of MOs or the modification of MO attributes are
possible during operation. They do not interrupt or degrade subscriber traffic as far as it is not directly related
to the changed MOs.
Re-versioning of the configuration data. During re-versioning, a configuration
- which existed before changes were made - is restored.
Independent creation and deletion of LMOs and I-S MOs. LMOs and I-S MOs may be created and deleted
independently, as long as the containment hierarchy is not violated. For example, this allows the support of
creation in advance.
Storage of the instantiated LMOs and their attribute values in a master database located in the RNC.
Storage of the instantiated I-S MOs and their attributes in a master database in the relevant entity (OMC,
Node B, RNC).
Each NE provides a facility to update its configuration data. The OMC is informed of any NE configuration data
updates, to maintain data consistency.
Symbolic names.
Alignment of the various databases with respect to managed objects, attributes and symbolic names.
Facilities to ensure consistency of configuration data in Node B and RNC, and, in particular, consistency
between Node B I-S MOs and the RNC LMOs.
Provision of interfaces to post-processing applications (offline tools) related to configuration management.
The CM bulk part of the interface from OMC to NMC (Itf-N) is compliant to 3GPP TS32.101, TS32.102 and
TS32.106.
Configuration management deals with managed objects. These managed objects model the Network: the
managed objects represent the physical (equipment-related) and logical (function-related) entities that build the
network.
Within the Radio Commander, the network is represented in the form of a containment tree. This hierarchy is
mapped according to the different layers of panels within the GUI.


164 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dda
Operation and Maintenance of the UTRAN
As a rule, changes in configuration data are made in confirmed mode, which means that the operator will always
receive feedback on the results of the operations.
The Radio Commander is able to request information on the configuration of hardware, firmware and software
from each network element and from the OMC itself (OMT, printers etc. - see Management of OMC Configura-
tion).
Configuration data can be exported to/imported from external back-up media, such as floppy disks or streamers.
There are two different configuration management interfaces for NEs (Node B, RNC):
The command interface creates, modifies, and deletes configuration data by way of single commands.
The file interface creates the complete configuration of an NE by downloading a database file to the NE and
activating it.
For detailed information see OMN:RN-750 Equipment Configuration Basics.
3.4 Software Management
Software management (SWM) within the UTRAN system comprises the following functions:
import/export of UTRAN software from/to external media
distribution and activation of UTRAN software
version change of UTRAN software
maintenance of parallel versions of UTRAN software
administration of software in the Network Entities (NEys) such as swLoads and patches.
upload/download of databases, firmware and optional feature packages
For detailed information see OMN:RN-750 Software Management Basics.
Partitioning of data
In the UTRAN system, the software for the UTRAN-NEys can be loaded remotely. In order to achieve this, the
UTRAN software is grouped into software packages for the various boards within an NEy. These software
packages are then grouped again into a logical context for a complete NEy.
The master copy of the software files for UTRAN-NEys is located in the NEy itself. On the OMC hard disk, the
UTRAN NEy software can be seen as a maintenance copy with no consistency checks against the copy in the
NEy.
swLoad
A swLoad represents the complete code (executable, static data, etc.) needed to run a Network Entity.
A swLoad contains a header file and software images. In addition, it may contain a VAM (Version Attachment
Mechanism) file and descriptive files. It is identified and referenced by the swLoad header file.
Software management on OMC
The software management on OMC (the Radio Commander) provides the operator with various services relating
to the UTRAN-SW, including:
import/export of software files to/from OMC
deletion of swLoads from the OMC disk
download of complete swLoads from OMC disk into RNC/Node B
activation of swLoads in RNC/Node B
maintaining of attributes of swLoads (e.g. backup, fallback software load, etc.)
display of version information of the UTRAN software in the system
patch handling for RNC
handling of RNC FW files
import FW from external media (CD-ROM, tape, floppy)
download FW to RNC


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
165
TED:UTRAN Common Operation and Maintenance of the UTRAN
Id:0900d80580118dda
Software management on LMT
Software management on LMT provides the functionality of importing swLoads from CD-ROM into RNC/Node B.
It allows the local administration and maintenance of the NEys SW.
Software management in RNC/Node B
The software management in RNC/Node B handles all requests regarding the
software files stored in RNC/Node B.
It checks if a download/activation request can be granted, is responsible for completeness checks, the integrity
check and/or compatibility checks of the software load, and distributes the software images onto the relevant
boards of the NEy. It administers the NEys software attributes and also provides information on running and
stored swLoads to the operator.
Software management application for Node B
The Siemens Common Application ISS (Integrated Software Management Solution) provides an easy handling of
NodeB Software/Database/Firmware Management activities with the RC. The GUI-driven ISS tool offers conve-
nient and guided handling. Operators can easily manage Node B software, database or firmware updates for
either one or a group of or all Node Bs in a network, and always have a comprehensive overview of the software
status in the network.
3.5 Fault Management
Fault management (FM) includes all measures required for detecting and repairing faults in a mobile radio com-
munication network, independent of the technology used. Fault management is therefore a key feature for the reli-
ability, availability and survivability of mobile radio networks, especially in heterogeneous and multi-technological
environments.
As a general rule, appropriate recovery actions should be selected which affect service as little as possible. There-
fore, all Siemens/NEC UTRAN NEs provide a recovery escalation mechanism which is able to start with a low-
level recovery action and only escalates to higher levels if necessary.
The guiding principle for the function split between the UTRAN network entities is to perform as much fault treat-
ment as possible inside the faulty network element itself.
This autonomy-oriented concept of fault treatment is based on the principle of internal redundancy that is realized
in all relevant HW components of the UTRAN system.
Fault management is split up among all supported network entities.
For detailed information see OMN:RN-750 Fault and Test Management Basics.


166 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dda
Operation and Maintenance of the UTRAN
3.6 Test Management
In the UTRAN concept the important functions of test management are not only a part of fault management, but
are also a separate application of their own. Tests can be performed with or without operator control. Only
hardware is tested.
The primary functions of test management are:
location and verification of any faults detected in a specific hardware unit by the hardware checkers
detection and location of any latent faults in hardware units by means of periodic routine tests performed on
less frequently used units, modules, or devices
checking of new hardware component functions.
After a fault has been eliminated, for example by replacing a defective board, the repaired device is checked and
the unit can only be restored to traffic if it checks out OK.
Operator-controlled tests can be initiated locally from LMT or remotely from OMC. The test routine is executed at
the NEy. A test result message is sent back to the LMT/OMC and may be displayed and logged there.
For detailed information see OMN:RN-750 Fault and Test Management Basics.
3.7 Performance Management
Performance management (PM) in UTRAN provides comprehensive information on the efficient use of existing
infrastructure, allowing powerful performance analysis and generation of performance-related post-processing
statistics for network optimization.
Measurements are performed for the Radio Access Network (see Performance Management on the Radio
Network Layer) as well as for the Transport Network on ATM (see Performance Management on the Transport
Network Layer).
UTRAN performance measurement data is collected and recorded by the Network Elements (NEs). The resulting
performance measurement data produced within each NEy is transferred to both Radio Commander and/or LMT,
and is finally presented in the OAM ToolSet or in 3rd party PM analysis tools.
A measurement job can be initiated by a command from RC or LMT. This job is established in the network element
and collects the specified measurements, which are stored in files according to the ASN.1:BER specification of
3GPP TS32.104/TS32.403.
The operator can establish measurement jobs with individual parameters, and can also administer measurement
jobs interactively, for example:
create/delete measurement jobs
start/stop measurement jobs
set/get attributes
request/present result files
The NE-internal collection of measurements can be scheduled by specifying a measurement interval (granularity
periods are 5, 15, 30, 60, 360, 720 and 1440 minutes).
Additional information can be found in the following documents:
OMN:RN-750 Performance Management Basics
TED: Performance Measurement Counters
TED: Performance Measurement Message Flows
Performance Measurement: Key Performance Indicators


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
167
TED:UTRAN Common Operation and Maintenance of the UTRAN
Id:0900d80580118dda
3.7.1 Performance Management on the Radio Network Layer
UTRAN provides a large number of performance measurements (PMs) within specific radio network management
to give operators a clearer view of how their network is working. Operators are enabled to improve the overall
supervision of their network and to use measurement evaluations for network planning/optimization and trouble-
shooting.
An overview of measurements on RNC is given in the following list:
Procedure-related measurements
Paging
Signaling
RRC connection
RRC connection re-establishment
RAB assignment
Channel reconfiguration
Cell update
Radio Link
Soft handover
Soft and UTRAN hard handover
Inter-system hard handover
Relocation
Iu release
Drifting UEs
Radio Bearer
Bit Rate Adaptation
HS-DSCH Radio links establishments
Radio Bearer reconfiguration
Subsystem-related measurements
Internal measurements
(allocation and throughput)
Iub throughput (RNL)
Iu throughput (RNL)
Iur throughput (RNL)
Blocking
Channel
UE quantity
Radio (RTWB and TCP)
RRC states
3.7.2 Performance Management on the Transport Network Layer
Common requirements for performance monitoring
Management systems can retrieve indications from the NE about the correctness of the collected data.
Performance monitoring for physical layer
The NEs support performance management and fault management of their physical interfaces. Failure notifica-
tions include threshold alerts for unacceptable performance (error) rates. Performance data includes transmission
counts of Errored Seconds (ES), Severely Errored Seconds (SES), Coding Violations (CV) and Unavailable
Seconds (UAS).
The E1/J1/T1 and STM-1 interface types are supported by the NEs. The STM-1 interface supports ES, SES, CV
and UAS, while the E1/J1/T1 interfaces do not.


168 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dda
Operation and Maintenance of the UTRAN
ATM cell level protocol monitoring
ATM cell level protocol monitoring involves the collection and thresholding of data counts that measure an ATM
NE's ability to successfully process and deliver incoming ATM cells and to diagnose cell processing malfunctions.
The management system can retrieve current and historical counts of the following data from each ATM interface
terminating on the ATM NE (5 separate counters):
discarded cells due to HEC Violation
discarded cells due to congestion
VP and VC layer performance monitoring
Performance information is useful for both the virtual path and the virtual circuit levels of information passing
through an NE. The management makes it possible to initiate VP/VC performance monitoring on all VP/VC termi-
nation points by means of ATM scanners.
The OAM feature enables management systems to retrieve current counts of the number of (CLP=0+1) cells
received and transmitted at each VPL.
Performance management of OAM flows
The operations interface enables the management application to initiate VP/VC performance monitoring on a
limited number of VP/VC termination points. The data is used by the management system to compute the cell loss
ratio.
The operations interface also enables management applications to retrieve current counts of the user cells and
lost cells from each VP/VC termination for which performance monitoring is performed.
If the performance management of OAM flows is supported, the NE supports the counters for lost cells, misin-
serted cells and user cells.
AAL protocol performance monitoring
The approach for AAL performance monitoring is based on maintaining counts of errors in received Segmentation
And Reassembly (SAR) and Convergence Sublayer (CS) Protocol Data Units (PDUs) per VCC termination point.
The following counters are supported:
number of AAL5 transmissions and receptions per VCL
number of AAL5 reception failures per VCL
number of AAL2 transmissions and receptions per VCL
number of AAL2 reception failures per VCL
Performance monitoring for signaling transport protocol
The counter number of SSCOP re-transmissions per VCL is supported.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
169
TED:UTRAN Common Operation and Maintenance of the UTRAN
Id:0900d80580118dda
3.8 Alarm Management
If an alarm condition occurs inside a Node B or RNC, an alarm event report is generated. If the new alarm condition
is an active one, a corresponding active alarm record is created and stored inside the network entity which
contains the respective management object (MO).
If an alarm condition is cleared inside a Node B or RNC, an alarm event report with perceived severity cleared is
generated and the severity of the corresponding active alarm record is set to cleared. No cleared message is sent
if an alarm condition with severity warning has been eliminated.
Alarm classification
Alarms belong to one of the following types:
Communications Alarm
An alarm of this type is principally associated with the procedures and/or processes required to convey infor-
mation from one network node to another.
The RNC is responsible for reporting failures on the Iub, Iu and Iur interfaces and propagates alarm notifica-
tions that were issued from a Node B.
Quality of Service (QoS) Alarm
An alarm of this type is principally associated with a degradation in the quality of a service and is issued as a
result of performance measurements. QoS alarms help the operator to
evaluate and gauge thresholds for performance management
modify (add, remove, activate, deactivate) thresholds
administer QoS alarm severities
QoS alarms can be configured for the purpose of performance measurement and load assessment.
The RNC can generate a QoS alarm of its own if a threshold of its CPU usage has been exceeded.
For detailed information see OMN:RN-750 Fault and Test Management Basics.
Processing Error Alarm
An alarm of this type is principally associated with a software or processing fault.
Equipment Alarm
An alarm of this type is principally associated with an equipment fault.
Environmental Alarm
An alarm of this type is principally associated with a condition relating to an enclosure in which the equipment
resides. The RNC and the Node B feature an input connector for external alarm sources such as smoke or
temperature sensors.
For more information on alarms see OMN:RN-750 Fault and Test Management Basics.
3.9 Security Management
In accordance with the ITU-T recommendation X.700, security management of the UTRAN system provides the
following features:
user authentication per NE
user authentication on OMC (see TED:RC)
authorization and access control
reporting and logging of security-related events
administration of Security Management.
encryption of communication with NEy


170 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dda
Operation and Maintenance of the UTRAN
3.9.1 Security in the OMC
Security management at the OMC is performed by the Radio Commander.
The special feature of the Radio Commanders security management is that various parameters can be used to
grant access rights, according to the operators workflow concept:
full access rights at network element and UTRAN management function level
time-controlled user access
session control (abort and disconnect) by the system administrator.
All the above contributes to increased security and greater flexibility in security management, combined with effi-
cient handling all of these features being key requirements in growing multi-technology and multi-vendor net-
works.
Further features implemented for UTRAN are:
managing and processing global user profiles
processing and browsing all security-related events issued by the managed RNCs or Node Bs
assuring the security of OAM message transportation by encrypting the messages (IP sec)
User authentication
Every user has to go through a two-step authentication procedure that includes entering his/her user name and
password in order to:
log in at UNIX level
log in at Radio Commander application level.
However, if the user name and password are identical for both UNIX and the Radio Commander, the second step
will be performed automatically.
The Radio Commander handles passwords in the following way:
passwords are not displayed during input
passwords can be changed by the user (two-step confirmation)
passwords can be changed by the administrator without knowledge of the previous password
passwords must have a minimum length of 8 characters
case-sensitivity is supported
a black list of words not to be used as passwords can be kept by the administrator
pattern matching management is provided
password aging management is provided
password history checks are performed, such as that the last n password(s) must not be used again by the
same user
failed login counter is provided; for example, access is disabled for the user after a configurable number of
failed login attempts (but can be re-enabled by the administrator)
accounts with expired passwords are blocked
no transfer of passwords in plain text is possible between systems, not even between OMP and OMTs.
User profile
The user profiles are defined and controlled independently per NE basis. This ensures independent operability of
NE from OMC even in the case of OMC link outage.
Time permission
Time permissions are checked whenever a user logs in or a screen lock is released.
Authorization profiles
The authorization concept concerns the definition and control of various levels of access to specifically autho-
rized people. Authorization profiles make sure that only authorized staff can perform specific operations.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
171
TED:UTRAN Common Operation and Maintenance of the UTRAN
Id:0900d80580118dda
The Radio Commander comes with four default authorization profiles:
system administrator
configuration user
read user
monitor user
The Radio Commander system administrator can define new authorization profiles dynamically. He/she can
create a new profile and can list, modify and delete predefined authorization profiles.
Authorization may refer to:
network entities
UTRAN Management Functions
services and actions, such as DO, SET, GET
access to logging data via an SQL interface.
The possibility of defining authorization profiles supports the concept of management areas.
Access control
All Radio Commander access control mechanisms are based on comprehensive security checks, such as:
is the accessing terminal registered and unblocked?
is the accessing user registered and has he/she verified his/her identity correctly?
The Radio Commander will not just trust any remote system, without checking the user seeking access. For
example, in the case of a TAC access request, the Radio Commander operator needs to explicitly grant
access, regarding starting times, time intervals, etc.
Screen locking
The screen will be locked if:
the user has not been active (no input) for a defined amount of time.
the operator issues a lock command.
Security audit trail
In order to be able to track security-relevant events, the Radio Commander generates and logs certain events in
the form of security records within the OMP database.
The following events are generated and logged by default:
user login/logout
session lock/unlock
unauthorized command input (CLI)
expiration of permitted time period during running session
security-related administrative activities (user creation/deletion, user profile creation/change/deletion, user
permission change, user password change, change of interface lock time)
blocking/releasing of LMT connection
session abort by system administrator
deletion of logging data.
The system administrator or any other authorized user can select, display, print, and archive security records (on
external backup media).
Forced session control
The Radio Commander system administrator can:
abort a user session at any time
disconnect (lock) a specific terminal on the UNIX level to quickly counteract any security problems.


172 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dda
Operation and Maintenance of the UTRAN
3.9.2 Security in the LMT
An LMT is a self-contained computing system that can be connected to a network element of the UTRAN system
(Node B, RNC) in local or remote mode.
The security facilities provided by the operating system of LMT and a user login procedure are used to prevent
illegal or unauthorized access to the LMT application.
The LMT application itself provides comprehensive security features such as:
checking, processing and forwarding login parameters such as user ID, password, login mode, to the UTRAN
network elements concerned,
encrypting passwords,
assuring the security of transportation of security-related information.
Authentication
The authentication procedure in the LMT is designed to work even when the link between OMC and NEy is not
available. The LMT is able to work at an initial installation of an NE, where the link to OMC is not yet established.
In this sense, the security in the LMT works rather independently from OMC.
Authorization and access control
After successful authentication a user is logged on several access levels in to the LMT.
Administration of LMT users from LMT
In order to administer various users of the LMT, it is possible for specially authorized users of the LMT to administer
other users locally at the LMT.
Terminal and session behaviour
At the LMT, the Windows screen lock can be applied and the screen will be locked in the following cases:
when an operator command has been issued or
after a predefined user inactivity period.
Warnings for dangerous actions
The user is warned with a message box, and asked for confirmation, before LMT allows execution of dangerous
actions which are service affecting (e.g. reset actions, SW activation, loop activation, locking).
Security features in RNC
For OAM access by the LMT (local/remote), the RNC provides the following features:
implement local authorization profiles
display the relevant security information for a user profile
implement a complete authentication procedure including locking/unlocking login accounts
process and issue security-related events to the OMC
assure the security of transportation of security-related information
Therefore, after a successful login procedure, the NEs provide user profiles which are used to grant access rights,
depending on the authenticated user.
The user profile contains the following: user ID, local access password, time permission, NE permission, and a
reference to an authorization profile.
The authorization profile contains access rights to specific functionality or resources.
The NEs grant/deny access rights to:
a user account
an LMT command or command group


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
173
TED:UTRAN Common Operation and Maintenance of the UTRAN
Id:0900d80580118dda
The NEs provide:
authentication requirements (password handling, etc.)
system access control requirements, such as the time-out feature.
The NEs support administrator functions as separate from other user functions.
3.10 State Management
State management of the UTRAN system refers to X.731[15] for semantics and to X.721[12] for syntax.
Tasks of state management are to:
report changes of state and status attributes (event type: State Change Event Reports (SCERs) of an MO)
read state and status attributes (GET) of an MO
change some of the state and status attributes (single SET or ACTION)
evaluate state/status attribute values
represent the essential state/status information which applies to the maintenance state and maintenance view
concept
The following paragraphs describe how functions are split up between the NEs.
Node B state management
Node B state management only acts in the agent role.
RNC state management
RNC state management acts in the agent role for UTRAN logical MOs and for RNC implementation-specific MOs.
It acts in the manager role for Node B logical MOs, such as the NBAP protocol of 3GPP, controlling cells and
other logical MOs. On the other hand, Node B implementation-specific MOs to OMC-B are left untouched when
being transferred through the RNC.
OMC-R state management
In the manager role, the Radio Commander application state management provides the operator with access to
and control of the state and status attributes of all UTRAN logical MOs of the RNC, the I-S (implementation-spe-
cific) MOs, and the local OMC-R MOs.
In the agent role, the Radio Commander state management provides services for the OMC-NMC interface and
for the local OMC-R MOs. OMC-R state management is the master of all state and status attributes of its equip-
ment MOs (e.g. interface cards) and of all MOs which represent external devices (e.g. LAN equipment, such as
routers).
OMC-B state management
In the manager role, the Radio Commander state management provides the operator with access to, and control
of, the state and status attributes of all Node B I-S MOs, as well as the state and status attributes of the local
OMC-B MOs.
In the agent role, the Radio Commander state management provides services for the interface Itf-N (OMC-NMC)
and for the local OMC-B MOs. OMC-B state management is the master of all state and status attributes of its
equipment MOs (e.g. interface cards) and of all MOs which represent external devices (e.g. LAN equipment such
as routers).
LMT state management
LMT state management always acts in the manager role and allows monitoring and controlling of the state and
status attributes of the connected network entity (Node B, RNC).


174 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dda
Operation and Maintenance of the UTRAN
3.11 Relationship Management
Relationship management supports the operator in carrying out OAM tasks by providing information that makes
him/her understand the dependencies between MOIs. Relationship management functions are visible to the
operator when navigating between panels or creates additional attributes and operations for objects to provide
valuable information. In general, relationships are modelled according to [X.732], i.e. by adding specific relation-
ship attributes to the MOs.
To give an idea of how relationship management makes work easier for the operator, some aspects of service
relationship are described below.
Service relationship
Service relationships are needed for configuration and fault management tasks as they relate e.g. objects in dif-
ferent management domains like transport and equipment. These relationships are established and kept up-to-
date either automatically by the NEy implementing the interface, or manually by the operator.
One of the most important tasks of relationship management is to provide consistent relationships between local
cells and Hardware Managed Objects (HMOs). This service relationship supports the operator when mapping
between radio access network and equipment, e.g. for analysing alarms. The list of HMOs contains those boards
that specifically provide a service for a given local cell.
Service relationships are implemented by using relationship attributes which can be single or set-valued depend-
ing on the multiplicity of the relationship. They can be set either by the operator or automatically by the system.
A service relationship can be described as an association between MOs of two MOCs (Management Object
Class). One MOC is a service provider and one is a service user. Both MOCs belong to the same NEys/interface.
There are no service relationships between MOs of different NEy/interfaces.
Service relationships are accessible at the OMCGUI, CLI, and LMT.
3.12 UTRAN-specific Transport Network Management
UTRAN provides specific transport network management for Node B and the RNC by including the following func-
tions:
Configuration Management
Fault Management
Performance Management
Performance Testing
Quality of Service for ATM traffic
3.12.1 Configuration Management
The operation interface supports network management application requests for retrieval/configuration, relating to:
Physical transmission system
ATM traffic
AAL traffic
Signaling protocols
Physical transmission system
configuration of the following physical interface types:
E1/J1/T1, STM-1/OC-3, ATM over Fractional E1/J1/T1, IMA, CES on ATM links (STM-1/OC-3, IMA on nxE1)
configuration of Automatic Protection Switch mode for STM-1/OC-3 interfaces


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
175
TED:UTRAN Common Operation and Maintenance of the UTRAN
Id:0900d80580118dda
ATM traffic
configuration of ATM layer parameters related to interfaces
management of cross connections within an ATM-NE
management of connection termination and its cell rates
activation and deactivation of continuity check
configuration of performance management OAM flows
traffic shaping
internal resource handling of RNC internal parameters
AAL traffic
assignment of AAL types (AAL1, AAL2 or AAL5)
configuration of AAL1, AAL2 or AAL5 parameters
support of AAL2 Switching in the Core Network
Signaling protocols
fulfilled requirements for MTP-3b (Q.2210), for B-MTP (YDN 102-1998), for SCCP (GSM8.06), for B-SSCP
(YDN 122-1999), for SSCF-NNI (Q.2140), for SSCF-UNI (Q.2130), for SSCOP (Q.2110), for AAL2 signaling
(Q.2630), for AAL1 signaling (Q.2110)
configuration of signaling links/routes and signaling profiles
For detailed information see OMN:RN-750 Transport Network Management Basics.
3.12.2 Fault Management
Events are correlated in order to avoid a large number of recorded events if a parent event causes multiple indi-
cations of performance impairment at different layers.
A check of the persistence of defects is performed in order to detect defects for which a notification could be sent
to the local and the remote management system through the TMN.
It is possible for the local or remote management systems to receive notifications issued as a result of failure
detection or performance impairment concerning the
Transmission system
ATM traffic
Transmission system
Fault management for the different types of physical interfaces for the RNC and Node B supports notification of
failures like LOS (Loss Of Signal), LOF (Loss Of Frame), AIS (Alarm Indication Signal), and RDI (Remote Defect
Indication). If the RNC detects a physical line fault (i.e. LOS, LOF, AIS) a RDI signal is sent on the physical layer
in backward direction to the far-end. According to the standards (ITU-T G.7710 and ETSI 300 417-1-1 V1.2.1)
transmission of the RDI signal is stopped immediately after the related defect disappears.
For fault localization, the physical interfaces provide the possibility to loop the transmitter signal back to the
receiver.
Fault Management functions located on the adoption layer between the transmission layer and the ATM layer
support failure notification of LCD (Loss of Cell Delineation).


176 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dda
Operation and Maintenance of the UTRAN
ATM traffic
AIS and RDI defect indication
When a defect affecting a VPC or VCC (e.g. LCD) is detected at any point other than the terminating end point,
the NE inserts fault management OAM cells with an AIS function type into the VPC (VCC) cell in the down-
stream direction, respectively.
When a VPC (VCC) end point receives AIS cells or enters the fault state because of an ATM defect, the NE
inserts fault management OAM cells, carrying an RDI function type, into the (VPC VCC) cell in the upstream
direction respectively.
When an NE receives RDI cells on a VPC (VCC) end point that is not in the fault state, the VPC (VCC) end
point at that NE enters the RDI state. The VPC (VCC) exits the RDI state when no RDI cells have been
received for a certain period of time. The NE declares an AIS or RDI failure on a connection when the AIS or
RDI defect state persists for 3.5 +/- 0.5 seconds. The NE sets local failure indications and, based on parame-
ters set by the management system, may provide an indication (i.e. a failure notification) to the appropriate
management system.
F4 and F5 OAM flows (i.e. end-to-end and segment OAM flows over ATM connections) like loop-back func-
tions, continuity check or performance management of OAM flows are activated via TMN.
A source point of a VPC (VCC) segment discards all VPC (VCC) segment OAM cells coming from the outside
of this segment no matter what their OAM function type is.
Upon reception of the OAM cells with RDI and AIS indications, the RNC automatically sets the state of the VPs
and VCs on the faulty physical line to fault and stops setting up new connections on this line. An alarm
message is sent to the Operator for notification. Radio Bearers whose AAL2 connections have been estab-
lished on the failed physical line are also released. When the RNC stops receiving OAM cells with AIS and
RDI indications, the states of the affected VPs and VCs are changed back to use and an alarm recovery noti-
fication is sent to the operator.
ATM OAM continuity check
ATM OAM continuity check is an in-service mechanism to detect ATM layer defects in real-time. It is a basic
ATM feature typically supported by all ATM network elements and used for maintenance purposes. The
purpose of ATM OAM continuity check is to indicate to the far end (sink point) that a connection is alive even
when it carries no user traffic data.
The operations interface supports management application requests to perform OAM cell continuity checks.
The ATM NE performs an OAM cell continuity check by inserting/extracting a continuity check OAM cell. The
VPC/VCC OAM cell continuity check monitoring can be performed on the segment connection or end-to-end
connection. In the case of a failure situation (loss of continuity), a failure notification is sent to the management
system.
Loop-back tests
The NE supports management system requests for OAM cell loop-back tests and end-to-end loop-backs. The
NE acts as an OAM cell insertion point and as an OAM cell loop-back point, respectively. The NE reports the
result of the loop-back test to the management system.
For detailed information see OMN:RN-750 Fault and Test Management Basics.
3.12.3 Performance Testing
During a software upgrade, which is assumed to be carried out during quiet periods to avoid impact on service,
field tests should be carried out in order to evaluate whether the new software works as expected. In order to
emulate a busy environment as expected during peak hours, performance testing is required.
DL load generation (DLLG)
By means of the DL Load Generation (DLLG) feature, performance testing functionality is implemented for the
common downlink physical channel. DLLG is a convenient operator function designed to simplify network config-
uration by supplying the environment necessary for both online and offline testing. It proposes a good tool for


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
177
TED:UTRAN Common Operation and Maintenance of the UTRAN
Id:0900d80580118dda
testing performance, for example after software upgrades as well as during operation. Testing is done by gener-
ating a pseudo-interference environment on the Node B downlink expected during peak operation time, which
more or less means creating a simulated load to mirror peak performance. This gives operators the opportunity to
evaluate network performance and coverage through field testing without the pressure of online activities in per-
forming networks or the need for large amounts of user equipment (UE).
This feature offers DLLG for 1st (PF1) and 2nd (PF2) platform Node Bs for testing inter-system handling, which is
very useful during the Node B installation stage. Downlink load generation means loading a dummy DPCH (ded-
icated physical channel) and, when necessary, a defined Primary Common Pilot Channel (PCPICH), Primary
Common Control Physical Channel (PCCPCH), Primary Synchronization Channel (PSCH), Secondary Synchro-
nization Channel (SSCH), Page Indication Channel (PICH) and Secondary Common Control Physical Channel
(SCCPCH) with a specified channel code, scrambling code, power, etc. It is started by the Node B on receipt of
an OAM command from the RC-Node B or LMT-Node B requesting DL load generation for reserved resources.
Field testing software upgrades is a must for operators to ensure that the new software version works as expected
and to avoid the tension of unknown performance during operation.
Usually, operators have to reserve resources before starting DL load generation to ensure that they are available
and that calls will not be dropped. With this feature the RC-Node B or the LMT-Node B manage the procedure
automatically.
Orthogonal Channel Noise Simulation (OCNS)
The OCNS feature is an extension of the existing feature DL load generation (DLLG). The main difference is the
ability to apply time variant power profiles for each UE instead of having a constant power level. ONCS can be
used for testing the network performance and coverage of the system under load without having many UEs placed
in the cell. This is realized by pseudo interference, which is generated and transmitted (in addition to the signal for
the real users) from the Node B with properties comparable to real users including power control effects due to
fading.
The OCNS is setup with the mechanisms of DLLG. DLLG or OCNS can be chosen by means of a command
parameter. Mixed operation, i.e. both OCNS (time variant power) and DLLG (constant power) simultaneously on
the same CHC96 is also possible.
Trigger of periodic UE measurement
For evaluation of UTRAN performance the following key performance indicators can be calculated by means of
external equipment:
DL BLER
CPICH Ec/No
CPICH RSCP
The corresponding measurements are performed by the UE, but can also be initiated simultaneously by the RNC
through RRC-message. They are performed periodically with a configurable period of measurements, just ignoring
the measurement reports coming from the UEs. The period of the measurements is the same for all 3 measure-
ment types. This allows the UE to send multiple measurements in one unique RRC-measurement report. On the
one hand this minimizes the message flow from UEs to RNC. On the other hand the quality of DL BLER measure-
ments is related to the reporting interval of CPICH Ec/No and CPICH RSCP increasing with longer reporting inter-
vals.
Simultaneous activation of the 3 periodical measurements is initiated according to the following sequence:
1. Establishment of dedicated physical channel.
2. Activation of existing intra/inter frequency measurements.
3. Activation of CPICH Ec/No and CPICH RSCP measurements as periodical measurement, but without report-
ing.
4. Activation of DL BLER as periodical measurement including additional measurements for the report of CPICH
Ec/No and CPICH RSCP, with periodical reporting.


178 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dda
Operation and Maintenance of the UTRAN
3.12.4 Quality of Service for ATM traffic
In principle, ATM traffic leaving the RNC must conform to the so-called traffic contract. For each VP (and VC) this
traffic contract defines the peak cell rate (i.e. the maximum bit rate) and optionally a cell delay variation tolerance
(CDVT), i.e. a tolerance threshold for the peak cell rate due to cell jitter. Such a traffic contract provides the guide-
line for proper resource reservation across ATM networks and inside ATM nodes (like RNC and Node B) or ATM
switches.
In todays ATM networks two methods are applied to enforce the traffic contract:
Traffic policing
Traffic shaping
Enforcement of the traffic contract guarantees and improves the quality of service of the various ATM connections.
Policing enforces traffic contracts by discarding non-conforming ATM cells and is mainly applied at the ATM
switches of user-network interfaces. Traffic shaping is much smoother as non-conforming cell bursts are tempo-
rarily buffered and sent one conforming cell at a time.
Traffic shaping
Traffic shaping for up to 512 shaped VPs on the Iub is provided in order to increase the number of shaped VPs
per STM-1/OC-3 line. The Node B connectivity of the RNC can thus be extended while guaranteeing QoS on the
ATM layer. The shaping functionality also comprises VC shaping on the Iu/Iur interfaces and VP for E1/J1/T1 on
the Iub interface of the RNC (supported by eRNC (MDTI card) only). The benefit of traffic shaping is illustrated in
Figure 107.
Figure 107 The benefit of traffic shaping
Virtual Path/Virtual Channel (VP/VC) egress shaping comprises a buffer for each VP/VC and a scheduling function
that takes an ATM cell out of the buffer and puts it on the physical line at the defined time intervals (T). T is the
reciprocal of the peak cell rate of the VP/VC. If more than one cell arrives for a VP/VC per T interval, the actual
VP/VC peak cell rate is higher than contracted and the exceeding cell(s) are queued into the buffer. The size of
the buffer relates to the maximum burst length of the VP/VC traffic and therefore to the cell transfer delay caused
by the fact that some of the cells are waiting in the queue. The RNC provides a buffer that can handle up to 12,000
cells. The NB 440/NB-880 family provides a buffer that can handle up to 4,000 cells and 12,000 cells with core
controller version 3 (CC3). It is possible for the shaped rate to exceed the configured cell rate by % due to rounding
effects.
T
Traffic buffered
by the shaper
Bandwidth
PCR
VP


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
179
TED:UTRAN Common Operation and Maintenance of the UTRAN
Id:0900d80580118dda
Table 15 summarizes the traffic-shaping support for VP/VC.
For a detailed description, see also OMN:RN-750 Transport Network Management Basics.
3.13 Call Tracing
Call tracing is the collection of data relating to selected calls and the export of logging data. Call tracing collects
data specified by the operator about events concerning one or more subscribers identified by International Mobile
Subscriber Identity (IMSI). Call tracing is an important feature which enables operators to collect effective infor-
mation for fault detection and network optimization.
An IMSI which identifies a UE can be entered by the operator from the LMT/OMC-R. The LMT/OMC-R passes the
IMSI to the RNC. The RNC performs the measurement and stores the data on the RNC disk according to the oper-
ators instructions. The measurement data is uploaded to the LMT/OMC-R via file transfer services and exported
to an external tool for call trace data processing by LMT/OMC-R. This external tool can decode the data format
(ASN.1) and the operator can display or edit data using the external tool.
Physical
Interface
Shaping
level
RN-750 Node B PF2,
Radio Server
NB-530
Iu/Iur Interface Iub Interface
STM-1 VP 15 VPs per
STM-1 line
4 STM-1 lines/
per TINF, i.e.
up to 60 VPs
per TINF
256 VPs per
STM-1 line
2 STM-1 lines
per TINF, i.e.
up to 512 VPs
per TINF
40 VPs per STM-1
line
(Up to 8 VPs can
be terminated in
Node B)
N/A
VC Up to 18,000
AAL-2 VCs and
12,000 AAL-5
VCs per TINF
N/A up to 9 AAL-2 VCs
(one for node
synchronization),
up to 4 AAL-5 VCs
per VP,
up to 4 AAL-1 VCs
(CES)
N/A
E1/J1/T1
(includ-
ing IMA)
VP N/A 16 VPs per
interface card
(via MDTI
card per
eRNC)
16 VPs per
8 E1/J1/T1 lines
(IMA group)
N/A
VC N/A N/A up to 9 AAL-2 VCs
(one for node
synchronization),
up to 4 AAL-5 VCs
per VP,
up to 4 AAL-1 VCs
(CES)
N/A
Table 15 Maximum number of VPs/VCs supported


180 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dda
Operation and Maintenance of the UTRAN
3.14 Remote Antenna Downtilt
Remote adjustment of antennas via OAM speeds up optimization time and effort and can be done at the same
time for all involved antennas. The feature is based on a command interface provided by the OMC/LMT-Node B
where the service personal is able to maintain the antenna downtilt of each sector. The CC obtains the controlling
access to the RET module via the DUAMCO where the CAN bus interface is terminated into a modulated signal
with a carrier frequency in the MHz range.
The CC provides a set of commands (see CML:Node B) to maintain the antenna downtilt from the OMC/LMT via
the CC.
SET_TILT:
The off-axis angle can be defined by a SET_TILT command where the operator specifies the angle in 0.1
degrees at a given range.
The attribute will be stored persistently at the RET.
GET_TILT:
By means of this command the operator is able to request the actual antenna downtilt in 0.1 degree.
GET_INFO:
With the help of this command the hardware and software information of the RET is read including the Prod.-
Nr., Ser.-Nr., HW-Version and SW-Version.
CALIBRATE:
After the installation the RET module needs a calibration in order to work with a given antenna type. At cali-
bration the whole tilt range is driven through by the stepper motor that might lead to call lost.
In case the synchronization fails an alarm is emitted in order to notify the operator about the failure (see
OML:Node B).


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
181
TED:UTRAN Common Operation and Maintenance of the UTRAN
Id:0900d80580118dda
3.15 Remote Inventory
Every network entity (i.e. Node Bs, RNCs) is responsible for collection, update and provision of the inventory data
(ID) of all boards installed in it.
Exact inventory data is necessary for the following reasons:
planning of quantity extensions
planning of system upgrades
analysis of the hardware/firmware inventory in the case of system faults
determining compatible replacement modules
reference for quality evaluations and statistics
The remote inventory feature provides a fully automated process for collecting inventory data and managing all
inventory data. The inventory data of the entire UTRAN area is quickly available.
All inventory data is collected in an Inventory Data Table (IDT) and stored in the NE. Therefore, an easy upload
to the LMT and file transfer to the RC is possible, see Figure 108.
Figure 108 Overview of the feature remote inventory
The IDT contains the inventory data of all remote inventory units (RIU) installed in the network entity (on-board
memory RIUs and non on-board memory RIUs). It is generated at the network entity by combining
network entity data
inventory data read from the info-element of the ob-RIUs
the NOB file of the network entity
The operator of either the LMT or the OMC can request the activation of Remote Inventory scanning. Only one
scanning procedure is allowed to be activated at a time. When the upload is finished, the LMT/RC adds a header
and footer record to the IDT to generate the Inventory Data File (IDF) of the network entity. These header and
footer records give additional information such as creation date, creation time and number of records in the file.
For a detailed description see OMN:RN-750 Software Management Basics.
LMT NE RC
Download NOB
Upload NOB
Load IDF Export IDF
NOB
file
IE IE
IE IE
IDT
RI scanning
Upload IDT
Export IDF
IDF-Editor
Editing
of NOB
Upload IDT
Generate IDT
Generate IDT


182 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dda
Operation and Maintenance of the UTRAN
3.16 License Management
Following the principles of pay-as-you-grow and design-to-cost, license management provides the rights-to-
use for both SW and highly integrated HW. Thus, project-specific packaging of features can be offered to the cus-
tomer.
Different types of licensing have to be distinguished:
Licenses for RNC Optional SW Features (OSFs):
1 license per 1 optional feature
Implemented as 1 password per OSF for a complete UTRAN network
Activation of OSFs via LMT-RNC and Radio Commander
Node B HW Capacity Activation Licensing (CAL):
1 license per 1 capacity unit, that means per 48 CE and per 1 cell
Implemented as 1 key per RC area for ChC capacity
and 1 key per RC area for a number of cells
Storage of activated license on ChC96, ngCAT, and DRIC board
HSDPA throughput licensing:
1 license = peak data throughput of 2.4Mbps per cell (granularity)
N = number of licenses per Node B (value range 0-60)
Licensed (maximum) HSDPA peak data throughput per Node B = N * 2.4Mbps
managed by CC (to be equally distributed over the Node B cells)
Maximum HSDPA peak data throughput per cell = 6 * 2.4Mbps = 14.4Mbps
(maximum N = 6 licenses per cell)
Activation of HSDPA throughput licenses up to the maximum via RC/LMT
Licenses for RNC Optional SW Features (OSFs)
Generally the complete software package is delivered to a customer. One single package including all optional
features is created in the factory to minimize administration overhead. However, an entity consists of the following
main parts:
The basic part:
Basic functionality for a specific release, common to all customers, is provided.
The optional part:
Depending on their needs customers are able to buy one or more optional features that can be activated via
a feature-activation procedure.
Optional features are protected from being used without the activation procedure by means of encryption tech-
niques. Currently, they are activated by service personnel during commissioning of the RNC. In a future release
customers will also be able to handle optional features by means of an RNC license management application on
the LMT-RNC or the Radio Commander.
Please see OMN:RN-750 Software Management Basics for more information.
Node B HW Capacity Activation Licensing (CAL)
Design-to-cost measures result in highly integrated hardware with more capacity and performance. Node B equip-
ment (platform 2 only) can be contracted by the customer without activating all its HW capabilities such as number
of channels or number of cells. Later the customer can activate some or all of these HW capabilities by purchasing
licenses from NEC/SAG. CAL provides an easy-to-handle process for the customer to increase capacity and per-
formance without further HW installation and service effort.
A central function (Radio Commander) administrates the HW capacity licenses (CAPLs). The additional license
vouchers are provided per RC area and can be downloaded to the relevant Node Bs. The vouchers can be used
for any Node B and can be purchased in bundles without specifying the Node B at ordering date. That means,
purchased licenses can be imported into the RC which then allows the operator to activate a certain number of
licenses on selected Node Bs without knowing the existing installation exactly. For this purpose the RC can display


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
183
TED:UTRAN Common Operation and Maintenance of the UTRAN
Id:0900d80580118dda
information on how many licenses can be activated on a specific Node B. Imported license files are checked to fit
the RCs host ID ensuring that used licenses cannot be imported or used a second time.
The licensing application also provides enhanced functionality for performing bulk license upgrade. The capacity
license upgrade procedure for several Node Bs can be customized using an XML configuration file. In addition,
the Licensing Application picks the required license vouchers automatically, if more than one are needed, and
performs the upgrade for all selected Node Bs and boards sequentially as a batch job.
The license information is stored locally on the relevant module where the licensed capacity is valid. That means
the license information is not centrally stored in a specific Node B CC, which makes it possible to transfer this
module to any other Node B. Figure 109 provides an overview of the Node B HW CAL concept.
Figure 109 Overview of the Node B HW CAL concept
Table 16 summarizes the use cases for HW licensing:
Please see FD012258 Activation of Hardware Functionality in NodeB for more information
SAG/NEC Customer
License ordering X
License generation and delivery X
Lincensing application start up X
License import at licensing application host X
Display of available licenses within licensing application X
Display of licensed capacity and maximum capacity at
Node B
X
License activation at Node B X
Display summary of licensed capacity and maximum
capacity for a selected number of Node Bs
X X
Bulk license upgrade X
Table 16 Use cases for Node B HW licensing
RC administrates
licenses and downloads
them to specific
Node Bs. Used keys are
deleted from the list.
Electronic media
(CD-ROM, e-mail)
Node B stores the max.
activated capacity on
the relevant module.
License can be moved
to other Node Bs
License Bundle for
a specific RC area
Node B
Download
D
R
I
C
C
h
C
9
6
C
h
C
9
6
C
h
C
9
6
Radio
Commander
X


184 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dda
Operation and Maintenance of the UTRAN
HSDPA throughput licensing
HSDPA throughput licensing is purchased on a Node B base and is distributed equally to HSDPA capable cells.
Together with the licensing the codes allocated for HSDPA usage per cell and the modulation scheme for this
Node B are fixed. HSDPA activation per Node B is managed by CC in multiples of 2.4 MBit/sec peak throughput.
There are two scenarios for HSDPA provision:
A customer buys Node Bs with a certain number of HSDPA licenses:
The HW is already configured with the allowed HSDPA throughput before delivered from factory to customer
sites with the HSDPA licenses already activated.
A customer wants to expand the HSDPA licenses on a Node B:
An additional licenses file is delivered on CD to the customer, who can activate the licences via the Licensing
Application from the RC.
The detailed procedure to activate additional licenses from RC is similar to the procedure for CHC, ngCAT, and
DRIC licenses activation.
Please see FD012249 Support of HSDPA for more information.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
185
TED:UTRAN Common UTRA Network Element Configurations
Id:0900d80580118de0
4 UTRA Network Element Configurations
Siemens/NEC UTRAN products provide a family of macro FDD Node Bs for area coverage as well as hotspot cells
and a corresponding RNC. The two different implementation platforms, platform 1 and platform 2, are provided for
Node Bs. Shelf and module design on these two platforms differ and therefore modules can only be exchanged
between Node Bs on the same platform.
See the following technical descriptions of these network elements:
Node B platform 1
TED:UTRAN NB-530
Node B platform 2
TED:UTRAN NB-341
TED:UTRAN NB-440/NB-441
TED:UTRAN NB-420
TED:UTRAN NB-880/NB-881/NB-881HR
TED:UTRAN NB-860/NB-861
TED:UTRAN RS-880/RRHs
TED:UTRAN RS-381/RRHs
TED:UTRAN RSSU-380/RRHs
TED:UTRAN RSCU-380/RRHs
RNC
TED:UTRAN RN-750


186 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118de0
UTRA Network Element Configurations
4.1 Iu, Iub, and Iur Interface Connections
Figure 110 shows the STM-1/OC-3 interface adaptation on Iu, Iub, and Iur interfaces of a UTRAN network. For
details please see Iu Connection Configuration, Iub Interface Configurations, and Iur Connection Configura-
tion.
Figure 110 Iu, Iur, and Iub across a possible ATM network
Possible ATM network
Possible ATM network
Legend:
MSC
Iu and its ATM layer terminations (black)
Iur and its ATM layer terminations (blue)
Iub and its ATM layer terminations (yellow)
Iur(1)
Iur(3)
Iur(2)
RNC RNC
Node B
2
Node B
1
Node B
3
Node B
4
Lines can be
identical
physically
Lines can be
identical
physically


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
187
TED:UTRAN Common UTRA Network Element Configurations
Id:0900d80580118de0
4.2 Iub Interface Configurations
The RNC and the connected Node Bs can be arranged in a star, cascade, hub or loop configuration. Node Bs can
link up to the RNC and to each other via several E1/J1/T1 lines or via STM-1/OC-3 lines. If the RNC is connected
to an external ATM switch via an STM-1/OC-3 line, overbooking is possible on the STM-1/OC-3 line between the
RNC and the external ATM equipment. This section provides an overview of these configurations.
Star configuration
Figure 111 shows a star configuration of three Node Bs connected to the same RNC. Node Bs link up to the RNC
via several E1/J1/T1 lines or via a partly filled STM-1/OC-3 line. The E1/J1/T1 lines can be used with Inverse Mul-
tiplexing for ATM (IMA).
Figure 111 Node B star configuration
Hub configuration
Figure 112 shows the hub configuration of three Node Bs that are connected to the same RNC via a Node B hub,
which collects the traffic of other Node Bs and transmits the overall traffic towards the RNC. The Node B hub
(Node B #1) links up to the other Node Bs (Node B #2, #3, #4) via several E1/J1/T1 lines and links up to the RNC
either via an STM-1/OC-3 line or via several E1/J1/T1 lines. It must provide an ATM cross-connect function for
mapping data between the RNC and the other Node Bs. The E1/J1/T1 lines can be used with IMA.
If an STM-1/OC-3 interface is used, the ATM cells are transported in VC-4 virtual containers. Links via STM-1/OC-
3 lines are implemented by point-to-point SDH/SONET connections.
Figure 112 Node B hub configuration
Node B
#1
RNC
Node B
#2
Node B
#3
STM-1/OC-3 or E1/J1/T1
(with/without IMA)
STM-1/OC-3 or E1/J1/T1
(with/without IMA)
STM-1/OC-3 or E1/J1/T1
(with/without IMA)
Node B
Function
ATM
VP Switching
Node B
RNC
Function
ATM
VP Switching
RNC
Node B
#2
Node B
#3
Node B
#4
VPs
(Node B 1,
Node B 2,
Node B 3,
Node B 4)
#1
E1/J1/T1
E1/J1/T1
E1/J1/T1
STM-1/OC-3 (ATM)
or n x E1/J1/T1
(with/without IMA)


188 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118de0
UTRA Network Element Configurations
Cascade configuration
Figure 113 shows the cascade configuration of three Node Bs connected to the same RNC. Each Node B in the
chain acts as a Node B hub optimizing the overall transmission band towards the next Node B. Node Bs link up
to the RNC and to each other via STM-1/OC-3 lines or via several E1/J1/T1 lines. This configuration requires an
ATM VP switching functionality. E1/J1/T1 lines could be used with IMA. Node Bs provide the required ATM VP
switching function. If required for a specific cascade configuration, the internal capacity of a Node B can be com-
plemented by an external implementation with an OEM product.
g If an STM-1 interface is used, the ATM cells are transported in VC-4 virtual containers. Links via STM-1 lines
are implemented by point-to-point SDH connections. Links via OC-3 lines are implemented by point-to-point
SONET connections.
Figure 113 Node B cascade configuration
Node B
Function
ATM
VP Switching
Node B #1
Node B
Function
ATM
VP Switching
Node B #3
VPs
(
Node B 2,
Node B 3)
Node B
Function
ATM
VP Switching
Node B #2
RNC
Function
ATM
VP Switching
RNC
Node B 1,
STM-1/OC-3 or E1/J1/T1
(with/without IMA)


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
189
TED:UTRAN Common UTRA Network Element Configurations
Id:0900d80580118de0
Loop configuration
Node Bs can link up to the RNC and to each other via several E1/J1/T1 lines or via STM-1/OC-3 lines. Loop topol-
ogies increase the availability of the network by providing two or more paths between network nodes. If one path
fails, the traffic can be seamlessly taken over by a redundant path.
Loop configuration with IMA
The RNC and all Node Bs (except NB-530) support E1/J1/T1 link-based loop topologies using IMA between
the RNC and a Node B or Node B cascade
a hub Node B and a Node B or Node B cascade
There are 2 different types of IMA configuration:
IMA aggregation mode:
in this mode all configured IMA links must be active
IMA protection mode:
the protection can be changed from an n to an n+x redundancy with an overall number of E1 links config-
ured in a IMAGroup of n+x
this mode allows that the group is active even not all configured links in a group are active
With IMA, up to 4 E1 lines with a bandwidth of 2 Mbps each can be combined to form an IMA group with a
bandwidth of nn+x * 2 Mbps. All 2 Mbps lines that are used to connect the Node Bs to the RNC can be arranged
in a closed loop. IMA groups combine two or more lines between the RNC and each Node B concentrator. If
an E1 link breaks down and the loop becomes open, the self-recovery mechanism of IMA ensures that the
Node Bs stay connected to the RNC. All the E1 links that connect a particular Node B to the RNC or hub should
use different paths through the transmission network. The ATM traffic at each ring site is limited to 8 Mbps.
For details see also OMN: RNC Transport Network Management Basics.
Loop configuration with SDH ADM
A loop configuration can also be implemented via external SDH equipment which handles the protection-
switching, see Figure 114 and Figure 115. An SDH Add-Drop Multiplexer (ADM) is required at each Node B
and at the RNC. Node Bs and the RNC are connected to the SDH ADMs via several E1/J1/T1 lines or via
STM-1 point-to-point links.
If E1/J1/T1 links and SDH/SONET equipment are used, the user traffic is transported in VC-12 virtual contain-
ers within the SDH/SONET loop. The traffic of a Node B requires up to 16 VC-12 containers in the
SDH/SONET ring to the RNC.
If STM-1/OC-3 interfaces and SDH/SONET equipment are used, the user traffic is transported in VC-4 con-
tainers. A VC-4 container is sent from the RNC to the first Node B. Within the first Node B, the user traffic from
the VC-4 container is split into the traffic to this Node B and the traffic to subsequent Node Bs. The first Node B
sends the user traffic destined for subsequent Node Bs to its second STM-1/OC-3 link and generates a new
VC-4 container. The VC-4 container with the remaining traffic is sent to the next Node B.


190 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118de0
UTRA Network Element Configurations
Figure 114 Node B loop configuration with E1/J1/T1 interfaces
Figure 115 Node B loop configuration with STM-1/OC-3 interfaces
(ext.) SDH
ADM
(ext.) SDH
ADM
(ext.) SDH
ADM
VC12s
(Node B 1,
Node B 2,
Node B 3)
SDH
(STM-1/4,
ATM)
SDH (STM-1/4, ATM)
SDH ring protection:
Redundant VC-12
(Node B1, Node B 2,
Node B 3)
(ext.) SDH
ADM
Node B
Function
ATM
VP Switching
Node B #1
Node B
Function
ATM
VP Switching
Node B #3
Node B
Function
ATM
VP Switching
Node B #2
RNC
Function
ATM
VP Switching
RNC
E1/J1/T1 E1/J1/T1 E1/J1/T1
VC-4
RNC to
SDH ring protection:
Redundant VC-4
SDH (STM-1/4, ATM)
SDH (STM-1/4,
ATM)
Node B 1
(ext.) SDH
ADM
(ext.) SDH
ADM
(ext.) SDH
ADM
(ext.) SDH
ADM
Node B
Function
ATM
VP Switching
Node B #1
Node B
Function
ATM
VP Switching
Node B #3
Node B
Function
ATM
VP Switching
Node B #2
RNC
Function
ATM
VP Switching
RNC
2 x STM-1
/OC-3
2 x STM-1
/OC-3
2 x STM-1
/OC-3


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
191
TED:UTRAN Common UTRA Network Element Configurations
Id:0900d80580118de0
External ATM configuration with overbooking
Overbooking on Iub improves the efficiency of the STM-1/OC-3 lines giving mobile network operators high link uti-
lization and saving both bandwidth and transmission costs simultaneously. An example for Iub configuration with
overbooking is given in Figure 116. Overbooking on Iub enables operators to set up ATM Virtual Paths (VPs), even
when the total bandwidth required for all of the VPs exceeds the STM-1/OC-3 link capability for a short period of
time. When an overbooking factor is specified, the RNCs bandwidth management calculates the total logical
bandwidth by multiplying the link capability of an STM-1/OC-3 line with the overbooking factor. More specifically,
by setting the overbooking factor parameter, the operator can tune the balance of the network between assured
transmission under high load circumstances (factor 100%) and very efficient STM-1/OC-3 usage (factor 200%)
when applicable.
g For details and a description of the command that changes the overbooking factor on the Iub see OMN: RNC
Transport Network Management Basics and FD012225a Overbooking on Iub.
Figure 116 Example for Iub configuration with overbooking
External ATM configuration with IMA dynamic bandwidth adaptation
IMA dynamic bandwidth adaptation avoids that an IMA group fails in case one or more link is interrupted or
disabled as long as the remaining number of links is sufficient to transfer all CBR/real time traffic. The bandwidth
available for the Best Effort traffic is dynamically adapted to the remaining resources used by the ATM connections
on the IMA group to the Node B (see Figure 117). Operators can increase the availability of a guaranteed CBR
bandwidth for R'99 traffic without additional spare links. The remaining capacity can be used for HSDPA traffic at
a reduced QoS level.
Node B
RNC
Iub
ATM
ATM
external
ATM switch
ATM
Node B
Node B
Node B
Node B
Node B
Node B
Node B
Node B Node B
STM-1/OC-3
E1/J1, IMA
E1/J1, IMA
E1/J1, IMA
E1/J1, IMA
E1/J1, IMA
E1/J1, IMA E1/J1, IMA
E1/J1, IMA
E1/J1, IMA
E1/J1, IMA, STM-1/OC-3
Overbooking is possible on
this STM-1/OC-3 line
(between RNC and external
ATM switch


192 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118de0
UTRA Network Element Configurations
Figure 117 External ATM configuration with IMA dynamic bandwidth adaptation
g IMA dynamic bandwidth adaptation is only applicable for configurations with an external ATM switch. E1 links
that directly connect the Node B to the RNC are not supported. CBR traffic bandwidth is guaranteed and there-
fore can not be dynamically adapted to the available number of E1 lines.
Figure 118 Example of IMA dynamic bandwidth adaptation
If the number of available links falls below imaGroupMinNumLinks the IMA group is shut down. Figure 118
provides an example of IMA dynamic bandwidth adaptation for a given set of parameters.
For details and a description of the parameters see FD012297 IMA Dynamic Bandwidth Adaptation.
RNC
Iub
ATM
ATM
external
ATM switch
ATM
Node B Node B
E1/J1/T1, IMA, STM-1/OC-3
STM-1/OC-3
actual available links = n
imaGroupMinNumLinks = m
E1/J1/T1, IMA
Data Rate
n*E1
m*E1
imaGroupAdd
NumLinks
on
off
UBR only
CBR/UBR
3
2
1
0
N
u
m
b
e
r

o
f

a
c
t
i
v
e

E
1

l
i
n
k
s
Traffic on UBR VP
Traffic on CBR VP
Bandwidth available
on IMA group
first E1 link in
IMA group fails
second E1 link in
IMA group fails
Example for Parameters set:
imaGroupMinNumLinks =1
imaGroupAddNumLinks = 2


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
193
TED:UTRAN Common UTRA Network Element Configurations
Id:0900d80580118de0
4.3 Iur Connection Configuration
The Iur is mainly used for the RNC-RNC handover sequence. Protocol messages and user plane data are trans-
mitted on an ATM link over the Iur, where the MSC does not cover call processing related topics between RNCs.
As shown in Figure 110 there are three different types of Iur network configuration:
Iur (1): physically direct connection between two RNCs (see Figure 119)
Iur (2): physically indirect connection between two RNCs via MSC
via MSC with ATM VC switching (see Figure 120)
via MSC with point code routing on MTP-3b/B-MTP layer of SS7 (see Figure 121)
Iur (3): physically indirect connection between two physical RNCs via MSC,
but ALCAP and RNSAP are terminated once and are also controlled by MSC
Direct physical connection between two RNCs
There are physically meshed connections among the RNCs within the network. Depending on the number of
adjacent RNCs, this configuration may be very elaborate and expensive.
Figure 119 Iur direct connection configuration
Indirect physical connection between two RNCs via MSC (ATM VC switching)
The RNCs within the network are connected via MSC. This configuration is used to save on physically meshed
connections. The number of physical connections to other RNCs is reduced to one per RNC by using the Iu inter-
faces. The MSC provides ATM switching capability only (see Figure 120) with the number of logical Iur ATM con-
nections (VP/VC) being equal to the number of physical direct connections if the RNCs were directly connected.
MSC
Legend:
RNC RNC
Node B
#2
Node B
#1
Node B
#3
Node B
#4
Iub Iub
Iu Iu
STM-1/OC-3 line as Iur
STM-1/OC-3 line (blue)
Iur VP path(s) on ATM interfaces (red)


194 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118de0
UTRA Network Element Configurations
Figure 120 Iur indirect connection configuration (ATM VC switching)
Indirect physical connection between two RNCs via MSC (ATM link termination)
This configuration uses a separate ATM link and requires MSC to terminate the signaling flow at the incoming
interface of the MSC (see Figure 121). Signaling is then generated and sent once again at the outgoing interface
to the destination RNC. ALCAP is terminated in the MSC which retrieves the DNSEA (Destination NSAP Service
Endpoint Address) and sends the ALCAP message to the target Node specified by the DNSEA. RNSAP is not
terminated, it is routed on MTP-3b/B-MTP layer of SS7 by DPC (Destination Point Code).
Figure 121 Iur indirect connection configuration (ATM link termination)
MSC
Legend:
Node B
#2
Node B
#1
Node B
#3
Node B
#4
Iub
Iu
Iu
Iur ATM path Iur ATM path ATM VP/VC
switching
RNC RNC
Iub
STM-1/OC-3 line (blue)
Iur VP path(s) on STM-1/OC-3 interfaces (red)
MSC
Legend:
Node B
#2
Node B
#1
Node B
#3
Node B
#4
Iub
Iu
Iu
Iur ATM path Iur ATM path ATM link
termination
RNC RNC
Iub
STM-1/OC-3 line (blue)
Iur VP path(s) on STM-1/OC-3 interfaces (red)


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
195
TED:UTRAN Common UTRA Network Element Configurations
Id:0900d80580118de0
4.4 Iu Connection Configuration
The Iu interface connects UTRAN to the CN and handles switching, routing and service control. For transmitting
protocol messages and user plane data three instances with different transport technologies are used:
Iu-CS for the connection to the circuit-switched (CS) CN
Iu-PS for the connection to the packet-switched (PS) CN
Iu-BC for the connection to a CBC in the CN
Different types of core net architecture are supported to provide CS, PS and SMS CB services:
Uniform core net architecture (see Figure 122)
Split core net architecture (see Figure 123)
SMS CBC architecture (see Figure 124)
Uniform core net architecture
The RNC supports common access via one and the same termination point for both ALCAP and RANAP mes-
sages, i.e. RANAP and ALCAP protocols on the Iu-CS are addressed by the same Destination Point Code (DPC).
Figure 122 Iu connection configuration for a uniform core net architecture
Split core net architecture
The UTRAN can be connected to a split CN configuration consisting of a separate Media Gateway (MGW) and an
MSC. All connections from the RNC into the core net are physically connected to the MGW. There are individual
signaling links for ALCAP and RANAP which are both carried in the VP running between RNC and the MGW, i.e.
RANAP and ALCAP protocols on the Iu-CS are addressed by separate DPCs. The MGW terminates the ALCAP
link, whereas the signaling links carrying RANAP are cross-connected in the MGW and are terminated in the MSC
or SGSN respectively.
Link
Group
2
Link
Group
1
Legend:
MSC SGSN
RNC
Link Group 1 RANAP Iu-CS, Q.AAL2 (ALCAP)
Link Group 2 RANAP Iu-PS


196 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118de0
UTRA Network Element Configurations
Figure 123 Iu connection configuration for a split core net architecture
SMS CBC architecture
To provide CBS functionality CBC, RNC, UE, Node B and SGSN interwork.
CBC is responsible for:
Allocation of serial numbers
Initiating/modifying/deleting CBS messages held by RNC
Determination of the SAI list for each message
Determination of repetition period and number of broadcast for each message
Determination of start and stop of broadcasting CB messages
RNC is responsible for:
Reception and interpretation of CBC requests
Storing the CBS Message
Routing the CBS messages to cells
Scheduling and repetition of the CBS messages on the air interface
Indication that the request received from CBC will be served
Informing CBC in case of failure/recovery of allocated CBS resources in RNC
Broadcasting of cell broadcast messages
RNC does not interpret the contents of CBS messages and Data Coding Scheme parameters. Scheduling is done
according Repetition Period Information, which are received together with CBS Messages from CBC.
UE is responsible for:
Listening to CBS related System Information Messages
Allocation of required CBS Resources
Capturing and displaying the CBS Messages
Node B does not have a specific task except to provide the physical layer.
SGSN is responsible for routing only.
Legend:
RANAP Iu-PS
MGW
ATM cross-connection
Link Group 10 RANAP Iu-CS
Q.AAL2 (ALCAP)
Link
Group
Link
Group
11 20
Link Group 11
Link Group 20
MSC SGSN
RNC
Link
Group
10


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
197
TED:UTRAN Common UTRA Network Element Configurations
Id:0900d80580118de0
Figure 124 Iu connection configuration for SMS CBC architecture
For a detailed description of the feature see FD012219A SMS Cell Broadcast.
Node B
#1
Node B
#2
Iu Iu-BC
Iub
ATM
Ethernet
Legend:
RNC directIy connected to the CBC
RNC indirectIy connected to the CBC via SGSN
6&
6&
6& 6&
6&
6&
ATM/
Ethernet
Converter
GGSN
SGSN
CBC
RNC


198 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118de0
UTRA Network Element Configurations
4.5 UMTS/GSM Co-Location Configuration
Many of today's GSM mobile network operators owning UMTS licenses require the re-use of existing 2nd gener-
ation sites to a maximum possible extent. This leads to co-location of GSM base stations and UMTS Node Bs.
Transmission Re-use
Transmission re-use for UMTS GSM Co-location is realized by two ways which are mutually exclusive (see
Figure 125):
Circuit Emulation Service (CES)
Circuit Emulation over ATM networks (UMTS) provides emulation of Abis transport layer and is performed on
ATM links (STM-1/OC-3, IMA on nxE1/T1).
For a detailed description see FD012221A Circuit Emulation Service and .
Fractional ATM (FRAC)
Fractional ATM over circuit switched networks (GSM) provides transport of Iub time slots and is performed on
TDM links (E1/T1).
For a detailed description see OMN:RN-750 Transport Network Configuration Basics.
Figure 125 Transmission re-use for UMTS GSM co-location
CN
BTS
Node B
#1
Iub
RNC
ATM
Switch
BSC
CN
BTS
Node B
#1
Abis
RNC
BSC
Legend: Transmission path
Circuit Emulation Service (CES) Fractional ATM (FRAC)


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
199
TED:UTRAN Common UTRA Network Element Configurations
Id:0900d80580118de0
Concatenation of time slots
Co-location can only be fulfilled if the time slot assignment for the GSM traffic (on the Abis interface) remain
unchanged when UMTS traffic is added. This means, UMTS traffic is only allowed to use those time slots of an
E1/J1/T1 line or port that are not assigned to GSM traffic. Reassignment is not allowed. Figure 126 illustrates the
requirements for time slot assignment for FRAC and CES in more detail.
Figure 126 Concatenation of time slots for UMTS GSM co-location
BTS
Node B
Iub
ATM Switch
Abis
RNC
BSC
RNC
A
T
M
A
T
M
A
T
M
C
E
S
T
D
M
T
D
M
T
D
M
T
D
M
TDM TDM
TDM
Abis
Iub
CBR PVC(s)
BTS
Node B
F
R
A
C
TS0 TS31
e.g. E1 with n=5
CES
TDM
BSC
T
D
M
TS0 TS31
e.g. E1
TS0 TS31
e.g. E1
A
T
M
TDM
FRAC
T
D
M
TDM
. . .
. . .
. . .
ATM based co-location
TDM based co-location
STM-1
/OC-3 E1/J1/T1
STM-1
/OC-3
E1/J1/T1
E1/J1/T1
E1/J1/T1
E1/J1


200 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118de0
UTRA Network Element Configurations
Equipment Upgrade
UMTS GSM Co-location can also be realized by adding UMTS equipment to existing GSM equipment. Such a
zero footprint upgrade scenario is represented by an Abis/Iub Configuration of BTS/RSCU. Figure 127 illustrated
the following Iub transport features:
CES
The RSCU carries the TDM traffic to another BTS and/or Node B over an ATM
network together with its own traffic via a common STM-1(o) line to an ATM switch which separates the GSM
and UMTS traffic to the BSC and RNC (and vice versa).
The BTS uses up to 8 E1/J1/T1 lines which are connected to Abis_0 and Abis_1.
IMA
The RSCU is interconnected to the RNC using up to 4 E1/J1/T1 lines which are
connected to an external OVPT.
The BTS uses up to 8 E1/J1/T1 lines which are connected to Abis_0 and Abis_1.
Figure 127 IMA/CES Application for Abis/Iub Configuration of BTS/RSCU
IMA Application
BTS
RSCU
ATM Switch
RNC
A
T
M
A
T
M
A
T
M
T
D
M
TDM
CES
TDM
BSC
T
D
M
A
T
M
STM-1
/OC-3
STM-1
/OC-3
E1/J1/T1
CES Application
BTS
Node B
external
OVPT
C
E
S
TDM
Abis_0, Abis_1
RNC
A
T
M
BSC
E1/J1/T1
BTS
RSCU
E1/J1/T1
external
OVPT
Abis_0, Abis_1
A
T
M
E1/J1/T1


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
201
TED:UTRAN Common UTRA Network Element Configurations
Id:0900d80580118de0
4.6 Transcoder Free Operation in CN
Transcoder Free Operation (TrFO), as specified in 3GPP Rel. 4, TR 25.953, enables the support mode operation
of the Iu UP not only on the Iu interface but also for end-to-end connections:
between two RNCs, in case of a mobile-to-mobile call
between an RNC and a gateway CN node in case of a mobile to fixed call
TrFO improves the voice quality and reduces the employment of transcoder equipment in the CN. This is due to
the fact that when transcoders are used, modulation of speech from AMR to PCM at the originating CN and then
from PCM to AMR at the terminating CN will lead to a loss of information and thus degradation of the voice quality.
In order to establish Transcoder Free Operation, Out-of-Band Transcoder Control (OoBTC) is required. OoBTC
(as specified in 3GPP Rel. 4, TR 25.153) refers to the capacapability to negotiate the preferred codec type to be
used between two end nodes and to avoid the use of transcoders in the network at call set-up. The originating UE
indicates the list of its supported codec types for codec negotiation. This list is conveyed to the terminating MSC.
The terminating UE indicates its list of supported codec types to the terminating MSC. The terminating MSC
conveys the selected codec to the originating MSC, which then indicates the selected codec to the originating UE.
TrFO is based on the use of the Iu UP protocol as a framing protocol within the CS AAL2/ATM in particular Iu UP
protocol v.2. Figure 128 provides an overview on the basic architecture for UMTS to UMTS TrFO connection.
Figure 128 Basic Architecture for UMTS to UMTS TrFO Connection
MGW
MSC
RNC
ControI
Server
MGW RNC
PIane
User
PIane
OoB Codec
Negotiation
OoB Codec
Negotiation
OoB Codec
Negotiation
RANAP RANAP
MGW
Control
MGW
Control
End to end connection
Radio Bearer Radio Bearer u Bearer u Bearer CN Bearer
MSC
Server
Bearer Req
Bearer Req Bearer Req
6& 6&


202 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118de0
UTRA Network Element Configurations
4.7 ATM/Multiservice Switch Configurations
To build up and optimize UTRAN ATM networks high-speed ATM/multiservice switches (e.g. SURPASS hiD3100
family) can be used. They provide connectivity for Iub, Iur, and Iu to optimize the usage of transport capacities
(see Figure 129).
Figure 129 Mobile transport network optimization using ATM/multiservice switches
The following scenarios can be realized:
Support of Iu, Iur Interfaces
Support of Iub Interfaces
Node B Hubbing
RNC Optimization
Sharing of Transport Resources with TDM Applications
4.7.1 Support of Iu, Iur Interfaces
ATM/multiservice switches can be used to realize the transport layer for Iu and Iur interfaces serving as an adapter
of interface lines from RNCs (STM-1/OC-3) to a generic ATM or SDH network, and/or to an MSC. Thus, ATM/mul-
tiservice switches support flexible Iu/Iur connections as illustrated in Figure 130.
Figure 130 Support of flexible Iu/Iur connections using ATM/multiservice switches
UTRAN
ATM/SDH
BSC
RNC
ATM/
Multiservice
Switch
ATM/
Multiservice
Switch
BTS
Node B
Node B
Hub
Node B/BTS
Hub
RNC
Hub
n x IMA E1
n

x

E
1

C
E
S

(
T
D
M
)
STM-1
STM-4
n x E1
CES
(TDM)
UTRAN
IP/MPLS/Ethernet
ATM/
Multiservice
Switch
Node B
Node B
SDH
(or ATM)
Network
SDH
(or ATM)
Network
ATM/
Multiservice
Switch
RNC
MSC
Iu, Iur
STM-1
Iu
ATM/
Multiservice
Switch
RNC
Iu, Iur
STM-1


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
203
TED:UTRAN Common UTRA Network Element Configurations
Id:0900d80580118de0
4.7.2 Support of Iub Interfaces
ATM/multiservice switches allow for the use of a packet switched network (PSN) at the Iub interface without mod-
ifying already installed network elements. Typical network scenarios are:
All Iub traffic over Ethernet (see Figure 131)
Mixed Traffic over both ATM and Ethernet (see Figure 132)
Node B Co-located with GSM (see Figure 133)
All Iub traffic over Ethernet
ATM/multiservice switch can be used to manage the transport of Iub traffic for different sites as illustrated in Figure
131. All Iub traffic (Site A) is transported over Ethernet to the RNC site. At the Node B site the ATM/multiservice
switch is used as a PWE Access Gateway for ATM to Ethernet conversion and clock recovery/generation for the
Node B. Node Bs (Site B) using classical ATM transport can be managed in parallel. The traffic from IP/Ethernet
backhaul and the ATM backhaul is merged in a ATM/multiservice switch in front of the RNC. This system also
performs the PWE gateway functionality to recover the ATM cells from the Ethernet frames. The IP/Ethernet
backhaul is assumed to be a secure layer 2 switched network. Nevertheless, also routed IP networks are sup-
ported with the IP encapsulation option provided by the ATM/multiservice switch.
Figure 131 All Iub Traffic over Ethernet
SDH (ATM)
Network
RNC
ATM/
Multiservice
Switch
IP/Ethernet
Network
ATM/
Multiservice
Switch
Site B
Site A
IP
FE
ATM
STM-1
ATM
E1
ATM
STM-1
IP
GE
CE
CE
CE: Carrier Ethernet (Network Termination)
FE: Fast Ethernet
GE: Gigabit Ethernet
ATM
E1
Node B
Node B


204 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118de0
UTRA Network Element Configurations
Mixed Traffic over both ATM and Ethernet
Operators that already have an ATM based UTRAN network in operation can maintain both "low quality" connec-
tions (as used to carry the HSDPA traffic from the Node B) and "high quality" ATM/SDH network (to be used for
synchronization). For traffic separation to the ATM or Ethernet path two options are supported (see Figure 132):
Separation is done directly by the Node B via a separate E1/T1 or IMA groups.
This is the preferred solution if a single Node B is the only source of traffic to be connected to the ATM/SDH
network.
Separation is done (after traffic aggregation) by the ATM/multiservice switch via
separate ATM VPs between RNC and each Node B.
This is the preferred solution if more than one Node Bs or other traffic sources are to be connected.
Figure 132 Mixed Traffic over both ATM and Ethernet
SDH (ATM)
Network
RNC
ATM/
Multiservice
Switch
IP/Ethernet
Network
ATM/
Multiservice
Switch
IP
FE
ATM
STM-1
ATM
E1
ATM
STM-1
IP
GE
DSLA
CE
CE: Carrier Ethernet (Network Termination)
FE: Fast Ethernet
GE: Gigabit Ethernet
ATM
E1
ATM
E1
xDSL
Node B


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
205
TED:UTRAN Common UTRA Network Element Configurations
Id:0900d80580118de0
Node B Co-located with GSM
In cases where GSM and UMTS base stations are located at the same site the UMTS and the GSM traffic are
combined onto a common transport network. This will be mostly done via a pure ATM or pure Ethernet transport,
but can also be realized be means of a mixed ATM/Ethernet transport scenario for the UTRAN part as illustrated
in Figure 133. The transport of GSM traffic over a PSN is maintained by GERAN without additional UTRAN
requirements to the network elements.
Figure 133 Node B Co-located with GSM
SDH (ATM)
Network
RNC
ATM/
Multiservice
Switch
IP/Ethernet
Network
ATM/
Multiservice
Switch
Site A
IP
FE
ATM
STM-1
Abis
E1
ATM
STM-1
IP
GE
CE
CE
CE: Carrier Ethernet (Network Termination)
FE: Fast Ethernet
GE: Gigabit Ethernet
ATM
E1
TDM
E1
BSC
ATM
E1
ATM/
Multiservice
Switch
Site B
Abis
E1
ATM
E1
Node B
BTS
Node B
BTS


206 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118de0
UTRA Network Element Configurations
4.7.3 Node B Hubbing
The physical transmission links to Node Bs are often used only partly. ATM/multiservice switches provide the
capability of aggregating those links into fully used links, either E1/T1 or STM-1/OC-3. Statistical multiplexing of
bursty UTRAN traffic additionally increases the transmission efficiency. ATM/multiservice switches extend the
existing aggregation capability of Node Bs for an optimized transport network design by means of Node B hubbing
as illustrated in Figure 134.
Figure 134 Node B hubbing using ATM/multiservice switches
ATM/
Multiservice
Switch
ATM/
Multiservice
Switch
ATM/
Multiservice
Switch
ATM/
Multiservice
Switch
RNC
Node B
Node B
Node B
Node B
Node B
Node B
Node B
Node B
Node B
Node B
Node B
Node B
STM-1
n x E1
IMA
n x E1
IMA
n x E1
IMA
(STM-1)
Meshed
Network
of ATM
Switches


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
207
TED:UTRAN Common UTRA Network Element Configurations
Id:0900d80580118de0
4.7.4 RNC Optimization
When located next to the RNC, ATM/multiservice switches can be used to save RNC ports. This is realized by
consolidating E1 lines into high speed STM-1/OC-3 links before injecting the traffic into the RNC.
When channelized STM-1/OC-3 links are used on the SDH/SONET ring, ATM/multiservice switches also provide
the capability to convert them into concatenated links. As illustrated in Figure 135, the ATM/multiservice switches
serve as an aggregation node and converter for ATM VPs mapped into several VC-12 (potentially in IMA groups)
to VPs mapped into a VC-4 container.
Figure 135 RNC optimization using ATM/multiservice switches
ATM/
Multiservice
Switch
ADM
RNC
Node B
Node B
Node B
Node B
STM-1
concatenated
(VC-4)
n x E1
IMA
n x E1
IMA
n x E1
IMA
ADM
ADM
ADM
SDH
Network
Node B
Node B
Node B
Node B
Node B
Node B
Node B
STM-1
channelized
(VC-12)


208 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118de0
UTRA Network Element Configurations
4.7.5 Sharing of Transport Resources with TDM Applications
In addition to the Node B, ATM/multiservice switches provide the capability of carrying TDM traffic over the ATM
transport network by using circuit emulation functionality (CES). Partly used TDM lines from GSM BTSs can be
aggregated together with the UTRAN traffic as illustrated in Figure 136. Thus, ATM infrastructures deployed for
UTRAN can be used efficiently also for GERAN services.
Figure 136 TDM traffic sharing using ATM/multiservice switches
ATM/
Multiservice
Switch
ATM/
Multiservice
Switch
RNC
Node B
Node B
Node B
Node B
BSC
BTS
BTS
BTS
BTS
STM-1
E1
TDM
n x E1
IMA
(STM-1)
n x E1
TDM
n x E1
TDM


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
209
TED:UTRAN Common Quality Standards / Specifications
Id:0900d80580118ddd
5 Quality Standards / Specifications
The Siemens/NEC UTRAN products fulfil the legal quality standards, but aim to meet the best-in-class quality
standards demanded by the market.
This section defines the quality specifications for the UTRAN FDD equipment.
5.1 Legal Directives
European legal directives
The Node Bs, RNC and OMC comply with the following European directives:
Harmonized European standards under these directives are referenced as legal requirements. The legal require-
ments for complying with the above mentioned directives include:
placing the CE mark on the equipment
issuing a declaration of conformity
CE marking covers EMC- and product safety requirements.
Japanese legal directives
Legal directives applicable to the Japanese market are:
Radio Law
(Law No. 131 of 2 May 1950, As last amended by: Law No.47 of 21 May 1999
Product Liability Act (Act No.85,1994)
US legal directives
Legal directives applicable to US markets are:
Directive Relevant for
1999/5/EC R&TTE Node B
73/23/EEC Low Voltage Directive RNC, OMC
89/336/EEC EMC Directive RNC, OMC
Table 17 Applied european directives
Directives Description
47 CFR 2 Frequency allocations and radio treaty matters; general rules
and regulations
47 CFR 15 Radio Frequency Devices
47 CFR 22 Public Mobile Services
47 CFR 24 Personal Communications Services
FCC Part 15.31 Measurement standards
FCC Part 15.33 Frequency range of radiated measurements
FCC Part 15.35 Measurement detector functions and bandwidths
Table 18 Applicable US legal directives


210 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118ddd
Quality Standards / Specifications
5.2 Industrial Standards
US industrial standards
Industrial standards applicable to US markets are:
5.3 Quality Standards
The UTRAN equipment complies with the standards below.
UL 60950-1 Standard for the safety of information technology equipment,
including electrical business equipment
NEMA 250 Enclosures of electrical equipment (1000V maximum):
outdoor equipment meets Type 3 R requirements
3GPP TS25.104/141 Uu-interface (based on 3GPP Rel.5 for all applicable fre-
quency bands)
Standards Relevant for
Telcordia GR-63 Earthquake Zone 4 Node B
All applicable requirements according NEBS Levels 1,2,3
as specified within Bellcore Special Report SR-3580.
Target specifications are Telcordia GR-63 and GR-1089
RNC
All requirements related to DC-power within SBC-TP-76200.
Table 19 Applicable US industrial standards
UTRAN equipment Standards world market Standards US market
EMC emission requirement
NB-341
NB-420/NB-440/NB-441
NB-860/NB-880/NB-861
NB-881/NB-881 HR
RS-381
RSSU-380/RSCU-380
RS-880
Radiated Emission:
EN 55022 Class B FCC part15.109 Class B
Conducted emission:
EN 55022 Class B FCC part15.107 Class B
Antenna power conduction limits for receivers:
FCC Part 15.111
Field strength of spurious radiation:
FCC Part 2.1053
Frequency spectrum of spurious radiation:
FCC Part 2.1057
Table 20 Quality standards
Directives Description
Table 18 Applicable US legal directives


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
211
TED:UTRAN Common Quality Standards / Specifications
Id:0900d80580118ddd
RN-750 Radiated Emission:
EN 55022 Class B FCC part15.109 Class A
Conducted emission:
EN 55022 Class B FCC part15.107 Class A
EMC immunity standards (EMI)
NB-341
NB-420/NB-440/NB-441
NB-860/NB-880/NB-861
NB-881/NB-881 HR
RS-381
RSSU-380/RSCU-380
RS-880
IEC 61000-6-2
RN-750 EN 3000386
Product safety
NB-341,
NB-420/NB-440/NB-441
NB-860/NB-880/NB-861
NB-881/NB-881 HR
RS-381
RSSU-380/RSCU-380
RS-880
Safety of information technology
technology equip./fire
resistance:
IEC 60950
Radio transmitting equipment:
IEC 60215
UL 60950-1
NB-341
NB-441
NB-861
NB-881/NB-881 HR
Protection of outdoor equipment:
IEC 60529 (outdoor enclosures)
/ IP55
Protection for outdoor
equipment:
NEMA250 Type 3R
RN-750 Safety of information technology
technology equip./fire
resistance:
IEC 60950-1
UL 60950-1
Power supply interface
NB-341
NB-420/NB-440
NB-860/NB-880
RSSU-380/RSCU-380
RS-880
RN-750
ETS 300132-2 (DC) for -48V
equipment
NB-341
NB-441
NB-861
NB-881/NB-881 HR
RS-381
IEC 60038 for standard voltages
UTRAN equipment Standards world market Standards US market
Table 20 Quality standards


212 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118ddd
Quality Standards / Specifications
5.4 Telecommunication Link Interfaces
In this context, telecommunication link interfaces for RAN equipment are the following: IuCS, IuPS, IuBC, Iur, Iub.
Where applicable, the telecommunication link interfaces comply with the technical standards listed in the table
below.
5.5 Jitter and Wander Standards
To allow problem-free interconnection of different network elements in a telecommunications network, it is neces-
sary to satisfy maximum jitter and wander amplitude criteria at the interfaces. On the other hand, inputs must
tolerate a certain amount of jitter and wander. The accumulation of jitter in a chain of regenerators must be limited
by compliance with jitter transfer functions. This is the reason behind the requirements stipulated for all digital hier-
archy levels in the standards of the ITU-T, ANSI and ETSI. The following table specifies the output limits for the
serving interfaces (Iu/Iub) which are used as input for RNC and Node B.
Interface Market Standards
E1 / 2.048 Mbps (75 coax /
120 twisted pair)
World-wide ITU-T: G.703, G.704, G.823
EN 300166, TBR13
STM-1 / 155.52 Mbps (optical) World-wide ITU-T: G.703, G.825, G.957,
I.432.2
J1 / 1.544 Mbps (100 twisted pair) Japan JT-G703, JT-G704,
JT-I.431-a
T1 / 1.544 Mbps (100 twisted pair) North America ITU-T G.703
ANSI T1.403
OC-3 / 155.52 Mbps (optical) North America ITU-T: G.703, G.707, G.783
G.957, I.432.1
ANSI T1.105
Table 21 Telecommunication link interfaces
Network
interface
used for:
Standard Bit
rate
Jitter limits Hints
Wide-band
Jitter/UIPP
High-band
Jitter/UIPP
Measurement ANT-20 mask
SDH
transport
ITU-T G.825,
ETSI
EN 302 084
STM-1 1.5 0.15 STM-N interface
is per definition a
synchronization
interface
"ITU-T Synchronous
Equipment Clock
Network Interface /
SEC G.823/G.825"
PDH
transport
ITU-T G.823,
ETSI
EN 302 084
2048
kbit/s
1.5 0.2 E1 Traffic Inter-
face (MRTIE):
G.823 5.2.1
(equal to EN 302
084 5.2.1)
"ETSI/2M
Network Interface
(EN 302 084)"
Table 22 Jitter and wander requirements


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
213
TED:UTRAN Common Quality Standards / Specifications
Id:0900d80580118ddd
5.6 Surge (Lightning) Protection
The external ports of the Siemens/NEC UTRAN equipment meet the standards listed in Table 23. The perfor-
mance criterion according to internal requirements is: no malfunction after application.
Synchro-
nization
(and
transport)
ITU-T G.823,
ETSI
EN 300 462-3-1
SDH/S
EC
0.5 0.2 Synch. Interface
(MTIE/TDEV)
"ITU-T Synchronous
Equipment Clock
Network Interface /
SEC G.823/G.825"
PDH 1.5 0.2 Synch. Interface
(MTIE/TDEV)
"ITU-T/PDH Sync.IF
(G.823)"
External port Test method and related standards
Antenna
NB-341
NB-420/NB-440/NB-441
NB-860/NB-880/NB-861
NB-881/NB-881 HR
RS-381
RSSU-380/RSCU-380
RS-880
IEC 61000-4-5, IEC 62305-1, IEC 62305-4
10 kV line to screen, 1.2/50 s
1.5 kV line to screen, 8/500 s
AC power
NB-341
NB-441
NB-861
NB-881/NB-881 HR
RS-381
IEC 61000-4-5, IEC 61000-6-2, IEC 62305-1, IEC 62305-4
10 kV line to earth, 1.2/50 s
2.5 kV line to line, 1.2/50 s
1.5 kV line to earth, 8/500 s
DC power
NB-440/NB-420
NB-880/NB-860
RSSU-380/RSCU-380
RS-880
IEC 61000-4-5, IEC 61000-6-2, IEC 62305-1, IEC 62305-4
5 kV line to earth, 1.2/50 s
1 kV line to line, 1.2/50 s
RN-750 IEC 61000-4-5, IEC 61000-6-2
0.5 kV line to earth, 1.2/50s
0.5 kV line to line, 1.2/50s
Table 23 Surge (lightning) protection standards
Network
interface
used for:
Standard Bit
rate
Jitter limits Hints
Wide-band
Jitter/UIPP
High-band
Jitter/UIPP
Measurement ANT-20 mask
Table 22 Jitter and wander requirements


214 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118ddd
Quality Standards / Specifications
Signal and Control lines
NB-341
NB-420/NB-440/NB-441
NB-860/NB-880/NB-861
NB-881/NB-881 HR
RS-381
RSSU-380/RSCU-380
RS-880
shielded outdoor line
ACTM with OPEXAL, OVPT (clock, ext. Ethernet)
IEC 61000-4-5, IEC 61305-1, IEC 62305-410 kV line to
earth, 1.2/50 s
2.5 kV line to line, 1.2/50 s
1.5 kV line to earth, 8/500 s
shielded indoor line
IEC 61000-4-5, IEC 61000-6-2
ACTM without OPEXAL, Iub-Connector
1 kV line to earth, 1.2/50 s
RN-750 indoor line
IEC 61000-4-5, IEC 61000-6-2
0.5 kV line to earth, 1.2/50s
Telecommunication Links
NB-341
NB-420/NB-440/NB-441
NB-860/NB-880/NB-861
NB-881/NB-881 HR
RS-381
RSSU-380/RSCU-380
RS-880
shielded outdoor line
OVPT
IEC 60950-1, IEC 61000-4-5, IEC 62305-1, IEC 62305-4,
TBR12, TBR13
1.5 kV line to earth, 10/700 s
10 kV line to earth, 1.2/50 s
2.5 kV line to line, 1.2/50 s
1.5 kV line to earth, 8/500 s
shielded indoor line
Iub-Connector
IEC 61000-4-5, IEC 61000-6-2
1.0 kV line to earth, 1.2/50 s
RN-750 shielded indoor line
IEC 61000-4-5, IEC 61000-6-2, TBR12, TBR13
1.0 kV line to earth, 1.2/50 s
External port Test method and related standards
Table 23 Surge (lightning) protection standards


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
215
TED:UTRAN Common Quality Standards / Specifications
Id:0900d80580118ddd
5.7 Environmental Standards
The Siemens/NEC UTRAN equipment meets the standards defined in the references of Environmental Require-
ments for Stationary Use.
Environment Standards
Climatic conditions
NB-440/NB-420
NB-880/NB-860
RSSU-380/RSCU-380
RS-880
EN 300019-1-3 Class 3.1
Testspecification: EN 300019-2-3 T3.1E
-5C +45C (23F ... 113F)
(w/o performace degradation)
NB-441, NB-861,
NB-881/NB-881 HR, RS-381
EN 300019-1-4 Class 4.1
Testspecification: EN 300019-2-4 T4.1
-33C+50C (-27.4F ... 122F)
(w/o performance degradation)
NB-341 EN 300019-1-4 Class 4.1
Testspecification: EN 300019-2-4 T.4.1
-33C +45C (-27.4F ... 113F)
(w/o performance degradation)
+45C+50C (113F ... 122F)
(performance degradation regarding air-
interface possible)
RN-750 EN 300019-1-3 Class 3.1
Testspecification: EN 300019-2-3 T3.1
+5C+40C (23F ... 104F)
Mechanical conditions
NB-440/NB-420
NB-880/NB-860
RSSU-380/RSCU-380
RS-880
RN-750
EN 300019-1-3 Class 3.1
Testspecification:
EN 300019-2-3 T3.2
IEC 60721-3-4 Class 4M3
NB-441, NB-861,
NB-881/NB-881 HR,
NB-341, RS-381
EN 300019-1-4 Class 4.1
Testspecification:
EN 300019-2-4 T4.1
IEC 60721 Class 4M5
Acoustic noise emission
Table 24 Environmental standards for stationary use


216 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118ddd
Quality Standards / Specifications
NB-440/NB-420
NB-880/NB-860
RSSU-380/RSCU-380
RS-880
RN-750
ETS 300753 (6), Class 3.1:
Measurement method: ISO 7779
6.3 B(A) sound power @ 23C (73.4F)
(business area, < 4 m from desk work loca-
tions)
RRH-pi EN 300019-1-3 Class 3.3
Testspecification:
EN 300019-2-3 T3.3
-25C +55C (-13F ... 131F)
(w/o performance degradation)
NB-341 ETS 300753 (6), Class 3.1:
Measurement method: ISO 7779
ETS 300753 (6), Class 4.1E (rural area):
Measurement method: ISO 7779
6.1 B(A) sound power @ 23C (73.4F)
6.7 B(A) sound power @ 45C (113F)
RRH-m EN300019-1-4 Class 1.4
Testspecification:
EN 300019-2-4 T4.1
-40C +55C (-40F ... 131F)
(w/o performance degradation)
NB-441, NB-861,
NB-881/NB-881 HR, RS-381
ETS 300753 (6), Class 4.1E (rural area):
Measurement method: ISO 7779
6.1 B(A) sound power @ 23C (73.4F)
6.7 B(A) sound power @ 45C (113F)
Earthquake standards
NB-341
NB-420/NB-440/NB-441
NB-860/NB-880/NB-861
NB-881/NB-881 HR
RS-381
RSSU-380/RSCU-380
RS-880
EN 300019-2-3 chapter 4.2
(zone 4 acc. IEC 60721-2-6)
Storage/transportation
Environment Standards
Table 24 Environmental standards for stationary use


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
217
TED:UTRAN Common Quality Standards / Specifications
Id:0900d80580118ddd
5.7.1 Environmental Protection
The design and manufacturing of the Siemens/NEC UTRAN equipment follows the environmental protection
guidelines of the references listed below:
IEC-Guide 109 Environmental aspects inclusion in electrotechnical Product Standards
Siemens Norm SN 36350 Product design, recycling, environmental protection, ecological compatibility,
product development
European Directive 94/62/EC on packaging and packaging waste
European Directive 2002/96/EC Measures on the collection, treatment, recycling and disposal of Waste Elec-
trical and Electronic Equipment (WEEE)
European Directive 2002/95/EC Restriction of the use of certain Hazardous Substances in electrical and elec-
tronic equipment (RoHS)
Green Purchasing Guideline (materials and parts): NIS-E-0403 (B)
(NEC internal standard - only applicable to Japanese market)
Guideline for Green Purchasing Procedure (materials and parts): NIS-E-0404 (B)
(NEC internal standard - only applicable to Japanese market)
BattV Verordnung fr die Rcknahme und Entsorgung gebrauchter Batterien und Akkumulatoren (only in
Germany)
ISO 14040 Environmental Management - Life cycle assessment - Principles and framework
ISO 14041 Environmental management - Life cycle assessment - Goal and scope definition and inventory
analysis
ISO 14042 Environmental management - Life cycle assessment - Life cycle impact assessment
ISO 14043 Environmental management - Life cycle assessment - Life cycle interpretation
ISO 14020 Environmental labels and declarations - General principles
NB-341
NB-420/NB-440/NB-441
NB-860/NB-880/NB-861
NB-881/NB-881 HR
RS-381
RSSU-380/RSCU-380
RS-880
RN-750
Storage:
ETS300019-1-1 Class 1.2
Test: EN 300019-2-1 test 1.2
Transportation:
ETS 300019-1-2 Class 2.3
Test: EN 300019-2-2 test 2.3
Environment Standards
Table 24 Environmental standards for stationary use


218 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118ddd
Quality Standards / Specifications
5.8 Reliability
5.8.1 Reliability Calculations
Reliability calculations are based on IEC 61709 - electronic components - reliability - reference conditions for
failure rates and stress models for conversion. High-reliability equipment configurations can be optionally provided
using (N+1) redundancy or load sharing techniques for those Least Replaceable Units (LRUs) which play a key
role in the total system availability. The resulting reliability or availability depends on the configuration and the
applied redundancy of the equipment type.
The reliability prediction values are based on component failure rate predictions by SN29500. The Siemens Norm
29500 is used by Siemens AG and the Siemens companies as a uniform basis for reliability predictions. For all
LRUs for which different manufactures are available the worst failure rate is taken into account for the availability
calculation.
Mean Repair Time (MRT)
The Mean Repair Time (MRT, also called Intrinsic MTTR) indicates the summation of fault location, correction,
and verification times for cases of corrective maintenance made on repairable units.
The MRT objectives for the Siemens/NEC UTRAN equipment are:
Node B:1 hour
OMC, RNC:2 hours for plug-in unit
1 - 3 hours for other fixed-mounted entities
Mean Time Between Failures (MTBF)
The Mean Time Between Failures (MTBF) indicates the expectation of the operating time between failures.
MTBF values for the Siemens/NEC UTRAN equipment are given in:
TED:UTRAN NB-440/NB-441
TED:UTRAN NB-420
TED:UTRAN NB-341
TED:UTRAN NB-530
TED:UTRAN NB-880/NB-881/NB-881HR
TED:UTRAN NB-860/NB-861
TED:UTRAN RS-880/RRHs
TED:UTRAN RS-381/RRHs
TED:UTRAN RSCU-380/RRHs
TED:UTRAN RSSU-380/RRHs
TED:UTRAN RN-750
5.8.2 Maintainability
The UTRAN equipment allows easy service access for maintenance personnel. Access to cable terminations will
be provided at one particular area.
5.8.3 Built-in Self-Test
The UTRAN equipment will support both continuous built-in self-tests and operator initiated built-in self-tests. Fault
location functions for the least replaceable unit (LRU, e.g. plug-in card) are also provided. If the built-in self-test
cannot without a doubt localize the fault to one LRU, it will indicate a restricted number of LRUs according to the
probability of being faulty.


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
219
TED:UTRAN Common Quality Standards / Specifications
Id:0900d80580118ddd
5.9 List of Norms and Standards
NORM/STANDARD Description
1999/5/EC R&TTE Directive: Radio Equipment and Telecommunications Terminal Equipment
and the mutual recognition of their conformity
2002/95/EC (RoHS) Restriction of the use of certain Hazardous Substances in electrical and electronic
equipment
2002/96/EC (WEEE) Measures on the collection, treatment, recycling and disposal of Waste Electrical and
Electronic Equipment
3GPP TS 25.113 EMC specification for Node B and ancillary equipment given by 3GPP standardization
group
3GPP TS 25.104/141 Requirements regarding the air-interface (spurious emissions, ACLR, sensitivity,)
given by 3GPP standardization group
3GPP TS 25.141 Test specification for 3GPP TS25.141 given by 3GPP standardization group
3GPP TS 25.142 Test specification for 3GPP TS25.142 given by 3GPP standardization group
3GPP TS 25.411 Test specification for 3GPP TS25.411 given by 3GPP standardization group
47 CFR 2 Frequency allocations and radio treaty matters; general rules and regulations / US-
standard
47 CFR 15 Radio Frequency Devices / US-standard
47 CFR 22 Public Mobile Services / US-standard
47 CFR 24 Personal Communications Services / US-standard
73/23/EEC Low Voltage Directive
89/336/EEC EMC Directive
94/62/EC Directive on packaging and packaging waste
ANSI T1.105 Synchronous Optical Network (SONET) - Basic Description including Multiplex Struc-
ture, Rates and Formats
ANSI T1.403 Telecommunications - Network and Customer Installation Interfaces - DS1 Electrical
Interface
BattV Verordnung fr die Rcknahme und Entsorgung gebrauchter Batterien und Akkumu-
latoren (only in Germany)
CISPR 24 Information technology equipment. Immunity characteristics. Limits and methods of
measurement
EN 300019-1-3 Environmental conditions and environmental test for telecommunication equipment -
Part 1-3: Classification of environmental conditions Stationary use at weatherpro-
tected locations
EN 300019-1-4 Environmental conditions and environmental test for telecommunication equipment -
Part 1-4: Classification of environmental conditions Stationary use at non-weather-
protected locations
Table 25 List of applied norms and standards


220 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118ddd
Quality Standards / Specifications
EN 300019-2-1 Environmental conditions and environmental tests for telecommunications equipment
Part 2-1: Specification of environmental tests Storage
EN 300019-2-2 Environmental conditions and environmental tests for telecommunications equipment
Part 2-2: Specification of environmental tests Transportation
EN 300019-2-3 Environmental conditions and environmental tests for telecommunications equipment
Part 2-3: Specification of environmental tests - Stationary use at weather-protected
locations
EN 300019-2-4 Environmental conditions and environmental tests for telecommunications equipment
Part 2-3: Specification of environmental tests - Stationary use at non-weather-pro-
tected locations
EN 300386-2 Electromagnetic compatibility and Radio spectrum Matters (ERM); Telecommunica-
tion network equipment; ElectroMagnetic Compatibility (EMC) requirements; Part 2:
Product family standard
EN 301087 Base Station System (BSS) equipment specification; Radio aspects (GSM 11.21)
EN 301489-1 Electromagnetic compatibility and Radio spectrum Matters (ERM);
Electromagnetic Compatibility (EMC) standard for radio equipment and services; Part
1: Common technical requirements
EN 301489-23 Part 23: specific condition for 3rd Generation Partnership Project (UMTS) Base station
radio and ancillary equipment
EN 301502 Harmonized EN for GSM; Base Station and Repeater equipment covering essential
requirements under article 3.2 of the R&TTE directive
EN 302084 Standards for output jitter and wander at network interfaces used for SDH and PDH
transport.
EN 300 462-3-1 Standards for output jitter and wander at network interfaces used for synchronization.
EN 50082-2 Electromagnetic compatibility - Generic immunity standard -- Part 2: Industrial environ-
ment
EN 50121-4 EMC Standards for Railways
EN 50385 Compliance boundaries for radio equipment
EN 55022 Limits and methods of measurement of radio interference characteristics of informa-
tion technology equipment
ETS 300019-1-3 Environmental conditions and environmental tests for telecommunications equipment
Part 1-3: Classification of environmental conditions - Stationary use at weather-pro-
tected locations
ETS 300019-1-4 Environmental conditions and environmental tests for telecommunications equipment
Part 1-4: Classification of environmental conditions - Stationary use at non-weather-
protected locations
ETS 300753 Equipment Engineering (EE); Acoustic noise emitted by telecommunications equip-
ment
FCC Part 2.1053 Field strength of spurious radiations (US-standard)
NORM/STANDARD Description
Table 25 List of applied norms and standards


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
221
TED:UTRAN Common Quality Standards / Specifications
Id:0900d80580118ddd
FCC Part 2.1057 Frequency spectrum of spurious radiation (US-standard)
FCC Part 15.111 Antenna power conduction limits for receivers (US-standard)
FCC Part 15.107 Conducted emission (US-standard)
FCC Part 15.109 Radiated emission (US-standard)
FCC Part 15.31 Measurement standards (US-standard)
FCC Part 15.33 Frequency range of radiated measurements (US-standard)
FCC Part 15.35 Measurement detector functions and bandwidths (US-standard)
GR-63 Telcordia document GR-63-Core, Issue 2, October 2002:
Network Equipment-Building System (NEBS) Requirements - Physical Protection
GR-1089 Telcordia document GR-1089-Core, Issue 3, October 2003:
Electromagnetic Compatibility and Electrical Safety - Generic Criteria for Telecommu-
nications Equipment
IEC 60068-2-11 Environmental testing regarding resistivity against air pollution and salt mist
IEC 60215 Safety requirements for radio transmitting equipment
IEC 60529 Degrees of protection provided by enclosures (IP code)
IEC 60721-2-6 Classification of environmental conditions. Part 2: Environmental conditions appearing
in nature. Earthquake vibration and shock
IEC 60825-1 Safety of laser products. Equipment classification, requirements and user's guide
IEC 60825-2 Safety of laser products. Safety of optical fibre communication systems
IEC 60950 Safety of information technology equipment
IEC 61000-3-3 Electromagnetic compatibility (EMC) -- Part 3-3: Limits - Limitation of voltage fluctua-
tions and flicker in low-voltage supply systems for equipment with rated current up to
16 A
IEC 61000-4-2 Electromagnetic compatibility (EMC) - Part 4: Testing and measurement techniques -
Section 2: Electrostatic discharge immunity test
IEC 61000-4-5 Electromagnetic compatibility (EMC). Testing and measurement techniques. Surge
immunity test
IEC 61000-6-2 Electromagnetic compatibility (EMC) -- Part 6-2: Generic standards - Immunity for
industrial environments
IEC 61312-1 Protection against lightning electromagnetic impulse Part 1: General principles
IEC 61709 Electronic components Reliability Reference conditions for failure rates and stress
models for conversion
IEC-Guide 109 Environmental aspects inclusion in electrotechnical product standards
IEEE 982.2 IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable
Software
IEEE Std 1228 Standard for Software Safety Plans
ISO 14020 Environmental labels and declarations - General principles
NORM/STANDARD Description
Table 25 List of applied norms and standards


222 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118ddd
Quality Standards / Specifications
ISO 14040 Environmental Management - Life cycle assessment - Principles and framework
ISO 14041 Environmental management - Life cycle assessment - Goal and scope definition and
inventory analysis
ISO 14042 Environmental management - Life cycle assessment - Life cycle impact assessment
ISO 14043 Environmental management - Life cycle assessment - Life cycle interpretation
ITU-T G.703 Physical/electrical characteristics of hierarchical digital interfaces
ITU-T G.704 Synchronous frame structures used at 1544, 6312, 2048, 8448 and 44 736 kbit/s hier-
archical levels
ITU-T G.706 Frame alignment and cyclic redundancy check (CRC) procedures relating to basic
frame structures defined in Recommendation G.704
ITU-T G.707 Network node interface for the synchronous digital hierarchy (SDH)
ITU-T G.708 Sub STM-0 network node interface for the synchronous digital hierarchy (SDH)
ITU-T G.709 Synchronous multiplexing structure
ITU-T G.751 Digital multiplex equipment operating at the third order bit rate of 34 368 kbit/s and the
fourth order bit rate of 139 264 kbit/s and using positive justification
ITU-T G.753 Third order digital multiplex equipment operating at 34 368 kbit/s and using posi-
tive/zero/negative justification
ITU-T G.783 Characteristics of synchronous digital hierarchy (SDH) equipment functional blocks
ITU-T G.804 ATM cell mapping into plesiochronous digital hierarchy (PDH)
ITU-T G.823 The control of jitter and wander within digital networks which are based on the 2048
kbit/s hierarchy
ITU-T G.825 The control of jitter and wander within digital networks which are based on the STM-1
hierarchy
ITU-T G.832 Transport of SDH elements on PDH networks - Frame and multiplexing structures
ITU-T G.841 Types and characteristics of SDH network protection architectures
ITU-T G.957 Optical interfaces for equipment and systems relating to the synchronous digital hier-
archy
ITU-T I.431 Primary rate user-network interface Layer 1 specification
ITU-T I.432.x B-ISDN User-Network Interface-Physical Layer Specification
ITU-T K.20 Resistibility of telecommunication switching equipment to overvoltages and overcur-
rents
JT-G.703 Physical/Electrical Characteristics of Hierarchical Digital Interface (Japanese stan-
dard)
JT-G.704 Frame Structures on Primary and Secondary Hierarchical Digital Interface (Japanese
standard)
JT-G.708 Sub STM-0 network node interface for the synchronous digital hierarchy (SDH) (Jap-
anese standard)
NORM/STANDARD Description
Table 25 List of applied norms and standards


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
223
TED:UTRAN Common Quality Standards / Specifications
Id:0900d80580118ddd
JT-G.709 Synchronous multiplexing structure (Japanese standard)
JT-G.957 Optical Interface for Equipment and Systems Relating to the Synchronous Digital Hier-
archy (Japanese standard)
JT-I.431a Leased Line Primary Rate User-Network Interface layer1-Specification (Japanese
standard)
JT-I.432.1 B-ISDN User-Network Interface-Physical Layer Specification-General Characteristics
(Japanese standard)
JT-I.432.2 B-ISDN User-Network Interface Physical Layer Specification for 155520 kbit/s and
622080 kbit/s (Japanese standard)
JT-I.432.4 B-ISDN User-Network Interface Physical Layer Specification for 51840 kbit/s (Japa-
nese standard)
NEMA 250 Enclosures of electrical equipment (1000V maximum): outdoor equipment meets Type
3 R requirements
R&TTE Radio Equipment and Telecommunications Terminal Equipment and the mutual rec-
ognition of their conformity
SBC-TP-76200 Network Equipment Power, Grounding, Environmental, and Physical Design
Requirements, Issue 5A, February 2004 (company specific standard of SouthWest-
ern Bell Corporation)
SR-3580 Bellcore Special Report SR-3580, Issue 1, November 1995:
Network Equipment - Building System (NEBS) Criteria Levels
SN36350 Product design, recycling, environmental protection, ecological compatibility, product
development
TBR 12 Business telecommunications (btc). Open network provision (onp) technical require-
ments. 2048 kbit/s digital unstructured leased line (d2048u). Attachment requirements
for terminal equipment interface.
TBR 13 Business telecommunications (btc). 2048 kbit/s digital structured leased line (d2048s).
Attachment requirements for terminal equipment interface
TSM 11.21 Base Station System (BSS) equipment specification; Radio aspects; TD-SCDMA @
GSM Core Network
UL 60950-1 Standard for the safety of information technology equipment, including electrical
business equipment
YDN 122-1999 China Information Industry Net (CNII): B-ISDN No.7, B-SCCP
YDN 102-1998 China Information Industry Net (CNII): B-ISDN No.7, B-MTP
NORM/STANDARD Description
Table 25 List of applied norms and standards


224 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dce
Appendix - Message Sequence Charts
6 Appendix - Message Sequence Charts


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
225
TED:UTRAN Common Appendix - Message Sequence Charts
Id:0900d80580118dce
6.1 External Inter-RNC and Inter-PLMN Handover
Figure 137 MSC: External Inter-RNC and Inter-PLMN Handover
RNSAP
RRC
RRC
Cell Update
(*1)
Relocation
UL Signaling Transfer Indication
Target
RNC
New
SGSN
Old
SGSN
Source
RNC
UE
RRC
GTP-C
RANAP
RNSAP
Connected
RANAP
RRC
RNSAP
GTP-C
RANAP
RANAP
RNSAP
RRC
RRC
(*1)
or URA Update or RRC Connection Re-establishment Request
(*2)
or URA Update Confirm or RRC Connection Re-establishment
(*3)
or RRC Connection Re-establishment Complete
Cell Update Confirm
(*2)
Radio Bearer Reconfiguration Complete
(*3)
Required
Relocation
Request
Relocation
Request
Acknowledge
RANAP RANAP
GTP-C GTP-C
Forward
Relocation
Request
Relocation
Command
RANAP RANAP
Relocation
Commit
RANAP RANAP
Relocation
Detect
RANAP RANAP
Relocation
Complete
GTP-C GTP-C
GTP-C GTP-C
Forward
Relocation
Complete
Forward
Relocation
Complete
Acknowledgement
RANAP RANAP
RANAP RANAP
Iu Release
Command
Iu Release
Complete


226 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dce
Appendix - Message Sequence Charts
6.2 Inter/Intra-Frequency Inter-PLMN Relocation
Figure 138 MSC: Inter/Intra-Frequency Inter-PLMN Relocation
UE Node B source Node B target SRNC TRNC CN CS CN PS CN CS CN PS
PLMN source PLMN source PLMN target PLMN target
Decision to perform SRNC
Relocation on CELL_DCH
RELOCATION
RELOCATION REQUEST
RELOCATION REQUEST
RANAP RANAP
RANAP RANAP
REQUIRED
RELOCATION
REQUIRED
RANAP RANAP
RANAP RANAP
RELOCATION REQUEST
RELOCATION REQUEST
RANAP
RANAP
RANAP RANAP
Intra-CN communication
(outside of UTRAN procedural scope)
ALCAP Iu Transport Bearers Setup
Procedure
Radio Link Setup Procedure
ALCAP Iub Transport Bearers Setup
Procedure
RANAP RANAP
RELOCATION
RELOCATION
RANAP RANAP
NBAP
RRC RRC
DCCH: RADIO BEARER
RADIO LINK
NBAP
NBAP
NBAP
RANAP
RANAP RANAP
RANAP
DCCH: RADIO BEARER
RRC RRC
RELOCATION DETECT
RELOCATION DETECT
RELOCATION COMPLETE
RELOCATION COMPLETE
RANAP
RANAP
RANAP
RANAP
RANAP RANAP
Intra-CN communication
(outside of UTRAN procedural scope)
Iu RELEASE COMMAND
Iu RELEASE
RANAP RANAP
ALCAP Iu Transport Bearers Release Procedure
RADIO LINK
Radio Link Deletion Procedure
RANAP
RANAP
RANAP RANAP
Iu RELEASE COMPLETE
Iu RELEASE
State:
CELL_DCH
In case of UMR TRNC, the RRC Radio
Bearer Reconfiguration is performed
If the TRNC belongs to other vendors,
the following procedures may be
performed in addition:
- RRC Radio Bearer Setup
- Radio Bearer Release
- RRC Transport Channel
ACKNOWLEDGE
ACKNOWLEDGE
COMMAND
COMMAND
RECONFIGURATION
RESTORE
FAILURE
INDICATION
RECONFIGURATION COMPLETE
COMMAND
COMPLETE
R
e
l
o
c
a
t
i
o
n
R
e
l
o
c
a
t
i
o
n

P
r
e
p
a
r
a
t
i
o
n
R
e
l
o
c
a
t
i
o
n

R
e
s
o
u
r
c
e

A
l
l
o
c
a
t
i
o
n
R
e
l
o
c
a
t
i
o
n

C
o
m
p
l
e
t
i
o
n
R
e
l
o
c
a
t
i
o
n

E
x
e
c
u
t
i
o
n
INDICATION
State:
CELL_DCH
UTRAN Mobility Information procedure
To synchronize ciphering
information between SRNC, UE and
Intra-CN communication
(outside of UTRAN procedural scope)
opt. 1
1

T
r
i
g
g
e
r
Only if ciphering
synchronization
is required
ALCAP Iub Transport Bearers Release Procedure


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
227
TED:UTRAN Common Appendix - Message Sequence Charts
Id:0900d80580118dce
6.3 Intra-Frequency Intra-PLMN Relocation
Figure 139 MSC: Intra-Frequency Intra-PLMN Relocation
State:
CELL_DCH
UE Node B1 (TRNC) SRNC TRNC CN CS CN PS
Decision to perform Intra-PLMN Intra-frequency
SRNS Relocation on CELL_DCH
RELOCATION
RELOCATION REQUEST
RELOCATION REQUEST
RANAP RANAP
RANAP RANAP
REQUIRED
RELOCATION
REQUIRED
RANAP RANAP
RANAP RANAP
RELOCATION REQUEST
RELOCATION REQUEST
RANAP
RANAP
RANAP RANAP
ALCAP Iu Transport Bearers Setup Procedure
RANAP RANAP
RELOCATION
RELOCATION
RANAP RANAP
NBAP
RRC RRC
DCCH: RADIO BEARER
RADIO LINK
NBAP
NBAP
NBAP
RANAP
RANAP RANAP
RANAP
DCCH: RADIO BEARER
RRC RRC
RELOCATION DETECT
RELOCATION DETECT
RELOCATION COMPLETE
RELOCATION COMPLETE
RANAP
RANAP
RANAP
RANAP
RANAP RANAP
Iu RELEASE COMMAND
RANAP RANAP
ALCAP Iu Transport Bearers Release Procedure
RADIO LINK
Iub Radio Link Deletion Procedure
ALCAP Iub Transport Bearers Release Procedure
RANAP
RANAP
RANAP RANAP
Iu RELEASE COMPLETE
Iu RELEASE
State:
CELL_DCH
ACKNOWLEDGE
ACKNOWLEDGE
COMMAND
COMMAND
RECONFIGURATION
RESTORE
FAILURE
INDICATION
RECONFIGURATION COMPLETE
COMPLETE
R
e
l
o
c
a
t
i
o
n

P
r
e
p
a
r
a
t
i
o
n
R
e
l
o
c
a
t
i
o
n

R
e
s
o
u
r
c
e

A
l
l
o
c
a
t
i
o
n
R
e
l
o
c
a
t
i
o
n

C
o
m
p
l
e
t
i
o
n
R
e
l
o
c
a
t
i
o
n

E
x
e
c
u
t
i
o
n
Timing re-initializing HHO
INDICATION
ALCAP Iur Transport Bearers Release Procedure
RNSAP
RNSAP
RADIO LINK FAILURE INDICATION
Iu RELEASE COMMAND
Iur Radio Link Deletion Procedure
State:
CELL_DCH
ALCAP Iub Transport Bearers Setup Procedure
R
e
l
o
c
a
t
i
o
n

T
r
i
g
g
e
r
In case of UMR TRNC, the RRC Radio
Bearer Reconfiguration is performed
If the TRNC belongs to other vendors,
the following procedures may be
performed in addition:
- RRC Radio Bearer Setup
- Radio Bearer Release
- RRC Transport Channel
Radio Link Setup Procedure
UTRAN Mobility Information procedure
To synchronize ciphering
information between SRNC, UE and
opt. 1
1
Only if ciphering
synchronization
is required
source cell
Node B1 (TRNC)
target cell
opt. 1
1
Only if
Iur
present
opt. 1
1
Only if
Iur
present
opt.
1
1
Only if
Iur
present


228 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dce
Appendix - Message Sequence Charts
6.4 UMTS-GSM Handover
Figure 140 MSC: UMTS-GSM Handover (Part1)
Relocation
Target
BSC
2G-MSC SRNC
UE
Connected
RANAP RANAP
Required
Handover
Request Acknowledge
Handover
Request
Relocation
Command
RANAP RANAP
RRC RRC
DCCH:
Handover
Command
3G-MSC
MAP MAP
Prepare Handover
(handover request)
BSS
MAP
BSS
MAP
Switching the UE on the channel of the new GSM cell
MAP MAP
Prepare Handover
(handover request
Response
acknowledge)
ISUP ISUP
IAM
ISUP ISUP
ACM
Assignment of
BSS
MAP
BSS
MAP
ISUP ISUP
ANM
Intersystem
(*1)
(*1) These charts follow the normal GSM procedures and are shown only for clarity.
Resources


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
229
TED:UTRAN Common Appendix - Message Sequence Charts
Id:0900d80580118dce
Figure 141 MSC: UMTS-GSM Handover (Part2)
Target
BSC
2G-MSC SRNC
UE
RANAP RANAP
RANAP RANAP
Iu Release
Command
Iu Release
Complete
3G-MSC
Switching the UE on the channel of the new GSM cell
Handover
Detect
BSS
MAP
BSS
MAP
RR RR
Handover Complete
ISUP ISUP
REL
ISUP ISUP
RLC
Handover
Complete
BSS
MAP
BSS
MAP
MAP MAP
Send End Signal
Interruption of
old Resources
MAP MAP
Send End Signal
Response
(*1)
(*1) These charts follow the normal GSM procedures and are shown only for clarity.
Request


230 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dce
Appendix - Message Sequence Charts
6.5 GSM-UMTS Handover
Figure 142 MSC: GSM-UMTS Handover (Part1)
Handover
BSC 3G-MSC TRNC
UE
Connected
Required
Relocation
Request Acknowledge
Relocation
Request
Handover
Command
RR RR
Intersystem
Handover
Command
2G-MSC
MAP MAP
Prepare Handover
(handover request)
BSS
MAP
BSS
MAP
Switching the UE on the channel of the new UMTS cell
RANAP RANAP
MAP MAP
Prepare Handover
(handover request
Response
acknowledge)
ISUP ISUP
IAM
ISUP ISUP
ACM
Assignment
of Resources
RANAP RANAP
(*1)
(*1) These charts follow the normal GSM procedures and are shown only for clarity.
BSS
MAP
BSS
MAP
ISUP ISUP
ANM


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
231
TED:UTRAN Common Appendix - Message Sequence Charts
Id:0900d80580118dce
Figure 143 MSC: GSM-UMTS Handover (Part2)
BSC
3G-MSC SRNC
UE
Clear
Command
Clear
Complete
2G-MSC
Switching the UE on the channel of the new UMTS cell
Relocation
Detect
BSS
MAP
BSS
MAP
RRC RRC
DCCH: Handover Complete
ISUP ISUP
REL
ISUP ISUP
RLC
Relocation
Complete
MAP MAP
Send End Signal
Interruption of
old Resources
MAP MAP
Send End Signal
Response
RANAP RANAP
BSS
MAP
BSS
MAP
RANAP RANAP
Request
(*1)
(*1) These charts follow the normal GSM procedures and are shown only for clarity.


232 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dce
Appendix - Message Sequence Charts
6.6 Compressed Mode and GSM Measurement Activation
Figure 144 MSC: Compressed Mode and GSM Measurement Activation
Serving RNC
RRC
RRC
Node B
(Drift RNS)
Drift RNC
Trigger CM
NBAP NBAP
NBAP NBAP
RNSAP
RRC
RRC
Radio Link
Radio Link
Radio Link
DCCH: Physical Channel Reconfiguration Complete
Measurement Control
Reconfiguration Prepare
NBAP NBAP
Reconfiguration Ready
Reconfiguration Commit
UE
RRC RRC
DCCH: Physical Channel Reconfiguration
ALT1
ALT2
ALT1
ALT2
Without Iur (no Relocation via DRNC)
With Iur only (Relocation via DRNC)
RNSAP
Radio Link
Reconfiguration
Prepare
NBAP NBAP
Radio Link
Reconfiguration
Prepare
NBAP NBAP
Radio Link
Reconfiguration
Ready
RNSAP RNSAP
Radio Link
Reconfiguration
Ready
RNSAP RNSAP
Radio Link
Reconfiguration
Commit
NBAP NBAP
Radio Link
Reconfiguration
Commit


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
233
TED:UTRAN Common Appendix - Message Sequence Charts
Id:0900d80580118dce
6.7 Compressed Mode and GSM Measurement Deactivation
Figure 145 MSC: Compressed Mode and GSM Measurement Deactivation
Serving RNC
RRC
Node B
(Drift RNS)
Drift RNC
Deactivate CM
RNSAP
RRC
Compressed Mode Command
Measurement Control
NBAP NBAP
UE
ALT1
ALT2
ALT1
ALT2
Without Iur (no Relocation via DRNC)
With Iur only (Relocation via DRNC)
RNSAP
Compressed
Mode
Command
NBAP NBAP
Compressed
Mode
Command


234 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dce
Appendix - Message Sequence Charts
6.8 UMTS Cell (Re-)Selection to/from GPRS
Figure 146 MSC: UMTS Cell (Re-)Selection to/from GPRS
RNC Node B UE
CELL_FACH state
CN
RLSD
RLC
RANAP RANAP
SRNS Context
Request
RANAP RANAP
SRNS Context
Response
RANAP RANAP
Iu Release
Command
Iu Release Procedure
RANAP RANAP
Iu Release
Complete


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
235
TED:UTRAN Common Appendix - Message Sequence Charts
Id:0900d80580118dce
6.9 Soft Handover - Radio Link Setup
Figure 147 MSC: Soft Handover - Radio Link Setup
Serving RNC
RNSAP
RNSAP
RRC
RRC
UE
Node B
(Drift RNS)
Drift RNC
Decision to set up
new Radio Link
RNSAP
NBAP NBAP
NBAP NBAP
RNSAP
RRC
RRC
ALCAP Iur Bearer
Setup
1. Radio Link
Setup
2. Radio Link
Setup
3. Radio Link
Response
4. Radio Link
Setup
Setup
5. ALCAP Iub Bearer
Setup
6. Node B-SRNC Data Transport
Bearer Sync.
7. DCCH: Active Set Update
8. DCCH: Active Set Update Complete
Start RX and TX
Request
Request
[Radio Link Addition]
Start TX
DCH-FP DCH-FP
Response
Start TX


236 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dce
Appendix - Message Sequence Charts
6.10 Soft Handover - Radio Link Deletion
Figure 148 MSC: Soft Handover - Radio Link Deletion
Serving RNC
RNSAP
RNSAP
RRC
RRC
UE
Node B
(Drift RNS)
Drift RNC
Decision to delete
old Radio Link
RNSAP
NBAP NBAP
NBAP NBAP
RNSAP
RRC
RRC
ALCAP Iur Bearer
Release
3. Radio Link
Deletion
4. Radio Link
Deletion
5. Radio Link
Response
6. Radio Link
Response
Deletion
5. ALCAP Iub Bearer
Release
1. DCCH: Active Set Update
[Radio Link Deletion]
2. DCCH: Active Set Update Complete
Stop RX and TX
Request
Request
Deletion


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
237
TED:UTRAN Common Appendix - Message Sequence Charts
Id:0900d80580118dce
6.11 Softer Handover - Radio Link Addition
Figure 149 MSC: Softer Handover - Radio Link Addition
NBAP NBAP
NBAP NBAP
RRC
RRC
1. Radio Link Addition Request
5. DCCH: Active Set Update (RL addition)
6. DCCH: Active Set Update Complete
Serving RNC
UE
Node B
RRC
RRC
2. Radio Link Addition Response
Decision to establish
new radio link
start receive (RX)
on new antenna
start transmission (TX)
on new antenna
NBAP NBAP
3. Radio Link Restore Indication


238 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dce
Appendix - Message Sequence Charts
6.12 Softer Handover - Radio Link Deletion
Figure 150 MSC: Softer Handover - Radio Link Deletion
NBAP NBAP
NBAP NBAP
RRC
3. Radio Link Deletion Request
1. DCCH: Active Set Update (RL deletion)
2. DCCH: Active Set Update Complete
CRNC
UE
Node B
RRC
RRC RRC
4. Radio Link Deletion Response
Decision to remove
old radio link
stop receive (RX)
on old antenna
& transmission (TX)


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
239
TED:UTRAN Common Appendix - Message Sequence Charts
Id:0900d80580118dce
6.13 Inter-Frequency Handover
Figure 151 MSC: Inter-Frequency Handover (Generic Procedure)
NBAP NBAP
NBAP NBAP
RRC
3. Radio Link Addition
6. DCCH: Physical Channel Reconfiguration
Serving RNC
UE
Node B
RRC
RRC
1. DCCH: Measurement Report
RRC
5. Radio Link Addition
Request
Response
4. Start RX new freq
7. Stop RX old freq
8. Start TX new freq
9. Layer1 Synchronisation
and Layer2 Link Established
9. Layer1 Synchronisation
and Layer2 Link Established
RRC
10. DCCH: Physical Channel Reconfiguration Complete
RRC
NBAP NBAP
11. Radio Link Deletion
Request
12. Stop TX old freq
NBAP NBAP
13. Radio Link Deletion
Response
2. Handover Decision


240 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dce
Appendix - Message Sequence Charts
6.14 IMSI Based Handover
Figure 152 MSC: IMSI Based Handover
RNC UE CN
RANAP
RANAP
RAB Assignment
IBHO Filtering
RANAP RANAP
RAB Assignment Response
Decision to trigger IBHO
RANAP RANAP
Command ID
RRC RRC
Measurement Control
RRC RRC
Measurement Report


A50016-G5000-H200-01-7618
ND-57282-708(E)-01
241
TED:UTRAN Common Appendix - Message Sequence Charts
Id:0900d80580118dce
6.15 Pre-emption
Figure 153 MSC: Pre-Emption (Overall Procedure)
Node B1 DRNC CRNC (SRNC) Node B2
RNSAP RADIO LINK RECONFIGURATION PREPARE
loop
(DCH allocation/retention priority)
The following two loops take place in parallel
per SRNC controlled RL
in the active set (Iub)
1
SRNC
Decision to perform RL
setup/addition/reconfiguration
CRNC RL pre-emption process
1
loop
per DRNC controlled RL
in the active set (Iur)
1
2 opt
2
RNSAP RADIO LINK SETUP REQUEST
(DCH allocation/retention priority)
2
RNSAP RADIO LINK ADDITION REQUEST
2
OPT1:
RL Reconfiguration
OPT2:
RL Setup
OPT3:
RL Addition
CRNC RL Pre-emption process
RNSAP RADIO LINK RECONFIGURATION READY
2 opt
2
RNSAP RADIO LINK SETUP RESPONSE
2
RNSAP RADIO LINK ADDITION RESPONSE
2
OPT1:
RL Reconfiguration
OPT3:
RL Addition
RNSAP RADIO LINK RECONFIGURATION COMMIT
OPT2:
RL Setup
1


242 A50016-G5000-H200-01-7618
ND-57282-708(E)-01
TED:UTRAN Common
Id:0900d80580118dce
Appendix - Message Sequence Charts
6.16 Cell Change Order
Figure 154 MSC: Cell Change Order (Successful Scenario Procedure)
Node B SGSN SRNC 2G-SGSN UE
RRC: MEASUREMENT REPORT
CONTEXT REQUEST
Cell_DCH and PS RAB only
(Event 3A)
RRC: CELL CHANGE ORDER FROM UTRAN
tCellChangeOrder
UE has changed RAT
ROUTING AREA UPDATE REQUEST
CONTEXT RESPONSE
CONTEXT ACKNOLEDGE
RANAP: IU RELEASE COMMAND
tCellChangeOrder
stopped
RANAP: IU RELEASE COMPLETE
ROUTING AREA UPDATE ACCEPTED
RANAP: CONTEXT REQUEST
RANAP: CONTEXT RESPONSE
NBAP: RADIO LINK DELETION
ALCAP: RELEASE
The SRNC confirms that no signaling
connection to the CS domain exists