LetsLearn3Gin10Days KamalVij

Let’s Learn
3G
in 10 Days
So Much to Learn...
So Little Time
EXPLOIT THE EVOLUTION
Written by Kamal Vij

Wires and Waves Solutions
Let’s take out 10 days and learn the essential concepts about 3G technology.
Let’s Learn 3G in 10 Days
written by
Kamal Vij
FOREWORD
The success story of GSM has generated a lot of motivation for businessmen, edu-
cational institutes, private consultants, legacy telecom operators, mobile operators,
equipment vendors and many more to master the fundamentals of 3G. It has been
13 years since the publication of the first 3G specification. It is no secret that 3G
(UMTS along with HSPA) has established itself as a successful and commercially
profitable mobile standard.
Telecom professionals keep on trying to search for the latest updates on the emerging
technologies. There are a lot of white papers, blogs, posters, and e-books available
on the Internet which help them in the learning but their busy schedule hardly
allows them to spend even a single hour per day to learn the updates of technology.
This was my motivation to write this book. In this book, the emphasis is on keeping
the language simple and focus on the essential concepts only. This book is not about
radio planning or RF optimization. Its sole purpose is to introduce the readers to
the 3G technology.
To get the maximum benefit out of this 10 days crash course with me, I recommend
you to follow the following plan:
DAY 1 History and Standardization: On the first day of reading, we will have
an ultra quick look at the history and very brief preview of the future. This
module or chapter will give us an overview about the legacy systems and their
migratory path to 3G and beyond. An the same time, we will also learn about
3GPP releases and their features.
2
DAY 2 Network Elements and Functionalities: The second day is planned
for learning about the network elements, interfaces, and to have a look at the
combined network architecture of 2G & 3G network.
DAY 3 WCDMA Air Interface: On the third day, we will focus on the radio
technology used in 3G system. In the third chapter, the principles of spreading
and code multiplexing are explained. We will also see the series of physical
layer procedures that take place at layer 1 of UE and Node B.
DAY 4 Logical, Transport & Physical Channels: On the fourth day, some
more physical layer aspects will be discussed when we will learn about the
channels of UMTS. In this module, we will focus on the UMTS channels only.
For HSDPA & HSUPA, separate modules are planned.
DAY 5 Radio Resource Management: The fifth day of our reading should fo-
cus on the RRM module, which discusses several features that work in parallel
to optimize the radio resource utilization.
DAY 6 Protocols & Interfaces: On the sixth day, topic of discussion will be
the protocols of UMTS. Along with radio protocols, we will also learn about
the control plane & user plane protocols on various UTRAN interfaces.
DAY 7 HSDPA: Release 5 onwards, the downlink speeds can be pushed beyond
2 Mbps. The seventh day is reserved for understanding the basics of HSDPA.
DAY 8 HSUPA: The project HSPA is completed only when both Uplink and
Downlink are High Speed. The eighth module of this book will discuss how
HSUPA differs from the conventional UMTS uplink.
DAY 9 Signalling: Towards the end of our journey, Module 9 is planned to dis-
cuss a few signalling scenarios. Here, we will discuss how a CS AMR call
and a PS data session gets established on UMTS & HSPA. Mobility related
signalling will also be illustrated, which plays an important role in service con-
tinuity and improves call success ratio.
3
DAY 10 Self Test: On the last day, I request all the readers to put themselves to
a self-evaluation and evaluate whether they have learnt something from this
book. 5 to 8 questions/exercises from each module are planned.
Please visit www.3gin10days.com to watch some video lessons related to these topics
and to download the e-book.
4
ABOUT THE AUTHOR
Kamal Vij received a B.Engg. degree in Electronics & Com-

munication from Kuvempu University, India in 2001. In 2005,
he received a M.Sc. degree in Communication Technology
from University of Bremen, Germany. While pursuing his
M.Sc., he took special interest in semiconductor simulation
and worked as a research assistant in the power electronics
department of University of Bremen. In 2006, he started his
career as a trainer for telecommunication. Since then, he has
been delivering trainings on WCDMA, HSPA & LTE Radio
Access Network technologies across the world.
Kamal Vij is now a technical trainer and private consultant.

He has keen interest in emerging technologies and following the market trends. His
skills are signalling, parameter optimization, radio planning and optimization. More
about him can be found at http://www.wiresandwaves.net and he can be reached
at: kamal.vij@wiresandwaves.net.
5
ACKNOWLEDGEMENTS
I, Kamal Vij, the author of this book, would like to thank 3GPP for being so
kind and allowing me to use their graphics, tables and text pieces in this book.
I also want to express my thankful regards to my friends working in the telecom
sector who have helped me in writing this book by giving me tips and ideas. My
biggest teachers are those telecom professionals whom I met while delivering the
classroom training. The discussions I had with them have enhanced my knowledge
and motivated me to work more passionately. I cannot mention all the names here
but a few colleagues and friends this group are Andreas Annen, Ashok Joshi, Andrey
Yaroshenko, Ilya Andreev, Jeetendra Ghare, Karl Hofmann, Kapil Bhutani, Michael
Oestreicher, Silviu Mihailescu, Jan Berglund, Ronald Fabian, Ravindra Mawale,
Saikat Nandi.
I also want to show my appreciation towards the authors of the following three
books. These books have been an excellent source of information for me. The Ideas
for many sections of this book were inspired from these books.
• H.Holma and A. Toskala, ‘WCDMA for UMTS’ , 5th Edition, John

Wiley & Sons.
• H.Holma and A. Toskala, ‘HSDPA/HSUPA for UMTS’ , 1st Edi-
tion, John Wiley & Sons.
• Chris Johnson, ‘Radio Access Networks For UMTS; Principles
And Practice’ , John Wiley & Sons.
I would like to thank ‘Zorba Publishers Pvt. Ltd.’ (www.zorbapublishers.com)
6
for meticulously proof reading this book and removing hundreds of typographic and
grammatical errors.
Above all, I want to thank my family, who supported and encouraged me in spite
of all the time it took me away from them. It was a long and difficult journey
for them. I apologize to all those who have been with me during my journey as a
telecom trainer and whose names I have failed to mention.
7
DISCLAIMER
The information contained in ‘Let’s Learn 3G in 10 Days’ is for general information

purposes only. The author has tried to simplify the explanation, and in that process
few complicated equations and rules have been dropped while maintaining the overall
correctness to the best of his knowledge. Every effort is made to keep the information
accurate. However, the author takes no responsibility for any damage caused by the
information obtained by this book.
Every care has been taken to mention the references and sources wherever needed.
This process has taken several months because references were added after the book
was written. Afterwards, it is a time-consuming and laborious task to recall all the
sources. The author has tried his best but at few places, he might have forgotten to
mention the source/reference due to human limitation. Author asks for forgiveness
if he has failed to declare the references in any part of the book.
8
CONTENTS
Preface 2
Preface 5
Acknowledgements 6
1 History and Standardization 2

1.1 Mobile Telecom Market . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 0G Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 1G Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.3 2G Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.4 3G Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3 3GPP and 3GPP2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.1 3rd Generation Partnership Project (3GPP) . . . . . . . . . . 14
1.3.2 3rd Generation Partnership Project 2 (3GPP2) . . . . . . . . 15
1.3.3 WiMAX as IMT-2000 System . . . . . . . . . . . . . . . . . . 17
9
1.4 WCDMA FDD - Releases . . . . . . . . . . . . . . . . . . . . . . . . 18
1.5 WCDMA FDD - Releases and Features . . . . . . . . . . . . . . . . . 19
2 Network Elements and Functionalities 25

2.1 Architecture of the GSM Network . . . . . . . . . . . . . . . . . . . . 26
2.1.1 The Mobile Station MS . . . . . . . . . . . . . . . . . . . . . . 27
2.1.2 Base Station Subsystem BSS . . . . . . . . . . . . . . . . . . . 27
2.1.3 Switching Subsystem . . . . . . . . . . . . . . . . . . . . . . . 28
2.2 Improvements of GSM Standard . . . . . . . . . . . . . . . . . . . . 32
2.2.1 CAMEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3 GPRS Network Architecture . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.1 GPRS Mobile Terminals . . . . . . . . . . . . . . . . . . . . . 36
2.3.2 GPRS Base Station Subsystem . . . . . . . . . . . . . . . . . 37
2.3.3 New Elements in the Core Network . . . . . . . . . . . . . . . 38
2.3.4 Other Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.3.5 GPRS Roaming Scenario . . . . . . . . . . . . . . . . . . . . . 41
2.4 Migration to 3G Network Architecture . . . . . . . . . . . . . . . . . 42
2.5 UTRAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.5.1 Node B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.5.2 RNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.6 Logical roles of RNC: S-RNC and D-RNC . . . . . . . . . . . . . . . 47
2.7 Release 4 Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.7.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.7.2 New Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.8.1 IP Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.8.2 IP Multimedia Subsystem (IMS) . . . . . . . . . . . . . . . . 55
2.9.1 IMS for IP-CAN or IMS phase 2 . . . . . . . . . . . . . . . . 57
2.10 Rel-7 & Rel-8 Modifications . . . . . . . . . . . . . . . . . . . . . . . 58
10
3 WCDMA Air Interface 62
3.1 Duplex Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.2 Multiple Access Technologies . . . . . . . . . . . . . . . . . . . . . . . 63
3.2.1 Frequency Division Multiple Access . . . . . . . . . . . . . . . 64
3.2.2 Time Division Multiple Access . . . . . . . . . . . . . . . . . . 65
3.2.3 Code Division Multiple Access . . . . . . . . . . . . . . . . . . 65
3.2.4 Orthogonal Frequency Division Multiple Access . . . . . . . . 65
3.3 UMTS operating Bands and Spectrum . . . . . . . . . . . . . . . . . 65
3.4 Timing in WCDMA . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.5 Spreading Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.6 Codes in UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.6.1 Channelization Code . . . . . . . . . . . . . . . . . . . . . . . 73
3.6.2 Scrambling Code . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.6.3 Summary of Scrambling Codes . . . . . . . . . . . . . . . . . 78
3.6.4 Summary of Codes in UMTS . . . . . . . . . . . . . . . . . . 78
3.7 Modulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4 Logical, Transport & Physical Channels 82

4.1 Chronology: First 3G and then 3.5G . . . . . . . . . . . . . . . . . . 83
4.2 Logical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.2.1 Logical Channels for Control Plane Information . . . . . . . . 84
4.2.2 Logical Channels for User Plane Information . . . . . . . . . 85
4.3 Transport Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.3.1 Common Transport Channels . . . . . . . . . . . . . . . . . . 87
4.3.2 Dedicated transport channels . . . . . . . . . . . . . . . . . . 88
4.4 Physical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.4.1 UL Common Channel . . . . . . . . . . . . . . . . . . . . . . 91
4.4.2 DL common Channel . . . . . . . . . . . . . . . . . . . . . . . 94
4.4.3 UL Dedicated Channels . . . . . . . . . . . . . . . . . . . . . 105
4.4.4 DL Dedicated Channels . . . . . . . . . . . . . . . . . . . . . 106
11
4.4.5 Summary of DCH Channels . . . . . . . . . . . . . . . . . . . 108
4.5 Cell Search Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4.6 HSDPA Channels in Short . . . . . . . . . . . . . . . . . . . . . . . . 111
4.7 HSUPA Channels in Short . . . . . . . . . . . . . . . . . . . . . . . . 113
5 Radio Resource Management 117

5.1 Inputs for RRM Functionality . . . . . . . . . . . . . . . . . . . . . . 119
5.1.1 RNC Parameter Database . . . . . . . . . . . . . . . . . . . . 120
5.1.2 Node B Measurements . . . . . . . . . . . . . . . . . . . . . . 121
5.1.3 UE Measurements . . . . . . . . . . . . . . . . . . . . . . . . 123
5.1.4 Internal RNC Measurements . . . . . . . . . . . . . . . . . . . 125
5.2 Load Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.2.1 Uplink Load Estimation . . . . . . . . . . . . . . . . . . . . . 126
5.2.2 Downlink Load Estimation . . . . . . . . . . . . . . . . . . . . 128
5.3 Radio Resource Management Strategies . . . . . . . . . . . . . . . . . 129
5.4 Admission Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
5.5 Code Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
5.5.1 Code Tree Optimization . . . . . . . . . . . . . . . . . . . . . 134
5.6 Packet Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
5.6.1 RRC States . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.6.2 RRC States Transitions . . . . . . . . . . . . . . . . . . . . . 141
5.7 Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
5.7.1 Open Loop Power Control . . . . . . . . . . . . . . . . . . . . 145
5.7.2 Inner Loop Power Control . . . . . . . . . . . . . . . . . . . . 146
5.7.3 Outer Loop Power Control . . . . . . . . . . . . . . . . . . . . 152
5.8 Handover Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
5.8.1 Active, Monitored and Detected cells . . . . . . . . . . . . . . 156
5.8.2 Soft/Softer Handover . . . . . . . . . . . . . . . . . . . . . . . 157
5.8.3 ISHO and IFHO Triggering . . . . . . . . . . . . . . . . . . . 162
5.8.4 Inter-Frequency Measurements . . . . . . . . . . . . . . . . . . 163
12
5.8.5 Inter-System Measurements . . . . . . . . . . . . . . . . . . . 164
5.8.6 Compressed Mode . . . . . . . . . . . . . . . . . . . . . . . . 165
5.8.7 Inter System HO Signalling . . . . . . . . . . . . . . . . . . . 166
6 Protocols & Interfaces 171

6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
6.1.1 Horizontal Layers . . . . . . . . . . . . . . . . . . . . . . . . . 173
6.1.2 Vertical Planes . . . . . . . . . . . . . . . . . . . . . . . . . . 173
6.2 QoS and Bearer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
6.2.1 UMTS QoS Classes . . . . . . . . . . . . . . . . . . . . . . . . 177
6.3 Access Stratum and Non-Access Stratum . . . . . . . . . . . . . . . . 178
6.4 Radio Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
6.4.1 Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
6.4.2 User Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
6.4.3 RRC-layer Functions . . . . . . . . . . . . . . . . . . . . . . . 182
6.4.4 RLC-layer Functions . . . . . . . . . . . . . . . . . . . . . . . 183
6.4.5 MAC-layer Functions . . . . . . . . . . . . . . . . . . . . . . . 185
6.4.6 PDCP-layer Functions . . . . . . . . . . . . . . . . . . . . . . 186
6.5 Iu-CS Interface Protocols . . . . . . . . . . . . . . . . . . . . . . . . . 187
6.5.1 Control Plane - Iu-CS . . . . . . . . . . . . . . . . . . . . . . 187
6.5.2 User Plane - Iu-CS . . . . . . . . . . . . . . . . . . . . . . . . 187
6.5.3 RANAP Functions . . . . . . . . . . . . . . . . . . . . . . . . 189
6.6 Iu-PS Interface Protocols . . . . . . . . . . . . . . . . . . . . . . . . . 190
6.6.1 Control Plane - Iu-PS . . . . . . . . . . . . . . . . . . . . . . 190
6.6.2 User Plane - Iu-PS . . . . . . . . . . . . . . . . . . . . . . . . 190
6.7 Iub Interface Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 192
6.7.1 Control Plane - Iub CP . . . . . . . . . . . . . . . . . . . . . . 192
6.7.2 User Plane - Iub UP . . . . . . . . . . . . . . . . . . . . . . . 193
6.7.3 NBAP Functions . . . . . . . . . . . . . . . . . . . . . . . . . 193
6.8 Iur Interface Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 195
13
6.8.1 Control Plane - Iur CP . . . . . . . . . . . . . . . . . . . . . . 195
6.8.2 User Plane - Iur UP . . . . . . . . . . . . . . . . . . . . . . . 195
6.8.3 RNSAP functions . . . . . . . . . . . . . . . . . . . . . . . . . 195
6.9 Non-Access Stratum Protocols . . . . . . . . . . . . . . . . . . . . . . 198
7 High Speed Downlink Packet Access 204

7.1 Why HSDPA? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
7.2 HSDPA Standardization, 3GPP Releases and Evolution . . . . . . . . 205
7.2.1 Release 99 & Rel-4 . . . . . . . . . . . . . . . . . . . . . . . . 206
7.2.2 Release 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
7.2.3 Release 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
7.2.4 Release 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
7.2.5 Release 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
7.3 HSDPA Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
7.3.1 HSDPA Operation: Between UE and RNC . . . . . . . . . . . 208
7.3.2 HSDPA Operation: Between Node B and RNC . . . . . . . . 209
7.4 What’s new in HSDPA? . . . . . . . . . . . . . . . . . . . . . . . . . 211
7.4.1 Adaptive Modulation & Coding . . . . . . . . . . . . . . . . . 211
7.4.2 Shorter and Fixed TTI . . . . . . . . . . . . . . . . . . . . . . 211
7.4.3 Node B-based Packet Scheduling . . . . . . . . . . . . . . . . 212
7.4.4 Multi-code Operation . . . . . . . . . . . . . . . . . . . . . . . 213
7.4.5 L1 H-ARQ Retransmission . . . . . . . . . . . . . . . . . . . . 217
7.4.6 MAC-hs Protocol in Node B and UE . . . . . . . . . . . . . . 218
7.4.7 Serving Cell Change Instead of Soft HO . . . . . . . . . . . . 219
7.5 HSDPA Protocol Architecture . . . . . . . . . . . . . . . . . . . . . . 221
7.5.1 MAC-hs entity - UE Side . . . . . . . . . . . . . . . . . . . . . 221
7.5.2 MAC-hs entity - UTRAN Side . . . . . . . . . . . . . . . . . . 224
7.6 Channels and Physical Layer . . . . . . . . . . . . . . . . . . . . . . . 226
7.6.1 HS-DPCCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
7.6.2 HS-SCCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
14
7.6.3 HS-PDSCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
7.6.4 Associated DCH . . . . . . . . . . . . . . . . . . . . . . . . . 233
7.6.5 Fractional-DPCH . . . . . . . . . . . . . . . . . . . . . . . . . 234
7.7 Timing of HSDPA Channels . . . . . . . . . . . . . . . . . . . . . . . 235
7.8 HSDPA UE Categories . . . . . . . . . . . . . . . . . . . . . . . . . . 236
7.9 HSDPA Peak Bitrate Calculation . . . . . . . . . . . . . . . . . . . . 237
7.10 Serving HS-DSCH Cell Change . . . . . . . . . . . . . . . . . . . . . 239
7.11 Summary: HSDPA Operation in Short . . . . . . . . . . . . . . . . . 241
8 High Speed Uplink Packet Access 245

8.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
8.2 Comparison with HSDPA . . . . . . . . . . . . . . . . . . . . . . . . 247
8.2.1 Commonalities with HSDPA . . . . . . . . . . . . . . . . . . . 247
8.2.2 Differences from HSDPA . . . . . . . . . . . . . . . . . . . . . 248
8.3 HSUPA User Plane Protocols . . . . . . . . . . . . . . . . . . . . . . 248
8.4 HSUPA Configuration Options . . . . . . . . . . . . . . . . . . . . . . 250
8.5 E-DCH UE Categories and Bit Rates . . . . . . . . . . . . . . . . . . 251
8.6 Starting of HSUPA Operation . . . . . . . . . . . . . . . . . . . . . . 253
8.7 HSUPA Protocol Architecture . . . . . . . . . . . . . . . . . . . . . . 254
8.8 Channels and Physical Layer . . . . . . . . . . . . . . . . . . . . . . . 260
8.8.1 E-DPDCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
8.8.2 E-DPCCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
8.8.3 E-AGCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
8.8.4 E-RGCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
8.8.5 E-HICH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
8.8.6 F-DPCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
8.9 Summary: Serving and Non-serving RLS . . . . . . . . . . . . . . . . 273
8.10 E-TFC Selection Procedure . . . . . . . . . . . . . . . . . . . . . . . 276
8.10.1 Step 1: UE sends Scheduling Requests to Node B . . . . . . . 276
8.10.2 Step 2: Serving Grant Value . . . . . . . . . . . . . . . . . . . 277
15
8.10.3 Step 3: Find Power Offset . . . . . . . . . . . . . . . . . . . . 278
8.10.4 Step 4: “Reference E-TFCI & Power Offset” Curve . . . . . . 278
8.10.5 Step 5: Calculate E-TFCI Allowed by Grant Value . . . . . . 278
8.10.6 Step 6: Calculate TB Size . . . . . . . . . . . . . . . . . . . . 278
8.10.7 Step 7: Select Channelization Code & L1 Parameters . . . . . 279
8.10.8 Step 8: UL Transmission on E-DCH . . . . . . . . . . . . . . 280
8.10.9 Step 9: Feedback from Node B on E-HICH . . . . . . . . . . 281
8.10.10 Step 10: Feedback from Node B on E-RGCH . . . . . . . . . . 282
8.11 Summary: HSUPA Operation in Short . . . . . . . . . . . . . . . . . 283
8.12 UL Channelization Codes . . . . . . . . . . . . . . . . . . . . . . . . 288
8.13 DL Channelization Codes . . . . . . . . . . . . . . . . . . . . . . . . 291
8.13.1 R99 DL Channels . . . . . . . . . . . . . . . . . . . . . . . . . 291
8.13.2 HSDPA-related DL Channels . . . . . . . . . . . . . . . . . . 292
8.13.3 HSUPA Related DL Channels . . . . . . . . . . . . . . . . . . 292
9 Signalling 295
9.1 Building Blocks of 3G Signalling . . . . . . . . . . . . . . . . . . . . . 296
9.1.1 RRC Connection . . . . . . . . . . . . . . . . . . . . . . . . . 296
9.1.2 Radio Access Bearer (RAB) . . . . . . . . . . . . . . . . . . . 298
9.1.3 Radio Bearer . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
9.1.4 Radio Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
9.1.5 Non-Access Stratum (NAS) Signalling Connection . . . . . . . 301
9.2 RRC Connection Establishment . . . . . . . . . . . . . . . . . . . . . 302
9.2.1 RRC Connection on Dedicated Channels - DCH . . . . . . . . 302
9.2.2 RRC Connection on Common Channels - FACH/RACH . . . 304
9.3 Mobile Originated Voice Call Establishment . . . . . . . . . . . . . . 306
9.4 Mobile Terminated Voice Call Establishment . . . . . . . . . . . . . . 310
9.5 PS Data Session Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 314
9.6 Soft Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
9.7 Inter-RNC Handover with Iur Interface . . . . . . . . . . . . . . . . . 323
16
1
9.8 Inter-RNC Handover without Iur Interface . . . . . . . . . . . . . . . 326

9.9 CS Inter-System Handover (3G to 2G) . . . . . . . . . . . . . . . . . 329
9.10 PS Inter-System Handover (3G to 2G) . . . . . . . . . . . . . . . . . 335
9.11 HSDPA Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
9.11.1 Serving HS-DSCH Cell Change . . . . . . . . . . . . . . . . . 338
9.11.2 HS-DSCH Channel Type Switch . . . . . . . . . . . . . . . . . 342
9.11.3 HS-DSCH IFHO and ISHO . . . . . . . . . . . . . . . . . . . 343
9.12 HSUPA Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
9.12.1 E-DCH Soft Handover . . . . . . . . . . . . . . . . . . . . . . 345
9.12.2 E-DCH Serving Cell Change . . . . . . . . . . . . . . . . . . . 345
9.12.3 E-DCH Channel Type Switch . . . . . . . . . . . . . . . . . . 345
9.12.4 E-DCH IFHO and ISHO . . . . . . . . . . . . . . . . . . . . . 347
10 Self Test 351

10.1 Module 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
10.2 Module 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
10.3 Module 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
10.4 Module 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
10.5 Module 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
10.6 Module 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
10.7 Module 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
10.8 Module 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
10.9 Module 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
CHAPTER
HISTORY AND STANDARDIZATION
We have come a long way. GSM made it possible to leave the office and yet
answer the phone calls, 3G did the same for the e-mails, and SMS still creates
wonders despite its tiny size.
If you have decided to read this book, you are definitely involved with the mobile
communication industry and it is quite possible that at least once someone has asked
you “What is 3G ? ”. Especially after hearing the words iPhone 3G & 3GS, even
non-technical people have started wondering what exactly is 3G. In this chapter, we
will try to find the answer to this question and have a look at the evolutionary path
taken by 3G.
1.1 Mobile Telecom Market

Source:
Informa Telecoms & Media
http://www.4gamericas.org/
The statistics from the 4th Quarter 20121 show that 90% of the mobile subscriptions
in the world are using GSM, UMTS & HSPA Systems. Figure 1.1 is taken from
1
Source: Informa Telecoms & Media & http://www.4gamericas.org/
2
1.2. HISTORY 3
www.4gamericas.com, which contains a lot of interesting details about the present

telecom market. Among all the cellular systems, GSM has been the most successful
technology and due to affordable handsets and the importance of voice service, it
will continue to remain the leading technology for the coming years as well.
When UMTS was developed as the 3G system, the 3G-2G interworking was planned
so that the investments of GSM could be reused and 3G cost of ownership could be
reduced. Even today, 2G provides a coverage safety belt to 3G. When subscribers
run into 3G coverage holes, then they can use the 2G systems. Similarly, when
the 2G load increases, 3G can provide some load-sharing possibility for the smooth
operation of 2G cell.
Figure 1.1: Mobile market in Q4 2012; source: Informa Telecoms & Media
1.2 History
Nowadays, the word mobile phone is a synonym of cellular phones. In some coun-
tries2 , the mobile phones are called handy. But there was a time when mobile phones
were neither handy nor cellular. Those commercial mobile systems can be called as
0G or Single Cell Systems.
2
e.g., in Germany
4 CHAPTER 1. HISTORY AND STANDARDIZATION
1.2.1 0G Systems
0G Systems are called so because they were the predecessors of the first generation
(1G) modern cellular communication systems. They were planned to serve a very
large geographical area using a very high base station. Due to this huge distance,
mobile was required to transmit at a very high transmit power, and it needed a bulky
battery to make it possible. Therefore, the tranmitters/receivers of these phones
were typically mounted on the top of vehicles and the handset was fitted close to
the driver’s seat. Because of the huge cost of equipment and service operation, this
could be used only by very few groups of people, e.g., celebrities, politicians and
construction managers.
For operators: These systems were not a profitable technology because each fre-
quency could be used only once in a very large geographical area.
For Users: Cost of service and user equipment was so high that the common man
did not feel the need of using this service.
Both of the points listed above stopped the growth of 0G systems and these remained
as low-subscriber system.
1.2.2 1G Systems
First-generation mobile systems were a big revolution. In 1G systems, for the first
time, we divided the coverage areas into cells and hence started the history of the
modern cellular mobile communication system. 1G systems could also be called
as analog3 mobile phone systems because they used analog transmission for speech
services.
In 1979, the first cellular system in the world became operational by Nippon Tele-
phone and Telegraph (NTT) in Tokyo, Japan. Two years later, the cellular epoch
reached Europe. The two most popular analogue systems were Nordic Mobile Tele-
phones (NMT) and Total Access Communication Systems (TACS). In 1981, the
NMT-450 system was commercialized by NMT in Scandinavia. The system oper-
ated in the 450 MHz and 900 MHz band with a total bandwidth of 10 MHz.
Advanced Mobile Phone System (AMPS) was an analog mobile phone system stan-
dard developed by Bell Labs, and officially introduced in the Americas in 1983.
TACS, launched in the United Kingdom in 1982, operated at 900 MHz with a band
of 25 MHz for each path and a channel bandwidth of 25 KHz. Other than NMT
3
Analog: Amplitude Modulation, Frequency Modulation, Phase Modulation
1.2. HISTORY 5
and TACS, some other analogue systems were also introduced in the 1980s across
Europe. For example, in Germany, the C-450 cellular system, operating at 450 MHz
and 900 MHz (later) was deployed in September in 1985.
All of these systems offered handover and roaming capabilities but the cellular net-
works were unable to inter-operate between countries. This was one of the inevitable
disadvantages of the first-generation mobile networks. Other than being just the lo-
cal & region-specific systems, these systems also had some other disadvantages:
Security: Analog speech was transmitted without any encryption.
Quality: Transmission errors were not so easy to correct because it was very difficult
to reconstruct exactly the same analog signal.
Capacity: Analog speech cannot be compressed. Therefore, 1G radio transmission

requires a lot of bandwidth. This causes network congestion for the operator
and expensive operation for the subscriber.
With the introduction of 1G phones, the mobile market showed some growth and
the number of subscribers reached 20 million by 1990. But still, to own a mobile
phone was a luxury and only a few people could afford it.
1.2.3 2G Systems
Just like 1G, every region had its own local 2G standards as well. For example, in
the USA, 1G AMPS was upgraded to digital AMPS (D-AMPS), in the USA itself, a
CDMA based IS-95 2G network was launched. Japan developed its own 2G system
called Personal Digital Cellular (PDC). PDC is a TDMA-based technology that is
deployed only in Japan. Among all 2G systems, one system that made the largest
impact on our lives is Global System for Mobile communication (GSM). The second-
generation (2G) mobile systems were introduced in the early 1990s. Low bit rate
data services were supported as well as the traditional speech service.
Development of GSM in Europe
But in Europe, there was a growing demand of a common standard which should
work in the major part of Europe. To fulfil this need, in 1982 a group was formed,
which is knows as Groupe Speciale Mobile (GSM)4 . This group was formed by
4
This was the original name of GSM. Later it was changed to Global System of Mobile Com-
munications
the Confederation of European Posts and Telecommunications (CEPT) to design a

pan-European mobile technology. In coming years, the European Commission and
European Union heads of states endorsed the GSM project. The GSM project was
started as a European initiative but soon the non-European operators also started
endorsing it. In fact, the GSM has been more successful than the most optimistic
forecast ever made for it. For example, the number of GSM subscribers reached
the 1 Million mark in 1994, 10 million in 1995, 50 million in 1996 and in 1998 the
number reached 100 million mark. In 1998, there were more than 100 countries
which were using GSM. A more detailed description of the events can be found at
http://www.gsma.com/aboutus/history/.
On technical aspects also, the second-generation mobile systems were a big enhance-
ment which fulfilled many shortcomings of 1G analog systems. One remarkable
aspect of 2G systems is that they all utilize digital 5 modulation.
In a digital system, the analog speech signal passes through an analog-to-digital
converter and the digitized signal is fed to the modulator. When compared to the
first-generation systems, 2G systems are able to achieve:
• higher spectrum efficiency due to modern speech codecs
• (encrypted) secure radio transmission
• better quality by using an error-correction scheme (channel coding)
• better data services
• more advanced roaming
Three 2G Standards of USA
In the United States, there were three lines of development in the second-generation
digital cellular systems.
1. The first digital system, introduced in 1991, was the IS-54 (North America
TDMA Digital Cellular) of which a new version supporting additional services
(IS-136) was introduced in 1996.
2. Meanwhile, IS-95 (cdmaOne) was deployed in 1993. In many regions of the

world, it is called 2G CDMA.
5
Digital: Amplitude Shift Keying, Frequency Shift Keying, Phase Shift Keying
1.2. HISTORY 7
Figure 1.2: Commercially deployed Mobile Communication Systems of the 3GPP

Family
3. The US Federal Communications Commission (FCC) also auctioned a new

block of spectrum in the 1900 MHz band (PCS), allowing GSM1900 to enter
the US market.
In Japan, the Personal Digital Cellular (PDC) system, originally known as JDC
(Japanese Digital Cellular) was initially defined in 1990. Commercial service was
started by NTT in 1993 in the 800 MHz band and in 1994 in the 1.5 GHz band.
GSM and its Evolution
GSM has emerged as a single, unified 2G standard operating in more than 200 coun-
tries. This enabled seamless services throughout Europe by means of international
roaming. The earliest GSM system operated in the 900 MHz frequency band. Later,
GSM specifications for 1800 & 1900 MHz bands were released. During development
over more than 20 years, the GSM technology has been continuously improved to
offer better services in the market. New technologies have been developed based
on the original GSM system, leading to some more advanced systems known as 2.5
Generation (2.5G) systems.

HSCSD, GPRS and EDGE are all based on the original GSM system.
High Speed Circuit Switched Data (HSCSD)
HSCSD is the first enhancement of the GSM air interface. The new features included
in HSCSD are illustrated in figure 1.3, These 2 features are:
1. The new channel coding used in HSCSD yields 14.4 kbps user data per time
slot.
2. For high bit rates, several time slots could be bundled and allocated to the
same user.
HSCSD bundles GSM time slots to give a theoretical maximum data rate of 57.6
kbit/s (bundling 4 X 14.4 kbit/s full rate time slots). HSCSD provides both sym-
metric and asymmetric services and it is relatively easy to deploy. However, HSCSD
is not easy to price competitively since each time slot is effectively a GSM channel.
Figure 1.3: HSCSD compared with GSM

1.2. HISTORY 9
General Packet Radio Service
Following HSCSD, GPRS is the next step of the evolution of the GSM air inter-
face. Other than bundling timeslots, 4 new channel coding schemes are proposed.
GPRS provides always-on packet-switched services with bandwidth only being used
when needed. Therefore, GPRS enables GSM with Internet access at high spectrum
efficiency by sharing time slots between different users. Theoretically, GPRS can
support data rate up to 160 kbit/s (current commercial GPRS provides 40 kbit/s).
Deploying GPRS is not as simple as HSCSD because the core network needs to be
upgraded as well.
General Packet Radio Service (GPRS) provides packet data radio access for GSM
mobile phones. On a general level, GPRS connections use the resources only for a
short period of time when sending or receiving data:
• In a circuit-switched system, the line is occupied even when no data is trans-

ferred.
• In a packet-switched system, the resources are released so they can be used by

other subscribers.
GPRS is, therefore, well adapted to the bursty nature of data applications. GPRS
has minimal effects on the handling of circuit switched calls but the inter-operability
of existing circuit switched functionalities needs to be taken into account.
An investment in the GPRS infrastructure is an investment in future services. GPRS
paves the way and is already part of the third generation (3G) network infrastruc-
ture. Migration to 3G comprises deployment of the new WCDMA radio interface
served by the GSM and GPRS core networks. Many of the 3G services are based
on IP, and the GPRS Core network is the key step of introducing the IP service
platform into the present GSM networks.
When migrating to 3G services, preserving the Core Network investments is a top
priority. Introducing UMTS will complement the GSM network, not replace it.
Enhanced Data Rates for GSM Evolution
Enhanced Data rates for GSM Evolution (EDGE) boosts GSM/GPRS network ca-
pacity and data rates to meet the demands of wireless multimedia applications and
mass market deployment. EDGE uses the GSM radio structure but with a new
modulation scheme, 8-PSK, instead of GMSK, thereby increasing by three times
the GSM throughput using the same bandwidth. A quick summary of EDGE tech-
nology can be found in figure 1.5.
Figure 1.4: GPRS improvements for higher bit rates
With the new modulation, EDGE increases the radio interface data throughput, as
per 3GPP standardization, three-fold compared to today’s GSM and boosts both
circuit switched and packet switched services. The maximum standardized data rate
per timeslot will triple, and the peak throughput, with eight time slots in the radio
interface, can be up to 473 kbit/s. Since it is fully based on GSM, introducing EDGE
to the existing network requires relatively small changes to the network hardware
and software. EDGE does not entail any new network elements6 . The operators
need not make any changes to the network structure or invest in new regulatory
licenses.
EDGE, in combination with GPRS, will deliver single user data rates of up to 384
kbit/s.
EDGE or E-GPRS supports higher data rates compared to basic GPRS, using sev-
eral Modulation and Coding Schemes (MCSs) varying from 8.8 kbit/s to 59.2 kbit/s
in the radio interface. Nine different MCS schemes are designed for EGPRS. When
an RLC data block is sent, the information is encoded using one of the MCSs to resist
6
Compared to GPRS network architecture, the EDGE network does not need any additional
network element.
1.2. HISTORY 11
Figure 1.5: Summary of EDGE Technology
8-PSK GMSK
Modulation 8-PSK, 3 bit/sym GMSK, 1 bit/sym
Symbol rate 270.833 ksps 270.833 ksps
Payload/burst 346 bits 116 bits
Gross rate/time slot 69.6 kbit/s 23.2 kbit/s
Table 1.1: Comparison of 8-PSK and GMSK modulation schemes
channel degradation and modulated before transmission over the radio interface.
Since the resources are limited, the higher the level of protection for information,
the less information is sent. The protection that best fits the channel condition is
chosen for a maximum throughput. The GMSK modulation provides a robust mode
for wide area coverage while 8PSK provides higher data rates.
1.2.4 3G Systems
The idea of next generation mobile network was first conceived by ITU and was
called IMT-2000. IMT-2000 is the result of collaboration of many entities, inside
the ITU (ITU-R and ITU-T), and outside the ITU (3GPP, 3GPP2, UWCC and so
MCS Modulation Code Rate User Rate

MCS-1 0.53 8.8 kbps
MCS-2 0.66 11.2 kbps
GMSK
MCS-3 0.80 14.8 kbps
MCS-4 1.0 17.6 kbps
MCS-5 0.37 22.4 kbps
MCS-6 0.49 29.6 kbps
MCS-7 8-PSK 0.76 44.8 kbps
MCS-8 0.92 54.4 kbps
MCS-9 1.0 59.2 kbps
Table 1.2: Peak data rates for E-GPRS Modulation and Coding Schemes
on).
As shown in figure 1.6, the vision of ITU for its next generation system was some-
thing like this.
Quoted word-by-word,
Source: http://www.itu.int/osg/spu/imt-2000/technology.html
IMT-2000 offers the capability of providing value-added services and applica-

tions on the basis of a single standard. The system envisages a platform for
distributing converged fixed, mobile, voice, data, Internet and multimedia ser-
vices. One of its key visions is to provide seamless global roaming, enabling
users to move across borders while using the same number and handset. IMT-
2000 also aims to provide seamless delivery of services, over a number of media
(satellite, fixed, etc). It is expected that IMT-2000 will provide higher trans-
mission rates: a minimum speed of 2 Mbit/s for stationary or walking users,
and 348 kbit/s in a moving vehicle. Second-generation systems only provide
speeds ranging from 9.6 kbit/s to 28.8 kbit/s.
When ITU defined the requirements of its next generation mobile system, several
standards development organizations started working on finding solutions to fulfill
those requirements in the easiest and most cost-effective manner. A few well known
organizations in this race were European Telecommunications Standards Institute
(ETSI), Telecommunications Technology Association, Korea, Association of Radio
Industries and Businesses, Japan etc.
As a part of the roadmap, July 1998 was accepted as the deadline for submission of
proposals for IMT-2000 by the regional standardization development organizations.
1.3. 3GPP AND 3GPP2 13
Third-generation (3G) systems promise faster communications services, including

voice, fax and Internet, anytime and anywhere with seamless global roaming. ITU’s
International Telecommunication Union IMT-2000 global standard for 3G has opened
the way to enabling innovative applications and services (e.g. multimedia entertain-
ment, infotainment and location-based services, among others).
Figure 1.6: ITU’s vision of IMT-2000
The terrestrial radio transmission technologies proposed to ITU in July 1998 in-
cluded a number of different Wideband CDMA (WCDMA) based radio access tech-
nologies, which can be grouped into two types.
Synchronous: These type of proposals requires synchronized base stations.

These proposals were built on the IS-95 2G radio transmission technology
(e.g., TD-SCDMA).
Non-Synchronous: The other group of concepts does not rely on base station
synchronization (e.g., WCDMA).
1.3 3GPP and 3GPP2

By the end of 1998, two specification development projects were founded by the
regional standardization organizations, 3GPP (3rd Generation Partnership Project)
and 3GPP2. The goal of both 3GPP and 3GPP2 was to merge a number of the
IMT-2000 proposals into a single one, see figure 1.7.
3GPP: 3GPP includes the organizations which are working on evolving GSM to-
wards 3G standards and beyond. 3GPP is responsible for the standardization
of GSM, GPRS, UMTS, HSPA & LTE.
3GPP2: 3GPP2 includes the organizations which are working on evolving IS-95
(2G CDMA) towards 3G standards. 3GPP2 is responsible for the standard-
ization of CDMA2000 1X, CDMA200 EV-DO Rev. A/B/C.
1.3.1 3rd Generation Partnership Project (3GPP)

Source: http://3gpp.org/Partners
http://3gpp.org/About-3GPP
The 3rd Generation Partnership Project (3GPP) unites six telecommunications stan-
dards bodies, known as Organizational Partners and provides their members with a
stable environment to produce the highly successful Reports and Specifications that
define 3GPP technologies.
The six 3GPP Organizational Partners - from Asia, Europe and North America -
determine the general policy and strategy of 3GPP.
ARIB The Association of Radio Industries and Businesses, Japan
CCSA China Communications Standards Association, China
TTA Telecommunications Technology Association, Korea
TTC Telecommunication Technology Committee, Japan
ETSI The European Telecommunications Standards Institute
ATIS The Alliance for Telecommunications Industry Solutions, USA
Other than these, 3GPP currently has three Observers. Observers are Standards
Development Organizations (SDOs) who have the qualifications to become future
Organizational Partners.
TIA Telecommunications Industries Association, USA

ISACC ICT Standards Advisory Council of Canada, Canada
ACIF Communications Alliance - former Australian Communications Industry Fo-

rum, Australia
Additionally, 3GPP has also members who have the ability to offer market advice
to 3GPP and to bring into 3GPP a consensus view of market requirements falling
within the 3GPP scope; but does not have the capability and authority to define,
publish and set standards within the 3GPP scope. These partners are called ‘Market
Representation Partners’.
3GPP has several market representative partners, which are IMS Forum, TD-
Forum, GSA, GSM Association, IPV6 Forum, UMTS Forum, 4G Amer-
icas, TD SCDMA Industry Alliance, InfoCommunication Union, Small
Cell Forum, CDMA Development Group, Cellular Operators Association
of India (COAI) and NGMN Alliance.
1.3.2 3rd Generation Partnership Project 2 (3GPP2)
Source: http://www.3gpp2.com/Public html/Misc/AboutHome.cfm
The Third Generation Partnership Project 2 (3GPP2) is also a collaborative effort

among 5 North American and Asian standards development organizations whose
aim is to develop the specifications for ANSI/TIA/EIA-41 Cellular Radio telecom-
munication Intersystem Operations network evolution to 3G. 3GPP2 is responsible
for standardization of cdma2000 and its future evolutions.
Similar to 3GPP, 3GPP2 also has organizational partners, which are:
ARIB The Association of Radio Industries and Businesses, Japan7
CCSA China Communications Standards Association, China
TTA Telecommunications Technology Association, Korea
TTC Telecommunication Technology Committee, Japan
TIA Telecommunications Industry Association, USA

7
ARIB, CCSA, TTA & TTC organizations are partners in both 3GPP and 3GPP2.
3GPP2 also has market representation partners which have the ability to offer mar-
ket advice to 3GPP2 and to bring into 3GPP2 a consensus view of market re-
quirements falling within the 3GPP2 scope. There are 4 market representatives
of 3GPP2: CDMA Development Group (CDG), IPv6 Forum, Small Cell
Forum, CDMA Certification Forum.
Figure 1.7: Standards Development Organizations responsible for forming 3GPP

& 3GPP2
List of all IMT-2000 Systems
The purpose of this section is to show the complete picture of 3G. In the
whole book, we will discuss only WCDMA FDD (officially called as IMT-2000
CDMA Direct Spectrum).
For someone living in Europe, 3G, WCDMA and UMTS are synonyms. But if we
analyze carefully, it is not correct. According to ITU’s Recommendation ITU-R
M.1457, there were 5 systems recommended for terrestrial radio interfaces of IMT-
2000.
Source: ITU’s Recommendation ITU-R M.1457
1. IMT-2000 CDMA Direct Spread: The IMT-2000 radio-interface specifica-

tions for CDMA Direct Spread technology are developed by 3GPP. This radio
interface is called Universal Terrestrial Radio Access (UTRA) FDD or Wide-

band CDMA (WCDMA). In the development of this radio interface, the CN
specifications are based on an evolved GSM-MAP. However, the specifications
include the necessary capabilities for operation with an evolved ANSI-41-based
CN.
2. IMT-2000 CDMA Multi-Carrier: The IMT-2000 radio interface specifica-
tions for CDMA multi-carrier (MC) technology are developed by 3GPP2. This
radio interface is called cdma2000. In the development of this radio interface
the CN specifications are based on an evolved ANSI-41 and IP network, but the
specifications include the necessary capabilities for operation with an evolved
GSM-MAP based CN, a CN based on IETF protocols, or the 3GPP Evolved
Packet Core (EPC).
3. IMT-2000 CDMA TDD: The IMT-2000 radio interface specifications for CDMA
TDD technology are developed by 3GPP. This radio interface is called the Uni-
versal Terrestrial Radio Access (UTRA) time division duplex (TDD), where
three options are defined:
• 1.28 Mchip/s TDD (TD-SCDMA)

• 3.84 Mchip/s TDD
• 7.68 Mchip/s TDD
4. IMT-2000 TDMA Single-Carrier: The IMT-2000 TDMA Single-Carrier ra-

dio interface specifications contain two variations depending on:
• whether a TIA/EIA-41 circuit switched network component is used, or
• a GSM evolved UMTS circuit switched network component is used.
In either case, a common enhanced GSM General Packet Radio Service (GPRS)
packet switched network component is used. The initial focus of the following
sections has been to provide an evolution path for the TIA/EIA-136 pre-IMT-
2000 radio interface to evolve to IMT-2000.
5. IMT-2000 FDMA/TDMA: The IMT-2000 radio interface specifications for
FDMA/TDMA technology are defined by a set of ETSI standards. This radio
interface is called digital enhanced cordless telecommunications (DECT).
1.3.3 WiMAX as IMT-2000 System

In 2007, WiMAX was also accepted as a new member of IMT-2000 family with the
official name of IMT-2000 OFDMA TDD WMAN. WiMAX (designated as IEEE
Std 802.16) is developed and maintained by the IEEE 802.16 Working Group on
Broadband Wireless Access. It is published by the IEEE Standards Association
(IEEE-SA) of the Institute of Electrical and Electronics Engineers (IEEE).
1.4 WCDMA FDD - Releases

Source: http://3gpp.org/Releases
Before 3G, the standardization work of GSM and GPRS was done by ETSI. From
R99 onwards, ETSI is one of the bodies in the collaboration of 3GPP. Hence, after
R99, we always talk about 3GPP releases instead of ETSI releases.
Table 1.3 shows the dates on which various 3GPP releases were standardized and
frozen. According to 3GPP, after freezing, a release can have no further additional
functions added. However, detailed protocol specifications (stage 3) may not yet be
complete.
Release Freezing Date
Ph 1 1992
Ph 2 1995
R96 Early 1997
R97 Early 1998
R98 Early 1999
R99 March 2000
Rel-4 March 2001
Rel-5 March - June 2002
Rel-6 December 2004 - March 2005
Rel-7 Stage 3 freeze December 2007
Rel-10 Stage 3 freeze March 2011
Table 1.3: 3GPP releases of WCDMA and their freezing dates
In some of the releases, dates are mentioned according to the stages (stage 1, 2, 3).
The term stage has following meaning:
“Stage 1” refers to the service description from a service-users point of view.

“Stage 2” is a logical analysis, breaking the problem down into functional elements
and the information flows amongst them across reference points between func-
tional entities.
1.5. WCDMA FDD - RELEASES AND FEATURES 19
“Stage 3” is the concrete implementation of the protocols appearing at physical

interfaces between physical elements onto which the functional elements have
been mapped.
1.5 WCDMA FDD - Releases and Features

Before we discuss the details of each 3GPP release and the corresponding features, let
us have a quick look at the bit rates offered by various 2G and 3G technologies. Table
1.4 shows both numbers, one which are mentioned in the technology description and
the others which are commercially used in practice. It is expected that HSDPA will
bridge the gap between theoretical and practical numbers and hence, the mobile
operators will feel transparency in the system operation and description.
System GSM GPRS EDGE UMTS HSDPA

Typical Max Bitrate(Kbps) 9.6 50 150 384 14400
Theoretical Max Bitrate(Kbps) 9.6 171 384 2048 14400
Table 1.4: Maximum bit rates of various technologies
Figure 1.8: Mobile Evolution from 2G to 4G
Release 99 or Rel-99: In December 1999, the first UMTS Release, the so-called
‘Release 99’ was frozen. UMTS Rel-99 is based on the large experience of
GSM,GPRS standardization, taking over many principles of the matured GSM,
GPRS network, protocol and service architecture.
• Mature GSM/GPRS Core network

• New Air IF technology (WCDMA)

• New radio network (UTRAN)
• bit rates up to 384 kbps8
Rel-99 was the start of 3G. The highlights of R99 was a CDMA based radio
access network (UTRAN) and the new interfaces which connect UTRAN to
the existing GSM/GPRS core network. Rel. 99 specifies that transmission
technology on these interfaces should be ATM9 .
REL-4 Continuing the 3GPP evolution, Release 4 enhanced UMTS via several
features, e.g.:
• Bearer independent CS Core Network

• CAMEL CAMEL Phase 4
• Low chip rate TDD mode
• Transcoder Free Operation
There was no major enhancement to the UTRAN in Rel-4. Therefore, the bit
rates of R99 and Rel-4 are identical. In CS Core Network, MSC functional-
ity was split into 2 separate Units: MSC Server (MSS) and Media Gateway
(MGW). This type of Core Network architecture is also called as Split Archi-
tecture. The next chapter explains these issues.
REL-5 UMTS Release 5 was finalized at the end of 2002, including several Core
Network and Radio Interface enhancements such as:
• High Speed Downlink Packet Access; peak DL bitrate up to 14.4 Mbps

• All IP Core Network
• IP Multimedia Subsystem
• Wide Band AMR
Release 5 is a very significant release which affected all areas of UMTS. For
radio network, HSDPA improved the peak bit rates of DL beyond the 2 Mbps
limit. For transmission network, IP based Iub, Iur and Iu interfaces were
defined. In core network, IP multimedia subsystem (IMS) was defined, which
uses SIP based signalling to setup, maintain and tear down the packet sessions.
8
Theoretically 2 Mbps but in practice, we do not get more than 384 kbps using conventional
3G DCH resources.
9
There were 3 options available: TDM, ATM or IP. ATM was chosen because of its flexibility
and QoS provisioning.
REL-6 UMTS Release 6 was frozen 09/2005, containing features such as:
• FDD Enhanced Uplink (HSUPA ); peak UL bitrate up to 5.76 Mbps

• WLAN-UMTS Interworking
• IP Multimedia Subsystem Phase 2
Release 6 was the point where both UL and DL could be High Speed. The
common name for HSDPA and HSUPA is HSPA. It was specified that HSUPA
cannot work without HSDPA in DL.
REL-7 UMTS Release 7 has been closed end of 2007, including important UMTS &
HSPA enhancements, improving the UMTS peak rates and spectral efficiency:
• Higher order Modulation: 64QAM for the DL (up to 21 Mbps), 16QAM

for the UL (up to 11.5 Mbps)
• 2x2 MIMO (up to 28 Mbps) for downlink (HSDPA)
• Continuous Packet Connectivity CPC
• Flexible RLC
• Enhanced Cell FACH
The development of HSPA in Rel-7 was focussed on 3 different objectives,

which are:
• To increase the peak bit rate of HSDPA towards higher limits. This could
be achieved by
– Higher Order Modulation (64QAM in DL & 16QAM in UL), or
– Multiple Input Multiple Output (MIMO) in DL.
• To decrease the battery consumption so that UEs could stay connected
for a longer period even if they are inactive.
• Reduced latency (Round trip time) for better support of RT services on
HSPA.
REL-8 3GPP Release 8 was frozen in 03/2009, containing further HSPA improve-
ments as well as the UMTS Long Term Evolution LTE and the Evolved Packet
System EPS:
• HSDPA further improvement using DC-HSDPA (42 Mbps) and simulta-

neous operation of MIMO & 64QAM in DL.
• DC-HSUPA (23 Mbps)
• New radio access technology: E-UTRAN /Long Term Evolution (LTE)

• New purely packet switched core network Evolved Packet Core (EPC)
Release 8 pushed HSDPA peak bit rate to even higher values by using the
combined operation of 64-QAM and 2X2 MIMO. Additionally, an OFDMA-
based new radio network (E-UTRAN) and a pure IP-based new core network
was defined. This new system os commonly known as Evolved Packet System
(EPS) or Long Term Evolution (LTE).
REL-9 3GPP Release 9 has been closed end of 2009, including HSPA+ enhance-
ments and initial LTE-Advanced (LTE-A) definitions.
• Dual-Cell HSDPA, 2x2 MIMO & 64QAM (up to 84 Mbps).
REL-10 3GPP Release 10 was finished in early 2011; central focus will be on LTE-
Advanced10 Few highlights of Rel-10 are described below.
• Furthermore, definition of Multi-Carrier HSPA for UL & DL is expected.

• LTE-Advanced (up to 1 Gbps DL & 500 Mbps UL for low mobility/Indoor)
as IMT-Advanced proposal (4G).
• Multi-Carrier HSDPA (DL: up to 3 or 4 carrier delivering up to 126 &
168 Mbps respectively).
• Dual-Carrier HSUPA (UL: up to 23 Mbps).
10
The term 4G is quite often used without much care. The ITU guidelines and requirements
show that only in Rel 10, LTE is able to fulfil the requirements of the 4G system. Hence, it is
technically wrong to call REL-8 LTE as 4G system.
Copyright Notices
Main reference material for this book has been technical specifications (TSs) and
technical reports (TRs) of 3rd Generation Partnership Project (3GPP). Information
has been interpreted and presented in a simplified manner.
In the first chapter no copyrighted material has been used. But the information
available on the official website of 3GPP has been the main source of information.
Text on page 16 http://3gpp.org/Partners

Text on page 16 http://3gpp.org/About-3GPP
Table 1.3 http://3gpp.org/Releases
Figure 1.1 on page 3 source: Informa Telecoms & Media
BIBLIOGRAPHY
[1] General information about 3GPP; Available at

http://www.3gpp.org/About-3GPP
[2] Information about 3GPP Organizational partners and market representatives ;

Available at http://www.3gpp.org/Partners
[3] Information about 3GPP Releases ; Available at http://3gpp.org/Releases
[4] Information about mobile technology and IMT-2000; Available at

http://www.itu.int/osg/spu/imt-2000/technology.html
[5] General information about 3GPP2; Available at http://www.3gpp2.com/.
[6] Information about 3GPP Organizational partners and market representatives ;

Available at http://www.3gpp2.com/Public html/Misc/PartnersHome.cfm
[7] http://www.4gamericas.org/
[8] http://www.gsma.com/aboutus/history/
[9] M.1457-11 Detailed specifications of the terrestrial radio interfaces of Interna-

tional Mobile Telecommunications-2000 (IMT-2000)
[10] H.Holma and A. Toskala, ‘WCDMA for UMTS’ , 5th Edition, John Wiley
& Sons.
24
CHAPTER
NETWORK ELEMENTS AND

FUNCTIONALITIES
To understand the network architecture and interfaces of UMTS, we must go through

the evolution of GSM and GPRS. UMTS can be understood as a combination of the
existing pre-Rel-99 GSM/GPRS core network and a new type of radio access network
(UTRAN). Hence, the core networks of 2G and 3G are the same. This aspect
significantly reduced the 3G cost of ownership and inspired the mobile operators
to invest in UMTS. The following sections will explain the architecture, network
elements and interfaces of an UMTS network.
Figure 2.1 shows the GSM network architecture according to its basic release (GSM
Phase 1 and phase 2). The services offered by such a purely circuit switched network
can be categorized in 2 categories.
1. CS Speech: Back in the early 90’s, the voice service was the main objective
while buying a mobile phone. Even today, voice is the most important service
for the majority of the subscribers and operators.
2. CS Data: The CS Data service can be compared to “Internet access using
dial-up modem”. Compared to the modern day’s Internet access, it is different
because in the early days of GSM, the traffic was carried by switches instead
of routers. The switches are equipped with an interworking functionality that
25
26 CHAPTER 2. NETWORK ELEMENTS AND FUNCTIONALITIES
can convert data into a form which can be accepted at the external packet
data network.
Figure 2.1: GSM Network Architecture
2.1 Architecture of the GSM Network

A GSM network is composed of several functional entities whose functions and
interfaces are depicted in figure 2.1. It shows the layout of a generic GSM network.
The GSM network can be divided into three broad subsystems or parts.
1. The Mobile Station (MS): MS is carried by the subscriber.
2. The Base Station Subsystem (BSS): BSS controls the radio link with the
Mobile Station.
3. The Switching Subsystem (SS): SS is also known as core network. Its main
part is the Mobile services Switching Center (MSC) which performs the switch-
ing of calls between the mobile and other fixed or mobile network users as well
as mobility management.
2.1. ARCHITECTURE OF THE GSM NETWORK 27
Not shown is the Operations and Maintenance Center (OMC) which oversees the
proper operation and setup of the network. The MS and the BSS communicate
across the Um interface1 . The Base Station Subsystem communicates with the
Mobile services Switching Center (MSC) across the A interface.
2.1.1 The Mobile Station MS

MS consists of the mobile equipment (the handset) and a smart card called the
Subscriber Identity Module SIM. The SIM provides personal mobility so that the
user can have access to subscribed services irrespective of a specific terminal. By
inserting the SIM card into another GSM terminal, the user is able to receive calls at
that terminal, make calls from that terminal and receive other subscribed services.
• The mobile equipment is uniquely identified by the International Mobile Equip-

ment Identity (IMEI).
• The SIM card contains the International Mobile Subscriber Identity(IMSI),
which is used to identify the subscriber. SIM also contains a secret key which
is required for authentication of the user and encryption of information.
The IMEI and the IMSI are independent thereby allowing personal mobility. The
SIM card may be protected against unauthorized use by a password or personal
identity number.
IMSI is a GSM-specific number which is used for internal signalling be-

tween the nodes of GSM. It is a secret information which is typically
unknown to the subscriber. For making calls and SMS, we use another
number known as MSISDN number2 or simply phone number. MSISDN
looks similar to the phone numbers of fixed line telephones. In HLR, the
mapping between MSISDN and IMSI can be performed.
2.1.2 Base Station Subsystem BSS

The Base Station Subsystem is composed of two types of network elements, the
Base Transceiver Station (BTS) and the Base Station Controller (BSC). These two
communicate across the standardized Abis interface3 . The openness is desired to
allow the interconnection of BTS from one vendor to the BSC of another vendor.
1
also known as the air interface or radio link
2
Mobile Station ISDN Number
3
Although Abis is planned to be an open interface but typically BTS and BSC belong to the
same vendor.
BTS
The Base Transceiver Station houses the radio transceivers that define a cell and
handle the radio link protocols with the Mobile Stations In a large urban area, there
will potentially be a large number of BTSs deployed. Thus the requirements for a
BTS are ruggedness, reliability, portability and minimum cost. The most important
functions of BTS are:
• Physical layer processing (channel coding, interleaving, puncturing etc.)
• Uplink physical layer measurements
• Radio transmission and reception
BSC
The Base Station Controller is the most important network element in BSS. It is
responsible for radio channel assignment, allotment, maintenance and release. One
BSC can control the operations of hundreds of BTS. BSC also controls the handover
procedures for connected mode mobility. BSC is the connection between the mobile
station and the Mobile service Switching Center MSC.
2.1.3 Switching Subsystem

Network Switching Subsystem (NSS) or Switching Subsystem (SS) is responsible for
switching the traffic from one mobile operator to another operator or to PSTN.
MSC and VLR
The central component of the this subsystem is the Mobile services Switching Center
(MSC). It acts like a normal switching node of the PSTN or ISDN and additionally
provides all the functionality needed to handle a mobile subscriber such as registra-
tion, authentication, location updating, handovers4 and call routing to a roaming
subscriber. These services are provided in conjunction with several functional enti-
ties which together form the switching subsystem. The MSC provides the connection
to the fixed networks such as the PSTN or ISDN. Signalling between functional en-
tities in the this subsystem uses Signalling System Number 7 SS7 used for trunk
signalling in ISDN and widely used in current public networks.
4
in the case of Inter-BSC handovers
The Visitor Location Register (VLR) contains selected subscriber’s information from
the HLR necessary for call control and provision of the subscribed services for each
subscriber currently located in the geographical area controlled by the VLR. Al-
though each functional entity can be implemented as an independent unit, all man-
ufacturers of switching equipment implement the VLR together with the MSC so
that the geographical area controlled by the MSC corresponds to that controlled
by the VLR thus simplifying the signalling required. Note that the MSC contains
no information about particular mobile stations. This information is stored in the
location registers.
The following steps take place when a MS tries to register itself with an MSC/VLR.
Step 1: A subscriber sends its request to register with an MSC/VLR (Using IMSI).
Step 2: MSC analyzes the IMSI and finds out the home operator and the HLR’s
address.
Step 3: MSC/VLR contacts the HLR and requests for subscriber’s information.
Step 4: Using this information, the serving MSC/VLR authenticates the subscriber.
Step 5: After successful authentication, VLR informs the HLR about the successful
registration. In future, if any incoming call or SMS arrives for this subscriber,
this MSC/VLR will be contacted for setting up the connection.
Gateway MSC GMSC
From basic operation and functionality, GMSC is in fact the same as MSC but its
logical role is different. GMSC is that MSC which is at the border of the PLMN
and interconnects one network to another. The main function of GMSC is HLR-
Interrogation. This procedure takes place when a Mobile Terminated Call (incoming
call) request comes to GMSC, and GMSC interrogates HLR regarding the current
location of a mobile subscriber.
To understand the role of GMSC, let us take a look at the sequence of events which
take place when an incoming5 call comes.
Step 1: Mobile terminated call setup request arrives at GMSC (using MSISDN of
called party).
Step 2: GMSC queries HLR regarding the current location of subscriber

(using MSISDN number).
5
also known as Mobile Terminated Call (MTC)
Step 3: HLR maps MSISDN to IMSI and finds the VLR address where UE was
last reported.
Step 4: HLR contacts VLR (using IMSI).
Step 5: VLR assigns a temporary Mobile Station Roaming Number (MSRN) to

this IMSI and sends it back to HLR.
Step 6: HLR sends MSRN to GMSC and hence the call can be forwarded to the
serving-MSC where the user is currently located.
The acceptance of an interrogation to an HLR is the decision of the operator. The

choice of which MSCs can act as Gateway MSCs is for the operator to decide (i.e.
all MSCs or some designated MSCs).
Home Location Register HLR
Home Location Register (HLR) is a central database that stores the information
about the subscribers. When a SIM card is issued to a mobile user, it gets reg-
istered in HLR. Afterwards, wherever the user goes, it gets registered with local
MSC/VLR and that MSC/VLR contacts HLR to get the administrative informa-
tion of the subscriber. In this way, HLR always keeps track of the user’s location.
This information is stored in the form of signalling address of VLR. HLR and VLR
communicate using MAP protocol of the SS7 signalling suite.
For each subscriber HLR contains a lot of information. Some of that is shown below:
• IMSI of the subscriber
• MSISDN of the subscriber
• VLR-address which is currently serving this subscriber
• List of Subscribed services
• GPRS related data
• Quality-of-service (QoS) profile
• Subscribed supplementary services (e.g., Call Waiting, Call Forwarding, etc.)
There is logically one HLR per GSM operator but as the number of subscribers
grows, there can be more than one HLR in the network. It is also better to have
another HLR node for redundancy purpose. The second node can be used for backup
and for redundancy purpose. This arrangement can be used to guarantee the service
continuity in case of technical failure with the first node. The information about
HLR-address can be found from the IMSI.
Equipment Identity Register EIR
The Equipment Identity Register (EIR) is a database that contains a list of all
valid mobile equipment on the network where each mobile station is identified by
its International Mobile Equipment Identity IMEI. An IMEI is marked as invalid if
it has been reported stolen or is not type-approved. An EIR maintains three lists:
1. Black: The IMEI numbers of the mobile handsets which have been reported
stolen or inappropriate are stored in black list.
2. White: The while list contains the few digits of IMEI number that identify the
handset type. In white list, there is no need to have the full IMEI number.
If a handset model has been approved by 3GPP standards, then its ”handset
type” is stored in the white list.
3. Grey: Under the grey list of EIR, one can find the IMEI numbers of phones
which are under surveillance. Every time, this handset is used to access the
network services, a log will be generated.
In the criminal investigation, IMEI number proves to be quite helpful. Sometimes,

criminals steal the phones and start using them with their own SIM cards. Fortu-
nately, the IMEI number of the handset can help the law enforcement agencies to
track the mobile equipment.
Authentication Center AuC
The Authentication Center (AuC) is a protected database that stores a copy of

the secret key stored in each subscriber’s SIM card. The AuC always resides in
the HPLMN. This network element is the most secured node in the whole PLMN.
The AuC generates security data which is used for authentication of users and
encryption of data over the radio channel. The secret master key (K) never leaves
the authentication center. The AuC feeds random number (RAND) and master key
(K) to a standards algorithm and generate security data. This security data is then
forwarded to the serving MSC/VLR in VPLMN.
As described, MSC/VLR perform an authentication procedure to verify the identity

of the user at the time of registration. The relationship between MSC/VLR and the
AuC can be illustrated in figure 2.2.
Figure 2.2: Authentication of user during roaming
2.2 Improvements of GSM Standard

Compared to the mobile systems which were available till the 90s, GSM was a
magical invention and hence, a huge success in the commercial market.
The services offered by GSM could be summarized as:
• Incoming and outgoing speech calls
• Short message services
• Supplementary services e.g., call forwarding, calling line identification presen-

tation etc.
• Data services e.g., email, fax, web surfing
In the next few sections, we will discuss the developments which improved the GSM
system in terms of efficiency and user experience.
2.2. IMPROVEMENTS OF GSM STANDARD 33
2.2.1 CAMEL
Source: 3GPP TS 29.002 (MAP) & 3GPP TS 22.078, 23.078, 29.078
(CAP)
CAMEL (Customized Applications for Mobile network Enhanced Logic) is an

IN6 architecture within the GSM based on 3GPP standardization. CAMEL pro-
vides mechanisms to support services independently of the serving network. With
CAMEL, it is possible to offer operator-specific services (OSS), that is, intelligent
network services, for the subscriber while roaming outside the home PLMN.
In order to support Intelligent-Network applications:
• MSCs are often upgraded with a Service Switching Point (SSP) which resides
in VPLMN.
• Operator-specific services can be generated in the Service Control Point (SCP)
which lies in HPLMN.
• Inter-operator communication is guaranteed by using an open interface and
common protocol. The Interface between SSP-SCP is well-defined open inter-
face and the protocol used is called CAMEL Application Part (CAP).
CAMEL was developed under the framework of Virtual Home Environment, which
means that the subscriber should get the same ‘look & feel’ of the services, inde-
pendent of the serving network, type of handset etc.
CAMEL within Home PLMN
Within Home PLMN (or Home Network), 2 functional entities are involved.
HLR: The HLR stores subscriber-related data, which also includes the informa-
tion whether the subscriber is a CAMEL subscriber. The HLR transfers the
CAMEL Subscription Information (CSI) to the network elements which need
it to be able to provide CAMEL services. These network elements have to
support CAMEL, and sending the CSI to these elements has to be allowed.
gsmSCF: The operator-specific services are executed in the gsmSCF, which con-
tains the service logics invoked during originating and terminating CAMEL
calls, originating SMSs, etc. The CAMEL standard does not specify the im-
plementation of operator-specific services.
6
Intelligent Network
Figure 2.3: CAMEL Service Architecture (Phase 1)
CAMEL within visited PLMN
The PLMN where the CAMEL subscriber is roaming is called the visited net-
work (VPLMN). The VMSC, VLR & gsmSSF handle the processing of originating
CAMEL calls and forwarded calls, and terminating CAMEL calls.
Visited MSC: The VMSC sets up calls from and towards the visiting subscriber.
When handling service setup, the VMSC detects whether the subscriber has
CAMEL services. If the VMSC receives CSI from VLR and the triggering
criteria are met, an initial contact to the gsmSCF takes place. During the
CAMEL call, the gsmSCF may request the VMSC to monitor and report
certain call events.
gsmSSF: The gsmSSF acts as an interface from the MSC/GMSC towards the gsm-
SCF. The gsmSSF initiates the dialogue with the gsmSCF to get instructions
for the CAMEL call handling.
VLR: The VLR stores the CAMEL subscriber data received from the HLR of the
home network as part of the subscriber data of the subscriber roaming in the
VLR area. The VLR sends the subscriber data to the VMSC during originating
or forwarded call processing, and terminating call processing.
CAMEL standard has been gradually improved in phases. Currently, there are 4
phases:
• CAMEL Phase 1
2.3. GPRS NETWORK ARCHITECTURE 35
• CAMEL Phase 2
• CAMEL Phase 3
• CAMEL Phase 4
In order to identify the CAMEL phase, we must check which version of MAP &
CAP protocols are supported by gsmSSF, gsmSCF & HLR.
2.3 GPRS Network Architecture

In the list of services offered by GSM, there is a circuit switched data service but it
has 2 basic problems:
• Low Bit rate (only 9.6 kbps)
• Circuit switching & time-based charging
As explained in the previous module, HSCSD was introduced to improve the GSM
bit rates by roughly 5 times by allocating multiple time slots to the same subscriber.
But as the name suggests, HSCSD is also a circuit switched technology which relies
on time-slot management and time-dependent charging. In a data session, typically
we never use the channel 100% of allocation time. Hence, the operator has to allocate
the resources unnecessarily and the user has to pay for this channel for the whole
duration of the connection.
This was the main motivation to develop the concept of GPRS. GPRS is a packet
switched technology where the packets are carried using routers and not using
switches. Figure 2.4 clearly shows the combined GSM & GPRS network archi-
tecture.
On a general level, GPRS connections use the resources only for a short period of
time when sending or receiving data:
• In a circuit-switched system, the line is occupied even when no data is trans-

ferred.
• In a packet-switched system, the resources are released so they can be used by

other subscribers.
Figure 2.4: GPRS Network Architecture
The General Packet Radio System (GPRS) is a new service that provides actual
packet radio access for mobile GSM and time-division multiple access (TDMA)
users. The main benefits of GPRS are that it reserves radio resources only when
there is data to send and it reduces reliance on traditional circuit-switched network
elements. The increased functionality of GPRS decreases the incremental cost to
provide data services and increases the penetration of data services among consumer
and business users.
In addition to providing new services for today’s mobile user, GPRS is an important
migration step toward third-generation (3G) networks. GPRS will allow network
operators to implement an IP-based core architecture for data applications, which
will continue to be used and expanded upon for 3G services for integrated voice
and data applications. Today, everyone knows that packets are transported using
routers. Prior to GPRS, the packets were carried via switches (MSCs) which is very
inefficient if the nature of traffic is bursty.
2.3.1 GPRS Mobile Terminals

New mobile terminals are required because existing GSM phones do not handle the
enhanced air interface nor do they have the ability to packetize traffic directly. All
these terminals will be backward compatible with GSM for making voice calls using
GSM.
Class A terminals: Class A terminals support simultaneous circuit-switched (CS)

and packet-switched (PS) traffic.
Class B terminals: Class B terminals attach to the network as both CS and PS
clients but only support traffic from one service at a time. They can monitor
GSM and GPRS channels simultaneously. In other words, a Class B terminal
can support simultaneous attach, activation, and monitor, but not simultane-
ous traffic.
Class C terminals: Class C terminals support attach to only one type of network
(either CS or PS). The user must manually select the service to which it wants
to connect. Therefore, a Class C terminal can make or receive calls from only
the manually (or default) selected service. The service that is not selected is
not reachable.
The three modes of operation are defined in 3GPP TS 22.060.
2.3.2 GPRS Base Station Subsystem

Impact of GPRS on BSC
Each BSC will require the installation of one or more Packet Control Unit (PCUs)
and a software upgrade. The PCU provides a physical and logical data interface
out of the base station system (BSS) for packet data traffic. When either voice or
data traffic is originated at the subscriber terminal, it is transported over the air
interface to the BTS, and from the BTS to the BSC in the same way as a standard
GSM call. However, at the output of the BSC the traffic is separated; voice is sent
to the mobile switching center (MSC) per standard GSM, and data is sent to a new
device called the SGSN, via the PCU over a Frame Relay interface.
Impact of GPRS on BTS
The BTS may also require a software upgrade but typically will not require hardware
enhancements. The upgrade in BTS is called Channel Control Unit (CCU) which
is responsible for adaptive coding (CS-1 , 2 , 3 and 4).
The CCU (Channel Coding Unit) in the BTS performs channel coding whose rate
is adapted to the radio transmission conditions:
• CS-1 (Channel Coding Scheme 1) - 9.05 kbps


2.3.3 New Elements in the Core Network

Source : 3GPP TS 23.060
SGSN
At the hierarchical level, SGSN can be considered as an “MSC with in-built VLR for
PS users”. In other words, SGSN can be viewed as a “packet-switched MSC”. Very
similar to the CS registration with MSC/VLR, a GPRS mobile station has to register
with SGSN. This registration process is called ‘GPRS attach’. After entering a new
area, GPRS user reports its location to the corresponding SGSN. Thus SGSN is
responsible for the registration of new mobile subscribers, and keep a record of their
location inside a given area. In other words, SGSN performs mobility management
functions such as mobile subscriber attach/detach and location management. The
SGSN is connected to the base-station subsystem via a Frame Relay connection to
the PCU in the BSC.
For a better understanding, the following section breaks down the attach process of
GRPS into several steps and explains it.
Step 1: A subscriber sends its request to register with an SGSN (Using IMSI).
Step 2: SGSN analyzes the IMSI and finds out the home operator and HLR’s
address.
Step 3: SGSN contacts HLR and requests for subscriber’s information (e.g., Sub-
scriber’s service profile, QoS agreement, max bit rate etc., authentication re-
lated data).
Step 4: Using this information, the serving SGSN authenticates the subscriber.
Step 5: After successful authentication, SGSN informs HLR about the successful
registration.
At this moment, a so-called ‘MM-Context’ is generated at MS and SGSN. In other

words, a logical-connection has been established between MS and SGSN. This con-
nection is not enough to receive/transmit IP packets because the MS does not have
an IP address yet.
The main functions of SGSN can be summarized as:
• Mobility Management
• Subscriber’s registration and authentication
• Charging Data Records (CDR) collection
• Ciphering7
• Packet routing
Gateway GPRS Support Node
When we observe the GPRS network from the outside world’s viewpoint, it appears
that GPRS is nothing but a private IP network owned by the mobile operator. The
access to this IP network is allowed only via a gateway router known as GGSN.
Hence GGSNs are used as interfaces to external IP networks such as the public
Internet, other mobile service providers GPRS services, or enterprise intranets.
UE establishes an IP connectivity with GGSN via a procedure known as ‘PDP
Context Activation’. This procedure takes place in following sequence:
Step 1: MS sends PDP activation requests by specifying the Access Point Name
(APN) Access Point Name (APN) and requested Quality-of-Service (QoS).
Step 2: SGSN translates APN into the IP address of GGSN with the help of a DNS
system.
Step 3: SGSN forwards the request to GGSN and GGSN allocates an IP address
to the mobile user.
Step 4: GGSN informs SGSN and SGSN informs MS about the successful PDP
context activation. From this moment, MS is known in the IP world because
it has been allocated a valid IP address.
At this point, a so-called PDP Context is generated at MS, SGSN and GGSN side.
The main functions of GGSN can be summarized as:
• Packet routing
• Charging Data Records (CDR) generation
• Firewall functionality
7
(only in 2G but not in 3G SGSN)
• IP-address allocation
• QoS negotiation
• Session management (e.g., PDP context activation)
GGSNs maintain routing information that is necessary to tunnel the protocol data
units (PDUs) to the SGSNs that service particular mobile stations.
A more detailed information about each parameter of MM-context and

PDP-context goes beyond the scope of this book. 3GPP TS 23.0608
contains tables which show the information storage structures required
for GPRS. There, we can also find details about subscription data stored
in the HLR. For proper GPRS operation, MM-context must be stored
in UE & SGSN; PDP-context must be stored in UE, SGSN & GGSN.
Please refer to 3GPP TS 23.060 to get more details.
2.3.4 Other Changes

The databases in the GSM network, such as the Home Location Register (HLR)
that handle the mobility management in the network also require software updates
to be able to handle the GPRS functions. Other than these standard nodes, the
GPRS network also requires the following network functionalities:
Border Gateway (BG)
The BG is a special firewall which connects SGSN or GGSN to GPRS Roaming

Exchange (GRX) which is used for inter-PLMN connectivity. To understand the
role of BG, please refer to figure 2.5.
Charging Gateway (CG)
The Charging Gateway or charging gateway functionality (CGF) is used for col-
lecting the CDRs from SGSN and GGSN. Quite often, the format of CDRs is not
standardized and varies strongly from one vendor to another. Charging gateway
functionality is used for transforming the CDRs into a standard form and forward
them to the billing center. It helps the telecom operators to implement different
services with little billing and charging effort as well as protecting the subscriber
8
General Packet Radio Service (GPRS); Service description
and operator from wrong charging. During PDP context activation the GGSN sends
a ‘charging ID (CID)’ to the SGSN. During the billing process, CDRs are regularly
sent from each network node to a central billing centre. The CID is used to merge
the records from different network nodes which apply to the same subscriber.
Domain Name System (DNS)
While activating the PDP context, UE sends Access Pint Name (APN) to SGSN.
APN is a user-friendly name which is designed for the comfort of human beings.
But routers cannot work with these names. GSGN uses DNS to translate the APNs
into the IP-Address of GGSN9 .
Lawful Interception Gateway (LIG)
LIG is used for law enforcement agencies (like police) to monitor the activities of
some suspicious subscriber.
Firewall
Firewall is used to filter the malicious packets and keep GPRS networks safe from
unwanted virus and other threats. Quite often, Firewall functionality is implemented
in the GGSN itself.
2.3.5 GPRS Roaming Scenario

Till now, we have observed that a packet in GPRS network takes the following path:
Radio Network (BSS) SGSN GGSN
The path shown above is depicted in the upper half of figure 2.5. This is true as long
as the SGSN and GGSN both reside in the same network. In other words, when the
user is not roaming.
However, in roaming scenarios, the most popular implementation is to use the
SGSN in Visited PLMN and GGSN in the Home PLMN. This inter-PLMN connec-
tion is made using a private IP-backbone owned by one of the operators or by a
third party. This scenario is depicted by the lower half of figure 2.5.
We hereby like to briefly mention the two scenarios:
9
The same principle is used in internet for translating URLs into an IP address.
Figure 2.5: Data Access during roaming and non-roaming scenario
1. In non-roaming scenario: In non-roaming scenario, both SGSN and GGSN

are located in the same PLMN using intra-PLMN backbone commonly
known as the Gn interface.
2. In roaming scenario: In roaming scenario, SGSN resides in the VPLMN whereas

GGSN resides in the HPLMN. The two GPRS nodes are connected to each
other using inter-PLMN backbone using Gp interface via a secure border
gateway functionality. Gp is the name of the interface between “SGSN and
Border Gateway” and “GGSN and Border Gateway”.
2.4 Migration to 3G Network Architecture

In order to re-use the investments of GSM and to minimize the rollout cost of UMTS,
it was decided that the existing GSM & GPRS core network will be slightly modified
but the very same nodes will be utilized to provide access to both10 the radio access
networks. There were some minor modifications defined for 3G MSC and 3G SGSN.
Many authors like to show these changes as interworking functionality IWF and
10
TDMA based 2G radio network BSS and WCDMA based 3G radio network UTRAN
2.5. UTRAN 43
reuse the same conventional MSC and SGSN.
Figure 2.6: Block Diagram of Combined GSM & UMTS Network Architecture
As a starting point, we should consider combined GSM, GPRS & UMTS the
network architecture as a combination of the following subsystems:
1. GSM Base station Subsystem: BTS and BSC
2. GSM CS core network: MSC and GMSC
3. GPRS CN: SGSN and GGSN
4. UTRAN: newly developed WCDMA based radio access network
5. Common units: Databases, registers, application servers and billing system
From this list, all objects except UTRAN have been already discussed in this chapter.
Therefore, in the following section, we will concentrate on the details of UTRAN.
2.5 UTRAN
UMTS Terrestrial Radio Access Network (UTRAN) is the brand new Wideband
CDMA-based access network defined for 3G UMTS networks. UTRAN is divided
into several Radio Network Subsystems where each RNS is managed by one RNC.
A RNS typically consists of hundreds of base stations known as Node B.
The Radio Network System (RNS) is the system of base station equipments (transceivers,
controllers, etc. . . . ) which is viewed by the MSC through a single Iu-interface as
being the entity responsible for communicating with Mobile Stations in a certain
area. Similarly, in PLMNs supporting GPRS, the RNS is viewed by the SGSN
through a single Iu-PS interface. In short,the RNS consists of one Radio Network
Controller (RNC) and one or more Node B.
Figure 2.7: UMTS Network Architecture
2.5.1 Node B
Node B can be simply considered as the “BTS of 3G”. The main functions of Node
B is to establish the physical implementation of Uu interface and Iub interface. The
realization of Uu interface means that Node B implements WCDMA physical chan-
nels and converts the information coming from transport channels to the physical
channels under control of RNC. For the Iub interface, Node B performs the inverse
functionality. It should be noted here that Node B owns only physical channels’
resources whereas transport channels are completely managed by RNC.
• Spreading
2.5. UTRAN 45
Figure 2.8: New Interfaces defined in UTRAN Iub, Iur and Iu
• Scrambling
• Modulation
• Channel Coding
• Interleaving
• Power Control
• Synchronization
• Measurement reporting
2.5.2 RNC
Radio Network Controller (RNC) is the main controlling element in UTRAN, since
it owns all the logical resources of Radio Network Subsystem. It is responsible for
controlling the use and integrity of all 3G radio resources by the means of performing
Radio Resource Management (RRM) procedures. This includes functions such as
handover and admission control, power control and code allocation, radio resource
control (RRC) and macro diversity combining (MDC).
RNC is the central unit in 3G RAN. It also plays an important role in configuration
management because the radio related parameters for the whole RNS are stored in
RNC. For performance management, RNC updates counters, which are later used
to calculate the key performance indicators (KPIs) for RAN. RNC also provided
support in fault management by keeping track of the alarms in any Node B controlled
by that particular RNC.
• Radio Resource Management
• Management of System information
• Alarms handling
• Interworking node Iub and Iu interfaces
• Operation and Maintenance
• Performance Measurement
RNC works as the intermediate node which connects Core Network (CN) to RAN. It
is possible that the transport technologies in RAN and Core are different (e.g., One
side is using ATM and the other side IP). In that case, RNC performs the protocol
conversion required for interworking.
2.6. LOGICAL ROLES OF RNC: S-RNC AND D-RNC 47
2.6 Logical roles of RNC: S-RNC and D-RNC
Figure 2.9: Logical Roles of RNC: SRNC and DRNC
In UMTS, while the user is moving from one cell to another, radio links are added
and deleted without breaking the connection. This is called Soft Handover. If the
two cells belong to 2 different RNCs, then SHO is possible only if the Iur interface
between the two RNCs exists. Otherwise, a hard handover takes place which can
be compared to Inter-BSC handover of GSM.
As shown in figure 2.9, the logical role played by RNC can earn it 3 different titles.
Controlling RNC (CRNC): CRNC of Cell # 1 is the RNC which controls the
operation of cell by defining its load and other parameters. For all the tele-
com procedures happening in cell #1, RNC #1 is responsible. Therefore, the

CRNC of cell #1 is RNC#1.
Serving RNC (SRNC): SRNC of UE is the RNC, which has a signalling connec-
tion (RRC Connection) with UE. From Core Network viewpoint, UE is con-
nected to only this RNC because Core Network (MSC or SGSN) receives/sends
data from/to this RNC only. UE always has only one SRNC. Serving RNC
owns all logical resources belonging to the user connection. Serving RNC is
the place where the Macro Diversity Combining (MDC) is executed.
Drift RNC (DRNC): DRNC of UE is the RNC which is involved in soft handover
but is not the SRNC. The DRNC is CRNC of one of the cells which are involved
in Soft Handover. DRNC comes into play only if we have Inter-RNC Soft HO.
Please refer to figure 2.9 for clear understanding.
Whenever we talk about Soft HO, there is always a discussion of Micro or Macro-
diversity.
Micro-diversity: Micro-diversity comes into play when UE is involved in Soft han-

dover with 2 cells which belong to the same Node B. This special case of soft
HO is called Softer HO. Micro-diversity combining takes place in Node B.
Macro-diversity: Macro-diversity comes into play when UE is involved in soft

handover with 2 or more cells which belong to 2 (or 3) different Node Bs.
Macro-diversity combining takes place in RNC.
2.6. LOGICAL ROLES OF RNC: S-RNC AND D-RNC 49
Summary of R99 Network Architecture

Source: 3G TS 23.002 V3.1.0; Network architecture
Figure 2.10: Configuration of a PLMN and Interfaces (Source TS 23.002)

2.7 Release 4 Modifications

Source:
• Overview of 3GPP Release 4 V1.1.2 (2010-02)
• 3GPP TS 23.205 V4.0.0; Bearer Independent CS Core Network
• 3GPP TS 23.002 V4.8.0; Network architecture
Figure 2.11: BICC Network Architecture or Split Architecture
As shown in chapter 1, after Rel-99, 3GPP stopped naming the releases after the
year as they did in Rel-95, 96, etc. The first set of modifications introduced were
called 3GPP Rel-4. In short, the history and future follows this path: Rel-96 →
Rel-97 → Rel-98 → R99 → Rel-4 → Rel-5 → Rel-6 → and so on.
3GPP Rel-4 specifications were frozen in March 2001. One of the highlights of Rel-4
is known as “Bearer Independent Call Control”. In order to understand this feature,
please refer to the CS part of core network in figure 2.11.
The objective of this feature is to separate the user plane (traffic) and control plane
(signalling) in the Circuit Switched (CS) domain. This new scheme offers a better
2.7. RELEASE 4 MODIFICATIONS 51
transport resource efficiency and a convergence with the Packet Switched (PS) do-
main transport. Also, this enables to use one single set of layer 3 protocols on top
of different transport resources as ATM, IP, STM, or even new ones.
The users shall not notice whether they are connected to a “bearer independent CS
network” or to a classical CS domain. Also, none of the protocols used on the radio
interface is modified by this feature. This means, for example, there is no need for
the terminals to support IP even if IP is the transport protocol used in the network.
Using BICC, the traffic is switched using CS-MGW which is capable of handling all
modern codecs (e.g., 4.75 kbps AMR ). Thus the speech can be transported from
one CS-MGW to another CS-MGW without the need of transcoding. This feature
has at least three direct benefits for the operator:
Reduced cost of transmission: The utilization of ATM/IP resources reduces sig-

nificantly compared to the conventional MSCs. Because speech must be transcoded
into 64 kbps TDM format so that MSCs can handle it. Using BICC, the need
of transcoding arises just before the speech ‘packet’ leaves UMTS domain and
enters PSTN. In conventional CS core network, the transcoding is performed
as soon as the first MSC is encountered, whereas in BICC, transcoding is
performed by the last CS-MGW in the chain.
Improved capacity: By avoiding the unnecessary transcoding, the speech quality
gets improved. In CDMA networks, this turns out to be a gain in network
capacity.
Reduced delay: If transcoding is not performed, then the delay caused by transcod-
ing is also avoided. This reduces the transmission delay and improved user’s
perception.
2.7.1 Architecture
The basic principle is that the MSC is split into an MSC server and a (Circuit-
Switched) Media Gateway (CS-MGW), the external interfaces remaining the same
as much as possible as for a monolithic MSC.
According to 23.002, “When needed, the MSC can be implemented in

two different entities: the MSC Server, handling only signalling,
and the CS-MGW, handling user’s data. A MSC Server and a
CS-MGW make up the full functionality of a MSC.”
• The MSC server provides the call control and mobility management functions,
and
• The CS-MGW provides the stream manipulating functions, i.e. bearer control
and transmission resource functions.
The same applies to the GMSC, split into a GMSC server and a CS-MGW.
Figure 2.12: BICC Network Architecture and Interworking with PSTN
MSC Server
The MSC Server comprises all the call control and mobility control parts of an MSC.
As such, it is responsible for the control of mobile originated and mobile terminated
CS domain calls. It terminates the user to network signalling and translates it into
the relevant network to network signalling. It also contains a VLR.
The MSC Server controls the parts of the call state that pertain to connection control
for media channels in a CS-MGW.
A GMSC Server is to a GMSC as an MSC Server is to an MSC.
CS-MGW
The CS-MGW interfaces the transport part of the UTRAN/BSC with the one of
the core network over Iu or the A interface. It interacts with the (G)MSC server for
resource control.
A CS-MGW may also terminate bearer channels from a circuit switched network
and media streams from a packet network (e.g., RTP streams in an IP network).
As the entity interfacing the access and the core network, the CS-MGW operates
the requested media conversion (it contains e.g., the TRAU), the bearer control and
the payload processing (e.g. codec, echo canceller, conference bridge). It supports
the different Iu options for CS services (AAL2/ATM based as well as RTP/UDP/IP
based).
2.7.2 New Interfaces

CS-MGW to MSC Server (Mc)
The Mc reference point describes the interfaces between the MSC Server and CS-
MGW, and between the GMSC Server and CS-MGW. It supports a separation of
call control entities from bearer control entities, and a separation of bearer control
entities from transport entities. It uses the H.248/IETF Megaco protocol, jointly
developed by ITU-T and IETF.
MSC-Server to MSC-Server (Nc)
Over the Nc reference point, the Network-Network based call control is performed.
Examples of this are ISUP or an evolvement of ISUP for Bearer Independent Call
Control (BICC).
CS-MGW to CS-MGW (Nb)
Over the Nb reference point, the bearer control and transport are performed. Dif-
ferent options are possible for user data transport and bearer control.

Source:
Overview of 3GPP Release 5 V0.1.1 (2010-02)
3GPP TS 23.002 V5.12.0; Network Architecture
Release 5 is a very important release because HSDPA was introduced in it. From
the architecture perspective too, there were very significant improvements suggested
by 3GPP in REL-5 specifications. The IMS11 is standardized by 3GPP in Rel-5.
Usage of IP on the transport plane was another improvement which was introduced
in this release. These features are briefly illustrated below.
2.8.1 IP Transport
In Rel-99 and Rel-4, only ATM can be used at the transport layer in the various
interfaces. Rel-5, introduces the possibility to use IP at the transport layer in the
Iub, Iur, Iu-Ps and Iu-Cs interfaces, as an alternative to ATM. However, the use of
ATM at the link layer under IP is not precluded. For more detailed description of
the protocol stacks, please refer to chapter 6.
The introduction of IP as a transport protocol in the radio network does not imply
an end to end IP network; the UE may be given an IP address by the higher layers,
but it will not be part of the UTRAN IP network (which is private), and packets
will be encapsulated in the corresponding User Plane protocol. 3GPP has made a
choice for the protocols to transport the Radio and Signalling bearers over IP.
Different solutions are adopted. UDP is used in the user plane in the three interfaces,
and SCTP with additional protocols is used for the signalling bearers. Addition-
ally, 3GPP resulted in the following decisions on QoS and interworking with ATM
transport networks:
• Diffserv is the mechanism to provide different service levels, and several al-
ternatives are allowed for the traffic flow classification. It is also allowed that
the QoS differentiation can be provided either on a hop-by-hop basis or on a
edge-to-edge basis;
• Interworking with Rel-99/Rel-4 and Rel-5 ATM nodes is required, and it can
be accomplished via a dual stack, a logical interworking function or a separate
Interworking unit.
11
Now a days, IMS is a very hot topic because in LTE, there is a provision of supporting IMS-
based Voice service over PS-domain.
2.8.2 IP Multimedia Subsystem (IMS)
Figure 2.13: Overview of IMS architecture
Home Subscriber Server
Home Subscriber Server (HSS) is an evolved version of HLR. From Rel-5 onwards,
the name of HLR is changed into “HSS” to emphasize that this database contains
not only location-related data but also subscription-related data, like the list of
services the user is able to get and the associated parameters. It keeps track of
which subscribers belong to the network and their service capabilities. The CSCF
consults with the HSS before initiating SIP connections.
Media Gateway Control Function (MGCF)
MGCF performs translation of SIP signalling messages into ISUP messages which
can be understood by the PSTN switches. As the name suggests, MGCF controls
the functions of IM-MGW.
IP Multimedia Media Gateway Function (IM-MGW)
An IM-MGW is used to terminate bearer channels from circuit switched infrastruc-

tures and media streams from packet data networks. For instance, when it interfaces
an ISDN network, it takes the data of voice from i-law PCM call, processes the user
data bits with a voice codec (e.g. AMR), before forwarding the voice information
via RTP/UDP/IP over a packet network. To do so, an IM-MGW requires its own
resources, such as codecs, echo cancellers, and conference bridges. The IM-MGW
communications with the Media Gateway Control Function (MGCF) for resource
control via the interface Mc. For this interface, the media gateway control protocol
H.248 is applied.
Proxy-Call State Control Function (P-CSCF)
P-CSCF is the “first contact point” of IMS. It is located in the same network as the
GGSN (visited or home network). Its main task is to select the I-CSCF of the Home
Network of the user. It also performs some local analysis (e.g. number translation,
QoS policing,..).
Interrogating-CSCF (I-CSCF)
I-CSCF is the “main entrance point” of the home network: it selects (with the help
of HSS) the appropriate S-CSCF.
Serving-CSCF (S-CSCF)
S-CSCF performs the actual Session Control. It handles the SIP requests, performs
the appropriate actions (e.g. requests the home and visited networks to establish
the bearers), and forwards the requests to the S-CSCF /external IP network of other
end users, as applicable. The S-CSCF might be specialized for the provisioning of a
(set of) service(s).
Source: Overview of 3GPP Release 6 V0.1.1 (2010-02)

2.9.1 IMS for IP-CAN or IMS phase 2

IMS was primarily designed in Rel-5 to work on top of UMTS/GPRS using SIP
signalling but in 3GPP Rel-6, it was extended to work on top on non-GPRS
based access and SIP terminal equipments. ETSI TISPAN12 has worked very
hard to adapt the IMS for requirements of fixed networks.
Figure 2.14: Usage of IMS expanded for any IP access network
As shown in figure 2.14, the access network for using IMS services is no more re-
stricted to GPRS & UMTS. The name chosen for this generic access network is
“IP-Connectivity Access Network (IP-CAN)”. Some of the examples of IP-CAN are
DSL, Cable, Wired and Wireless LAN, LTE etc.
IP-CAN of 3GPP Rel-6 also addresses the issues like:
• Policy Control: “Policy Decision Function” in the IMS (e.g., in P-CSCF) and
“Policy Enforcement Function” in the IP-CAN (e.g., in GGSN)
• Security
• User and service profile
• UE and ISIM/USIM
• IP version issues
12
TISPAN: Telecommunications and Internet converged Services and Protocols for Advanced
Networking
• SIP Compression
• Emergency calls
2.10 Rel-7 & Rel-8 Modifications

3GPP REL-7 & 8 have introduced a lot of improvements of HSDPA & HSUPA
of REL-6. This bundle-of-enhancements is collectively called as evolved-HSPA or
HSPA+. Since, we have not discussed the details of HSPA yet, it makes no sense to
talk about HSPA+ in this module.
In nutshell, we can say that HSPA+ is trying to:
• Push the peak bit rates of HSDPA & HSUPA higher
• Reduce the battery consumption for continuous connectivity
• Reduce the latency (transfer delay)
3GPP REL-7 & 8 have also introduced some changes in the core network to optimize
the network performance towards lower latency. These changes in the PS core
network are popularly called as “one tunnel solution”. Figure 2.15 shows the changes
introduced in Rel. 7 & 8.
1. As in conventional GPRS, EDGE, UMTS & HSPA (R6), there are two tunnels:
One between GGSN & SGSN and the other one between SGSN & RNC. That
means, SGSN takes out the IP packets from one tunnel and packs it into
another tunnel. This procedure certainly takes some time.
2. In Rel-7, there is a mechanism for “One- Tunnel- Solution”. This allows

SGSN to be involved with only a control plane, e.g., connection setup, mobility
management, authentication etc. SGSN does not appear in the chain for user
plane traffic flow. User data can be directly tunneled from GGSN to RNC.
Although this solution reduced the round trip time but there are some com-
plications with this scheme.
(a) Volume-dependent charging at SGSN will not be possible with this solu-
tion.
(b) For Lawful Interception also, SGSN will not be able to provide any details
about the packet transmitted during the session.
2.10. REL-7 & REL-8 MODIFICATIONS 59
3. In Rel-8, the concept of one tunnel can be extended by one more step where
the user data is directly tunneled from GGSN to Node B. But we must not
forget that this Node B is a special one. The Node B has in-built capability
of RNC.
Figure 2.15: Direct Tunnel Solution of REL-7 & REL-8

Copyright Notices
In order to create some figures, tables and text-sections, the following reference ma-
terial has been used. Information has been interpreted and presented in a simplified
manner. The original references are provided here.
technical reports (TRs) of 3rd Generation Partnership Project (3GPP).
Figure 2.10 on page 49 Figure 1 of TS 23.002 v 3.1.0

⃝1999.
c 3GPPTM TSs and TRs are the property of ARIB, ATIS, ETSI, CCSA,
TTA, and TTC who jointly own the copyright for them. They are subject to
further modifications and are therefore provided to you “as is” for information
purposes only. Further use is strictly prohibited.
Text on page 51 Section 4.1.1 of “Overview of 3GPP Release

4 v 1.1.2”
Text about MSC Server on page Section 4.1.2.1 of “Overview of 3GPP Re-
52 lease 4 v 1.1.2”
Text about CS-MGW on page 52 Section 4.1.2.2 of “Overview of 3GPP Re-
lease 4 v 1.1.2”
Figure 2.11 on page 50 Figure: BICC Network Architecture of
“Overview of 3GPP Release 4 v 1.1.2”
Figure 2.12 on page 52 Figure: Bearer Independent Core Network
with A- and Iu-Interfaces of “Overview of
3GPP Release 4 v 1.1.2”
Text in section 2.7.2 on page 53 Section 4.1.3.1, 4.1.3.2 & 4.1.3.3 of
“Overview of 3GPP Release 4 v 1.1.2”
Text in section 2.8.1 on page 54 Section 6.1 of “Overview of 3GPP Release 5
v 0.1.1”
Text about CSCF on page 56 Section 12.2 of “Overview of 3GPP Release
5 v 0.1.1”
⃝2010.
c TM
3GPP TSs and TRs are the property of ARIB, ATIS, ETSI, CCSA,
BIBLIOGRAPHY
[1] 3GPP TS 25.401 Ver. 7.0.0 ;‘UTRAN overall description’

[2] 3GPP TS 23.002 ver. 3.1.0 ;‘Network architecture’
[5] 3GPP TS 29.002 ver. 3.0.0 ;‘Mobile Application Part (MAP) specification’
[6] 3GPP TS 22.078 ver. 9.0.0 ;‘Customised Applications for Mobile network En-
hanced Logic (CAMEL) Service description’
[7] 3GPP TS 23.078 ver. 5.0.0 ;‘Customised Applications for Mobile network En-
hanced Logic (CAMEL) Phase 4’
[8] 3GPP TS 29.078 ver. 5.0.0 ;‘CAMEL Application Part (CAP) specification’
[9] 3GPP TS 23.205 ver. 4.0.0;‘Bearer Independent CS Core Network’
[10] 3GPP TS 23.060 ver. 6.0.0 ;‘General Packet Radio Service (GPRS); Service
description’
[11] 3GPP TS 22.060 ver. 6.0.0 ;‘General Packet Radio Service (GPRS); Service
description’
[12] Overview of 3GPP Release 4 v 1.1.2 ; Available at
http://www.3gpp.org/ftp/Information/WORK PLAN/Description Releases/.
[13] Overview of 3GPP Release 5/ 6 / 7 /8 . . . ; Available at
http://www.3gpp.org/ftp/Information/WORK PLAN/Description Releases/.
& Sons.
61
CHAPTER
WCDMA AIR INTERFACE
The main difference between GSM of second generation and UMTS of third genera-
tion is the air interface technology. The switches, routers and databases in the core
network behave in the the same manner in both the technologies. Therefore, un-
derstanding the concepts of UMTS air interface is a very important part in learning
3G fundamentals. This module tries to cover the basic principles about spreading,
code multiplexing and physical layer processing of the data in UMTS.
3.1 Duplex Methods

Because commercial mobile networks are used to send as well as receive data from
UE, they are duplex systems. This is different from simplex transmission as in TV
or radio broadcast where the user only receives but does not send data. Hence, in
mobile communication we use full-duplex. There are two popular methods which
can be used to separate the signals from UE to Node B, Uplink and Node B to UE,
Downlink. They are:
FDD: As shown in figure 3.1, in FDD scheme, user sends his data on one frequency
and receives on another one. These 2 frequencies must be separated by several
MHz. FDD can only operate in paired band. For every uplink frequency, there
62
3.2. MULTIPLE ACCESS TECHNOLOGIES 63
Figure 3.1: Popular duplexing methods - FDD & TDD
is a downlink frequency. This pair of frequencies forms a carrier. For example,

GSM is a FDD system.
TDD: In contrast with FDD, TDD operates in an unpaired spectrum. The same
frequency is used for both uplink and downlink. This is achieved by organizing
the time into time slots and assigning some lots to uplink and remaining slots
for downlink.
According to 3GPP, UMTS can operate both in FDD and TDD mode. But FDD has
been a more popular choice among the commercial telecom operators. According
to common practice and usage, when someone speaks of “UMTS”, we undoubtedly
assume that UMTS-FDD is referred to. But for TDD, it must be explicitly men-
tioned that we are referring to the UMTS-TDD version. Both technologies have
their advantages and disadvantages but we will investigate only the FDD part in
this book due to its popularity.
3.2 Multiple Access Technologies

In the previous section, we saw 2 methods to separate the uplink and downlink
streams. Now, if we imagine a cell with several users simultaneously accessing the
64 CHAPTER 3. WCDMA AIR INTERFACE
Figure 3.2: Popular multiple-access methods
services, their individual signals will interfere with each other and cause distur-
bance in the transmission and reception. In order to avoid or minimize the effect of
interference from other users, several multiple access schemes have been designed.
In other words, multiple access technique is a method by which multiple users can
share the same radio resources. This sharing can be in time domain, frequency
domain or in power domain. Hence, we have several options for multiple access
schemes. Some of them are briefly1 mentioned here:
3.2.1 Frequency Division Multiple Access

FDMA is a multiple access scheme where the total frequency spectrum is divided
into small radio channels and each user is allocated one radio channel. This is one of
the oldest radio techniques which was used in 1G cellular systems like NMT, C-Nets,
AMPS etc. Figure 3.2 shows FDMA principle in the left upper subfigure.
In FDMA, several users use the radio resources at their allocated section of frequency
spectrum.
1
The discussion is kept very short because generally these topics are well known.
3.3. UMTS OPERATING BANDS AND SPECTRUM 65
3.2.2 Time Division Multiple Access
In the TDMA multiple access scheme, the time resource is structured into TDMA
frames and each frame is further divided into time slots. Each user is allocated one
time slot every TDMA frame. Therefore, in TDMA we can accommodate only as
many users as the number of time slots per TDMA frame. In GSM, such a scheme
with 8 slots per frame is used.
In TDMA, several users use the radio resources at their scheduled time intervals.
3.2.3 Code Division Multiple Access
CDMA is the main topic to be discussed in this chapter because air interface tech-
nology used in UMTS air interface is based on Wideband CDMA.
In CDMA, several users are allowed to use the same frequency resource at the same
time but their signals are separated by codes. Theoretically, we can accommodate
as many simultaneous users as the number of codes. It sounds like magic but
this scheme has its limitation. The communication with acceptable quality can be
maintained as long as the interference at the receiver is within allowed limits. If
the interference rises, the transmitter should increase the power to fight against the
disturbance. But the power of UE and Node B are finite. Therefore, CDMA systems
are also called as interference limited systems.
3.2.4 Orthogonal Frequency Division Multiple Access
Orthogonal FDMA is a relatively new technology where different frequencies are

allocated to different users. Therefore, it is a frequency division multiple access
scheme but with one basic difference. In OFDMA, the allocated frequency is further
divided into smaller sub-carriers which makes it very robust against inter-symbol
interference, multipath fading and other radio disturbances.
Radio access technology used in E-UTRAN (LTE), WiMAX and WLAN is based
on OFDMA principles.
3.3 UMTS operating Bands and Spectrum
Source: 3GPP TS 25.104 ; Base Station (BS) radio transmission and

reception (FDD)
The spectrum allocated for IMT-2000 deployment was declared in WRC-92 which
included the bands shown in figure 3.3. This is a country-independent data which
might suit one geographical region but may be conflicting with other radio systems
in another part of world. The allocated spectrum had separate frequency regions of
terrestrial communication systems and mobile satellite communication systems.
Figure 3.3: Operating frequency bands for IMT-2000 System (BAND I)
In the same figure (3.3), the core band of UMTS has also been illustrated which
is chosen by 3GPP for the UMTS deployment in Europe. This figure shows both
the TDD and FDD regions of the UMTS core band. Other than the Core Band or
BAND I, UTRA/FDD is designed to operate in the paired bands shown in table
3.1. Nominal channel spacing is 5 MHz. The channel raster is 200 kHz for all bands,
which means that the center frequency must be an integer multiple of 200 kHz. This
rule is generally true but for some specific bands, the center frequencies are shifted
by 100 kHz relative to the channel raster. These frequencies are explicitly listed in
table 5.0 & 5.1 in 3GPP TS 25.104.
In UTRAN FDD Band I, there is 2 × 60 MHz. Hence, there can be 12 FDD carriers
in this band. For example, the center of the first carrier will be 1922.4 MHz for
uplink and 2112.4 MHz for DL. Similarly, the center of the last carrier in this band
is at 1977.6 MHz for uplink and 2167.6 MHz for downlink.
3.4 Timing in WCDMA

In UMTS, the smallest time unit is called TChip which is equal to 3.84 1Mcps = 0.26 µs.
Quite often, other important time units are specified as multiples of TChip . The three
3.4. TIMING IN WCDMA 67
Operating Band Uplink Freq. Downlink Freq. TX-RX

Freq.
separation
I 1920-1980 MHz 2110 -2170 190 MHz
II 1850 -1910 MHz 1930 -1990 MHz 80 MHz
III 1710-1785 MHz 1805-1880 MHz 95 MHz
IV 1710-1755 MHz 2110-2155 MHz 400 MHz
V 824 - 849MHz 869-894 MHz 45 MHz
VI 830-840 MHz 875-885 MHz 45
VII 2500 - 2570 MHz 2620 - 2690 MHz 120 MHz
VIII 880 - 915 MHz 925 - 960 MHz 45 MHz
IX 1749.9 - 1784.9 MHz 1844.9 - 1879.9 MHz 95 MHz
X 1710-1770 MHz 2110-2170 MHz 400 MHz
XI 1427.9 - 1447.9 MHz 1475.9 - 1495.9 MHz 48 MHz
XII 699 - 716 MHz 729 - 746 MHz 30 MHz
XIII 777 - 787 MHz 746 - 756 MHz 31 MHz
XIV 788 - 798 MHz 758 - 768 MHz 30 MHz
XV - XVIII Reserved Reserved -
XIX 830 845 MHz 875 -890 MHz 45 MHz
XX 832 - 862 MHz 791 - 821 MHz 41 MHz
XXI 1447.9 - 1462.9 MHz 1495.9 - 1510.9 MHz 48 MHz
Table 3.1: UTRAN FDD Bands, reproduced from 3GPP TS 25.104
most important time units discussed in UMTS & HSPA are illustrated in figure 3.4.
Figure 3.4: Time units used in WCDMA air interface
1. Radio Frame: A radio frame is a processing duration which consists of 15 slots.

The length of a radio frame corresponds to 38400 chips. In other words, a radio
frame is 10 ms long and can accommodate 38,400 chips.
2. Slot: A slot is a duration which consists of fields containing bits. The length of
a slot corresponds to 2560 chips. Compared to the 2G combination of TDMA
frame & Time Slot, 3G uses a combination of Radio Frame & Slot. One Radio
Frame of 3G is further divided into 15 Slots but all the times slots are allocated
to the same users. The main purpose of having Slots in 3G is so that control
information can be sent to the UE at a regular and very fast interval. One
slot is 2/3 ms long.
3. Sub-frame: A sub-frame is the basic time interval for E-DCH and HS-DSCH
transmission and E-DCH and HS-DSCH-related signalling at the physical
layer2 . The length of a sub-frame corresponds to 3 slots (7680 chips).
3.5 Spreading Principles

UMTS air interface is based on code division multiple access scheme where the
bandwidth after spreading is 5 MHz wide. The narrowband signal is converted to
wideband with the help of a spreading code. The exact details of the codes will be
shown in the next section but for the current discussion, they are simply called code.
Figure 3.5 shows 4 users using the same 5 MHz wideband carrier. The time is
organized in 10 ms radio frame. Each user is allowed to transmit or receive in the
entire 10 ms period. Therefore, the users are using the same frequency & time
domain resources. It is natural for them to interfere with each other. In order to
keep the interference to a minimum level, it is desirable that each users uses as little
power as possible. This reduction in power3 is achieved by spreading the whole
energy over a wide frequency band. The spreading technique allows the operator to
simultaneously allocate the same time and frequency resources to many users.
There are two resources in CDMA world, which are (1) code and (2) power. Let us
analyze them one by one:
1. Codes: In general, the users must be identified by codes. A new user cannot be
admitted until there is a code available for him. Hence, the number of active
users can be limited by unavailability of codes.
2
Please note: Prior to the introduction of HSDPA in 3GPP Rel-5, there was no discussion about
sub-frame. Therefore, for R99 channels (DCH, FACH, RACH etc.) the term ‘sub-frame’ has no
significance.
3
Power spectral density
3.5. SPREADING PRINCIPLES 69
Figure 3.5: Principle of Spreading
2. Power: Code itself is not enough to allow a radio connection in CDMA.
2.a In Uplink: In Uplink, the received power at the Node B’s receiver
should be under the manageable limits. If the interference at the receiver
becomes very high, then the desired signal cannot be reconstructed from
the received signal. This is a very common reason for blocking in CDMA
networks. In other words, CDMA systems are interference limited sys-
tems.
2.b In Downlink: In Downlink, the transmitted power of Node B is the
resource which limits the number of subscribers. With each connected
user, Node B needs to spend aome finite power for each active user.
Therefore, in DL Node B transmit power is the shared resource.
Figure 3.6 illustrates how the spreading & despreading mechanism can be used to
suppress interference. After spreading, when the wideband signal is transmitted,
it gets interfered by both narrowband and wideband interference. In the receiver,
during despreading, the narrow band interference gets spread and its power spec-
tral density gets reduced. After despreading, when the output is passed through a
lowpass filter then despreaded data signal can be derived.
The received data signal can be used to regenerate the actual data only if the received
Eb
bit energy is greater than the overall noise energy by at least N o
[dB].
If CDMA is successfully used in commercial networks, it should be robust against
the interference from the other user interference. This principle is illustrated in
figure 3.7. For example, imagine that the transmitter shown in this picture depicts
the transmitter in Node B, which spreads the data for user 1 with code # 1 and
data for user 2 with code # 2. As expected, the spread signal for both the users will
interfere at the radio interface. Now, the User 1 will try to despread the received
Figure 3.6: Spreading and despreading to suppress the interference
signal with code # 1. UE has the knowledge about the codes by prior signalling
with RNC.
As a result of despreading, the data of user 1 can be reconstructed. In the same
figure, we can see that spread signal of user 2 does not get despreaded at the receiver
of UE 1. This is possible if:
• Code # 1 and code # 2 are orthogonal to each other. [AND]
• Codes at the transmitter and receiver are synchronized to each other.
In commercial cellular networks, operators want that one cell should cover a large
geographical area. In other words, communication should be possible between base
station and a distant user equipment. This can be achieved if the sensitivity of
the base station and user equipment is good. While performing despreading, the
receiver can manifold amplify the received signal. This gain is called Processing
gain. Processing gain can be mathematically expressed as:
3.84 Mcps
Processing Gain = 10 · log [dB]
Rbit
3.5. SPREADING PRINCIPLES 71
Figure 3.7: Multiple access using different codes for 2 users
Figure 3.8: Processing gain at the receiver side
Figure 3.9 shows a fast code sequence whose symbol duration is fixed by 3GPP
specifications. This small symbol is called a chip. According to 3GPP, in one

second, there can be 3.84 million such chips. Hence, each chip is 0.26 µs long.
The channelization codes used for spreading always use this fast code. As a result,
the product is always 3.84 Mcps. The bandwidth required to transmit this fast
waveform is also very large. In UMTS, the licensed bandwidth is 5 MHz but the
effective transmission takes place in 3.84 MHz.
Figure 3.9 also illustrates that for various services, the symbol rate can vary but the
chip rate is always constant and fixed.
• For a high bit rate service, the symbol duration is short. Therefore,
the SF is also small.
• For a low bit rate service, the symbol duration is very large and
therefore, the SF is also very high.
1
• In other words Bit Rate ∝
SF
Figure 3.9: Effect of SF on bitrate and symbol duration
3.6 Codes in UMTS

Source: 3GPP 25.213 Spreading and Modulation (FDD)
3.6. CODES IN UMTS 73
According to the definition used by 3GPP TS 25.213, spreading consists of two

operations. The first is the channelization operation, which transforms every data
symbol into a number of chips, thus increasing the bandwidth of the signal. The
second operation is the scrambling operation, where a scrambling code is applied to
the spread signal. Hence, there are two types of codes used in UMTS.
1. Scrambling Codes: Scrambling codes do not perform any spreading of band-

width. These codes are used to super-impose the identity of transmitter on the
physical layer signals. Scrambling codes are not orthogonal. They are derived
using sequence generators consisting of shift registers.
2. Channelization Codes: According to section 4.3.1.1 of 3GPP TS 25.213, the

Channelization codes are the codes which perform spreading of bandwidth.
Therefore, sometimes, these codes are also called as spreading code. Channel-
ization codes define the user bit rate. These codes are Orthogonal Variable
Spreading Factor (OVSF) codes that preserve the orthogonality between a
user’s different physical channels. The OVSF codes can be defined using the
code tree shown in figure 3.10.
The number of chips per data symbol is called the Spreading Factor (SF).
3.6.1 Channelization Code

Channelization Codes have similar properties in DL and UL. As stated earlier,
1
Bit Rate ∝ . Therefore, the user bit rate is defined by the channelization code.
SF
• In UL, Channelization codes are used to separate control and data chan-
nels from the same UE (DPDCH and DPCCH).
• In DL, Channelization codes are is used to separate the users within a
cell.
In order to calculate the L1 data rate for each spreading factor, we use following
formula:
Rchip 3.84 Mcps

Symbol Rate = =
SF SF
It will be explained in the next section that UL modulation is BPSK and DL mod-
ulation is QPSK. Therefore, for the same SF, UL & DL bit rates are different. For
QPSK, one symbol corresponds to two bits whereas in BPSK one symbol equals one
bit only. This concept is illustrated in Table 3.2.
Symbol
[ ]Rate (ksps) bit rate (kbps) on DL bit rate (kbps) on UL
SF Rchip [ 3.84 Mcps ]
= SF = SF
DPCH DPDCH
512 7.5 15 -
256 15 30 15
128 30 60 30
64 60 120 60
32 120 240 120
16 240 480 240
8 480 960 480
4 960 1920 960
Table 3.2: SF and the corresponding L1 bitrate
Figure 3.10: Code Tree for generation of Orthogonal codes
3.6.2 Scrambling Code
As stated earlier in the introduction part, the scrambling codes do not perform
any spreading of bandwidth. These codes are used to super-impose the identity of
transmitter on the physical layer signals. As a result of scrambling, some ‘0’s become
‘1’s and some ‘1’s become ‘0’s, but the time-duration of each chip does not alter.
Hence, the scrambling procedure does not affect the bandwidth of the transmitted
signal. Spreading is achieved by Channelization code alone. The following sections
tries to investigate the usage of scrambling codes in UL and DL.
UL Scrambling Codes
UL Scrambling codes are used as user identity in Uplink. All uplink physical chan-
nels are scrambled with a complex-valued Scrambling code. The dedicated physical
channels may be scrambled by either a long or a short scrambling code.
There are 224 long and 224 short uplink scrambling codes. The usage of long
scrambling codes in UL is very popular. Therefore, in this book we will
only discuss the long codes. The sequence generator used to generate the long
UL scrambling codes is shown in figure 3.11. The shift registers with 24 bit delay
capability and can be used to create 224 − 1 or 16.7 Million UL scrambling codes.
Uplink scrambling codes are assigned by RRC signalling.
Figure 3.11: Configuration of uplink scrambling sequence generator
DL Scrambling Codes
DL (primary) scrambling codes are used as a physical layer cell-id in UMTS. The DL
scrambling codes are generated using the sequence generator shown in figure 3.12.
There are 18 shift registers in the sequence generator. Hence, we can get a total of
218 − 1 = 262, 143 scrambling codes. But not all of the SC are used. Only 8192
DL scrambling codes are allowed in UMTS which are further divided into
512 groups.
Each group contains one primary Scrambling code and 15 secondary
scrambling codes. Figure 3.14 illustrates this arrangement.
The Scrambling code sequences are constructed by combining two real sequences into
Figure 3.12: Configuration of downlink scrambling sequence generator
a complex sequence. Each of the two real sequences are constructed as the position
wise modulo 2 sum of 38400 chip segments of two binary m-sequences generated
by means of two generator polynomials of degree 18. The resulting sequences thus
constitute segments of a set of Gold sequences. The scrambling codes are repeated
for every 10 ms radio frame.
The primary scrambling codes n : n = 16 ∗ i where i = 0 . . . 511

The i:th set of secondary scrambling codes: 16 ∗ i + k, where k = 1 . . . 15
Each cell is allocated one and only one primary Scrambling code. The primary
CCPCH, primary CPICH, PICH, AICH and S-CCPCH carrying PCH shall always
be transmitted using the primary scrambling code. The other downlink physical
channels may be4 transmitted with either the primary scrambling code or a sec-
ondary scrambling code from the set associated with the primary scrambling code
of the cell.
The set of primary scrambling codes is further divided into 64 Scrambling code
groups, each consisting of 8 primary scrambling codes. The j:th scrambling code
group consists of primary scrambling codes 16*8*j+16*k, where j=0..63 and k=0..7.
4
Use of secondary scrambling code is not very popular in practice. Therefore, this book will
further assume that in DL only primary scrambling code is used.
Figure 3.13: Total 8192 DL Scrambling Codes and 512 Primary SC
Figure 3.14: 512 SC divided into 64 Groups of 8 codes each

3.6.3 Summary of Scrambling Codes

In the last few sections, the details about channelization and scrambling codes were
given. Table 3.3 shows a brief summary of the codes in UMTS.
• In UL, the users are separated by using different UL scrambling codes.

There are 224 - 1 = 16.7 Million UL scrambling codes. RNC allocates
one SC to one user at connection setup. SC are unique within one
RNC area. The number of SC available in one RNC are defined by the
hardware capacity of RNC.
• In DL, the cells are separated by DL scrambling codes. There are 512
primary scrambling codes which are organized in 64 code groups having 8
codes per group ( 64 × 8 = 512)). DL SC are planned by radio planners.
3.6.4 Summary of Codes in UMTS

At this point, it is quite normal for the readers to feel confused and lost in details.
Therefore, table 3.3 shows the summary of the previous section by highlighting the
main aspects of the codes used in UMTS.
Scrambling Code Channelization Code

UL: User Id UL: To separate control and data
Usage
channels from UE
DL: Cell Id DL: User Id
Spreading Does not perform spreading Performs spreading
UL : 16.7 Million UL: Depends on the SF ( 256 ,. . . ,
# of codes
4)
DL : 8192 (512 Primary SC and the DL: Depends on the SF (512,. . . , 4)
rest are secondary SC)
Orthogonality Non-orthogonal Orthogonal
UL : There are 2 options UL: 4 to 256 chips
Length
• Option 1: long Codes 38400
chips
• Option 2: Short codes 256 chips
DL: 10 ms (38400 Chips) DL: 4 to 512 chips

Code Genera- Using Shift Register based sequence Using Walsh Code Tree matrix
tion generator
Table 3.3: Main aspects about the codes used in UMTS

3.7. MODULATION 79
3.7 Modulation
The modulation schemes used in UMTS uplink and downlink are illustrated in
figure 3.15. The same figure also shows the codes used in spreading and scrambling.
For example, in UL, we use user-specific scrambling codes and in DL, cell-specific
scrambling code.
Figure 3.15: Spreading and Modulation in UL & DL
• The modulation used in downlink is Quadrature Phase Shift Keying (QPSK)

which involves 2 bits per symbol. For example,
SF = 256 ⇒ 15 ksps = 30 kbps
• The modulation used in uplink is Binary Phase Shift Keying (BPSK ) which
involves 1 bits per symbol. For example,
SF = 256 ⇒ 15 ksps = 15 kbps
Figure 3.15 illustrates the spreading and modulation for the uplink dedicated phys-
ical channels & DL dedicated channel. In Uplink, data modulation is dual branch
QPSK, that is, the I and Q channels are used as two independent BPSK channels.
Copyright Notices
Text about UMTS operating Section 5.4.1 & 5.4.2 of 3GPP TS 25.104
Bands on page 66 v9.6.0
Table 3.1 on page 67 Table 5.0 of 3GPP TS 25.104 v9.6.0
⃝2011.
c TM
Figure 3.11 on page 75 Figure 5 of 3GPP TS 25.213 v 8.4.0

Figure 3.12 on page 76 Figure 10 of 3GPP TS 25.213 v 8.4.0
Text in section 3.6 on page 72 Section 4.1 of 3GPP TS 25.213 v 8.4.0
Text in section 3.6 on page 73 Section 4.3.1.1 of 3GPP TS 25.213 v 8.4.0
Text about UL Scrambling Codes Section 4.3.2.1 of 3GPP TS 25.213 v 8.4.0
on page 75
Text about DL Scrambling Codes Section 4.1 of 3GPP TS 25.213 v 8.4.0
on page 75
Text in section 3.4 on page 66 Section 5 of 3GPP TS 25.211 v 9.1.0
⃝2009.
c TM
BIBLIOGRAPHY
[1] 3GPP TS 25.201 ver. 6.0.0 ;‘Physical layer - General description’
[2] 3GPP TS 25.211 ver. 6.0.0 ;‘Physical channels and mapping of transport chan-
nels onto physical channels (FDD)’
[3] 3GPP TS 25.212 ver. 6.0.0 ;‘Multiplexing and Channel Coding (FDD)’
[4] 3GPP TS 25.213 ver. 6.0.0 ;‘Spreading and Modulation (FDD)’
[5] 3GPP TS 25.214 ver. 6.0.0 ;‘Physical Layer Procedures (FDD)’
[6] 3GPP TS 25.104 ver. 6.0.0 ;‘Base Station (BS) radio transmission and reception
(FDD)’
& Sons.
[8] Chris Johnson, ‘Radio Access Networks For UMTS ; Principles And
Practice’ , John Wiley & Sons.
81
CHAPTER
LOGICAL, TRANSPORT & PHYSICAL

CHANNELS
In order to master the fundamentals of 3G radio transmission and reception, it is

essential to get acquainted with the channels used in UMTS and HSPA. Channels
are simply a method to organize the information into some categories depending
on some common aspects. This chapter is written to provide the most essential
details about them. According to UTRAN specifications, there are three hierarchies
of channels.
• Logical channels
• Transport channels
• Physical channels
The concept of channel was used in GSM as well. In 2G, there are logical and
physical channels. The concept of Transport channel is new in UMTS. This page
tries to illustrate the difference between the three types of channels and later in this
chapter more details can be found about each of them.
A Logical channel is used to describe what type of information is being

transported by it (e.g., control signalling or user data).
82
4.1. CHRONOLOGY: FIRST 3G AND THEN 3.5G 83
A Transport channel is used to describe the characteristics with which it

transports the information carried by it (e.g., using common channels of the
cell or dedicated channels especially allocated to one user).
A Physical channel is used to describe the physical aspects of it (e.g., fre-

quency, scrambling code, channelization code and slot format).
4.1 Chronology: First 3G and then 3.5G

As we all know, 3G is constantly evolving and getting better with each 3GPP release.
Therefore, we should study the changes in chronological order. It is highly recom-
mended that readers must try to learn channels in the same order. The learning
becomes much easier if we break the whole process in three steps.
Step 1, R99 Channels: R99 channels are the topic of this particular chapter.
Here, we will discuss common control channels and dedicated channels of
UMTS.
Step 2, HSDPA Channels: HSDPA channels will be discussed in chapter 7. All

the channels which have something to do with HSDPA, start with HS-. There
are only 3 new channels introduced in Rel-5 for HSDPA operation.
Step 3, HSUPA Channels: HSUPA channels will be discussed in chapter 8. All

the channels which have something to do with HSUPA, start with E-. There
are only 5 new channels introduced in Rel-6 for HSUPA operation.
As we can see, there will be a lot of channels to learn and discuss. Therefore, we
will start building our knowledge on the strong foundation of R99 UMTS channels.
4.2 Logical Channels

Source: 3GPP TS 25.301, 25.211, 25.212, 25.213
As explained in the first section of this chapter, Logical channels are used to describe
what is being transported. According to 3GPP TS 25.301, logical channels are
divided into two groups:
1. Control channels: for the transfer of control plane information, &

84 CHAPTER 4. LOGICAL, TRANSPORT & PHYSICAL CHANNELS
2. Traffic channels: for the transfer of user plane information.
Figure 4.1 illustrates the distribution of uplink and downlink logical channels. It can
be seen that there are 6 logical channels in UMTS, 2 for traffic and 4 for control plane.
Some of these channels are only in DL e.g., (BCCH, PCCH and CTCH) whereas the
other 3 channels are bidrectional (CCCH, DCCH and DTCH). Splitting the analysis
in DL and UL makes it much easier to understand.
While describing the logical channels, we do not discuss the issues about power, bit
rates, bit error rate, block error rates, etc. At this level, we only consider the nature
of data being transported.
Figure 4.1: UL & DL Logical channels
4.2.1 Logical Channels for Control Plane Information

In this section, all 6 logical channels are described.
1. BCCH, Downlink only ↓ BCCH channel is used for system control informa-
tion broadcasting. It exists only in the downlink.
4.2. LOGICAL CHANNELS 85
2. PCCH, Downlink only ↓ PCCH channel is used to transmit the paging mes-
sages. RNC can generate paging after getting the paging requests from core
network or generate the paging by itself to page the packet-switched users who
are in RRC power saving stand-by states.
3. CCCH, Uplink and Downlink ↕ CCCH is a bi-directional channel. It carries

control information between the network and the UE. This channel is used by
those UEs which access a new cell after cell re-selection as well as by UEs
which do not have a RRC connection.
4.DCCH, Uplink and Downlink ↕ This is a point-to-point bi-directional chan-

nel which is set up in the RRC connection establishment procedure. It carries
dedicated control information between RNC and the UE.
4.2.2 Logical Channels for User Plane Information

5. CTCH, Downlink only ↓ This point-to-multipoint channel is used to carry
dedicated information in the downlink to all or a group of UEs. For example,
stock market updates, sports results, weather updates, business promotions
and service area broadcast.
6. DTCH, Uplink and Downlink ↕ DTCH is a dedicated point-to-point chan-

nel which can be used in the uplink as well as in the downlink. This channel
carries user traffic like CS speech, video, streaming video, emails with and
without attachments, file transfer etc.
As a quick summary, table 4.1 lists all the logical channels. In this table, we can see
which channels are used to carry control data and which channels for traffic. The
same table also shown whether the channels are unidirectional or bidirectional.
Logical Channels for Control Plane

1. BCCH Broadcast Control Channel DL only
2. PCCH Paging Control Channel DL only
3. CCCH Common Control Channel UL & DL
4. DCCH Dedicated Control Channel UL & DL
Logical Channels for User Plane
5. CTCH Common Traffic Channel DL only
6. DTCH Dedicated Traffic Channel UL & DL
Table 4.1: List of all Logical channels in UMTS

4.3 Transport Channels

Source: 3GPP TS 25.301, 25.302, 25.321
The main task of a transport channel is to describe the characteristics with which
the data will be transported. At this moment, it is quite normal for the readers to
doubt why do we need transport channels?
As we have seen in the previous section, there is only one logical channel DTCH for
describing the one-to-one user traffic, for example, voice, video, streaming and NRT
data. We cannot expect the transport conditions of CS voice and FTP file transfer
be same. Typically, there are the following preferences:
• CS Voice needs low but constant bit rate with strict delay requirements. Voice
service is insensitive to bit error rates and we do not re-transmit the speech
frame in case of errors.
• File transfer requires high bit rate which can tolerate the bit-rate fluctua-
tions. The end-to-end delay can also be flexible but file transfer is very strict
about bit errors which are achieved using negative acknowledgements and re-
transmissions.
Furthermore, the packets sessions can be of various natures:
1. Packet session with small amount of infrequent data transmission.
2. Packet session with high amount of data transmission.
3. Packet session with small amount of packets but very frequently transmitted.
Medium Access Control Layer (MAC) in RNC & UE is responsible for map-
ping logical channels to transport channels. This procedure is illustrated in
figure 4.2.
Hence, one can argue that UMTS needs different types of transport channels to
fulfill the different types of needs. There are 2 types of transport channels defined
for UMTS.
• 1. Common transport channels
• 2. Dedicated transport channels

4.3. TRANSPORT CHANNELS 87
Figure 4.2: UL & DL Transport channels ; Logical Transport channel mapping
Common Transport Channels

BCH Broadcast Channel DL only
PCH Paging Channel DL only
FACH Forward Access Channel DL only
RACH Random Access Channel UL only
Dedicated Transport Channels
DCH Dedicated Channel UL & DL
Table 4.2: List of all Transport channels in UMTS

1
4.3.1 Common Transport Channels

In the common transport channels, if UE addressing is required, then explicit ad-
dressing is used.
BCH BCCH V BCH. (Logical channel BCCH is mapped on the transport channel
BCH.) The Broadcast Channel (BCH) is a downlink transport channel that is
used to broadcast system- and cell-specific information. The BCH is always
transmitted over the entire cell and has a single transport format.
PCH PCCH V PCH. (Logical channel PCCH is mapped on the transport channel
PCH.) The Paging Channel (PCH) is a downlink transport channel. The
PCH is always transmitted over the entire cell. The transmission of the PCH is
associated with the transmission of physical-layer generated Paging Indicators,
to support efficient sleep-mode procedures.
RACH RACH is a well-known name for people who are familiar with 2G. In GSM,
RACH is used to make the initial access to the network and ask for dedicated
signalling resources. Here in 3G also, the same functions are performed by
RACH channel.
But in UMTS, RACH can also be used to transmit small amount of NRT PS
data in uplink2 . Hence, RACH can generate some revenue for the operator.
FACH In 2G, the answer to RACH is received on Access Grant Channel AGCH.
In UMTS, the same task has been given to Forward Access Channel (FACH).
Hence, FACH is used to inform the users about allocated dedicated signalling
resources in response to the RACH request.
But in UMTS, FACH can also be used to transmit small amount of NRT PS
data in downlink3 . Hence, FACH can generate some revenue for the operator.
4.3.2 Dedicated transport channels

Dedicated Channel DCH is a transport channel allocated to one UE. It can be
used either for uplink or downlink. This channel is controlled through the inner
power control. DCH bit rate is variable depending on the channel conditions
and the allocated bearer. Bit rate variations can be performed every 10 ms.
4.4 Physical Channels

According to 3GPP TS 25.211, a physical channel is defined by:
• a specific carrier frequency,
• scrambling code,
• channelization code,
2
3G RACH = 2G RACH + Small amount of UL NRT PS traffic.
3
3G FACH = 2G AGCH + Small amount of DL NRT PS traffic.
4.4. PHYSICAL CHANNELS 89
• time start & stop (giving a duration) &
• on the uplink, relative phase (0 or π/2).
Scrambling and channelization codes are specified in chapter 3. Time durations are
defined by start and stop instants, measured in integer multiples of chips. Suitable
multiples of chips also used in specification are:
Figure 4.3: Slot, Subframe and Radio Frame as used in WCDMA
1. Radio frame: A radio frame is a processing duration which consists of 15 slots.

The length of a radio frame corresponds to 38400 chips or 10 ms.
2. Slot: A slot is a duration which consists of fields containing bits. The length of
a slot corresponds to 2560 chips or 2/3 ms.
3. Sub-frame: A sub-frame is the basic time interval for E-DCH and HS-DSCH
transmission and E-DCH and HS-DSCH-related signalling at the physical
layer. The length of a sub-frame corresponds to 3 slots (7680 chips) or 2
ms.
Physical layer (L1) in Node B & UE is responsible for mapping transport

channels to physical channels. This procedure is illustrated in figure 4.4.
As shown in figure 4.4, there are some physical channels which do not have any
corresponding transport or logical channels. These channels are, in fact, physical
signals which are generated by physical layer of transmitter (e.g., Node B) and used
by the physical layer of the receiver (e.g., UE). The scope of these channels are
restricted to only physical layer. These physical channels exist to support some
special functions of physical layer e.g., synchronization, channel estimation etc.
The default time duration for a physical channel is continuous from the instant
when it is started to the instant when it is stopped. Physical channels that are not
continuous will be explicitly described.
UMTS has been designed in such a way that physical layer maps various transport
channels to physical channels. When more than one transport channel is multi-
plexed, this composite channel is called composite coded transport channel (CC-
TrCH). This composite transport channel (CCTrCH) is mapped to the data part of
a physical channel. In addition to data parts, there also exist control parts which
are locally generated and inserted by the physical layer.
Figure 4.4: UL & DL Physical channels ; Transport Physical channel mapping
In chapter 3, the basics about channelization and scrambling were discussed. The
unique combinations of these codes works as the identity of various physical channels.
Example: Let us consider two physical channels and investi-

gate their physical layer attributes. First channel is the Primary-
common pilot channel (P-CPICH) of the cell and the second one a DL
dedicated physical channel (DPCH) allocated to a specific user.
• P-CPICH is a physical channel that uses

– Frequency FDL , that has been assigned to the cell by radio

planner,
– Scrambling code SCCell , assigned by the planner while radio
planning,
– & the Channelization Code4 , CC256, 0 .
• Downlink DPCH allocated to a particular user is a physical channel
that uses
– Frequency FDL , that has been assigned to the cell by radio
planner,
– Scrambling code SCCell , assigned by the planner while radio
planning,
– & the Channelization Code5 , CCSF, Code Number which is allo-
cated by RNC at the time of call or session setup.
There are a lot of physical channels defined for UMTS. In order to make the under-
standing easier, we will discuss them in four groups:
1. UL Common Channels: PRACH
2. UL Dedicated Channels: DPDCH and DPCCH
3. DL Common Channels: P-SCH, S-SCH, P-CPICH, P-CCPCH, S-CCPCH,

AICH and PICH
4. DL Dedicated Channels: DPCH
Please refer to figure 4.5 and table 4.3 to keep an overview about the physical
channels. There is only one UL common channel and there are 2 UL dedicated
channels. Similarly in DL, there are 7 common channels and one dedicated channels.
4.4.1 UL Common Channel

There is only one UL common physical channel PRACH. The next section explains
more details about it.
4
This is a standard code which is used in all UMTS networks for primary-common pilot channel
(P-CPICH).
5
Here SF is decided based on the allocated bit rate while code number is a random choice based
on the codes availability.
DL Common Channels UL Common Channels

P-SCH Primary Synchronization Ch.
S-SCH Secondary Synchronization Ch.
P-CPICH Primary Common Pilot Ch.
P-CCPCH Pri. Common Control Physical Ch. PRACH Physical Random Access Ch.
S-CCPCH Sec. Common Control Physical Ch.
PICH Paging Indication Channel Ch.
AICH Acquisition Indication Channel Ch.
DL Dedicated Channels UL Dedicated Channels

DPDCH Dedicated Phy. Data Ch.
DPCH Dedicated Physical Channel
DPCCH Dedicated Phy. Control Ch.
Table 4.3: List of all R99 Physical channels
Figure 4.5: Summary of all R99 Channels
Physical Random Access Channel (PRACH)
In section 4.3, we discussed about an UL transport channel RACH. Physical layer

of UE maps this transport channel to a physical channel called ‘Physical Random
Access CHannel (PRACH)’. Therefore, PRACH is used by user for making initial
contact with the UTRAN and also to transmit some small amount of non-real time
(NRT) data.
PRACH physical channel can be used to carry transport channel RACH, which
in turn, carries logical channel DTCH and CCCH.
Logical Ch. V Transport Ch. V Physical Ch.

CCCH V RACH V PRACH
DTCH V RACH V PRACH
While making the initial access to UTRAN, UE has no idea about the amount the
transmitted power which is sufficient to reach Node B. Therefore, the UE uses a
mechanism called Open Loop Power Control. This mechanism is explained in full
details in chapter 5 in section 5.7.1. This procedure is illustrated in figure 4.6.
Figure 4.6: PRACH procedure in UMTS
In short, this procedure can be summarized as following.
Step 1: UE transmits a PRACH preamble with a very small power which is calcu-
lated by UE, based on path loss calculations and some system parameters.
Step 2: UE waits for the response to this preamble on a DL channel called ‘Acqui-
sition Indication Channel’ (AICH). At this point, 3 scenarios can take place
which are explained in the step 3-a, 3-b & 3-c.
Step 3-a: If there is a positive response from Node B on AICH, UE sends the
PRACH message part. Using this message, UE informs RNC about its inten-
tions and asks for dedicated resources.
Step 3-b: If there is no response from Node B on AICH, then UE ramps up the
transmission power and sends another preamble. UE keeps on ramping its
preamble power until it hears a reply from Node B.
Step 3-c: If there is a negative response from Node B on AICH, UE aborts the
random access procedures.
The preamble is a sequence of 16 chips which are repeated 256 times. Hence, the
length of a PRACH preamble is 256 × 16 = 4096 chips. Table 4.4 shows all the 16
preamble signature sequences defined by 3GPP. This table can be found in 3GPP TS
25.211. Operators can define how many and which preambles are allowed to be used
in a cell and broadcast this information using system information. UE randomly
selects one of the allowed preamble signatures and forms its preamble.
Preamble
Sequence
Signature
P0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
P1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1 1 -1
P2 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
P3 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1
P4 1 1 1 1 -1 -1 -1 -1 1 1 1 1 -1 -1 -1 -1
P5 1 -1 1 -1 -1 1 -1 1 1 -1 1 -1 -1 1 -1 1
P6 1 1 -1 -1 -1 -1 1 1 1 1 -1 -1 -1 -1 1 1
... ...
P14 1 1 -1 -1 -1 -1 1 1 -1 -1 1 1 1 1 -1 -1
P15 1 -1 -1 1 -1 1 1 -1 -1 1 1 -1 1 -1 -1 1
Table 4.4: PRACH preamble signatures
4.4.2 DL common Channel

There are 7 DL common channels which are referred to as R99 common channels.
The next sections discuss some essential details of these channels. Each section is
numbered from one to seven for convenience.
1. P-SCH
At switch-on, UE looks for P-SCH and tries to identify the beginning of a

time slot by using a globally unique code called primary synchronization
code. Hence, P-SCH is the starting point of all UMTS activities.
The Synchronization Channel (SCH) is a downlink signal used for cell search. The
SCH consists of two sub channels, the Primary and Secondary SCH. The 10 ms
radio frames of the Primary and Secondary SCH are divided into 15 slots, each of
length 2560 chips. Figure 4.8 illustrates the structure of the SCH radio frame.
P-SCH is transmitted for only first 10% of each slot. One slot corresponds to 2/3 ms
or 2560 chip. Therefore, P-SCH consists of a unique code, Primary Synchronization
Code (PSC) which is modulated and transmitted at the beginning of every slot.
This is illustrated in figure 4.8. The PSC is the same for every cell in the UMTS
system irrespective of the country or operator. The value of code itself goes beyond
the scope of our discussion. If you are interested in knowing more about the PSC,
please refer to section 5.3.3.5 of 3GPP TS 25.213.
Figure 4.7: Timing of Synch. Channels; sent on the first 10 % of every slot
At the beginning, UE is not synchronized to the Node B timing. Therefore, it is

impossible to perform spreading and scrambling. Hence, P-SCH is sent without any
spreading. In other words, P-SCH does not consume any channelization code.
2. S-SCH
After finding the beginning of Slot using P-SCH, UE searches for S-SCH and
tries to identify the beginning of radio frame by using a sequence of sec-
ondary synchronization code. This sequence is shared by all cells belong-
ing to that scrambling code group.
Slot #
SC Group
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Group 0 1 1 2 8 9 10 15 8 10 16 2 7 15 7 16
Group 1 1 1 5 16 7 3 14 16 3 10 5 12 14 12 10
Group 2 1 2 1 15 5 5 12 16 6 11 2 16 11 15 12
Group 3 1 2 3 1 8 6 5 2 5 8 4 4 6 3 7
Group 4 1 2 16 6 6 11 15 5 12 1 15 12 16 11 2
Group 5 1 3 4 7 4 1 5 5 3 6 2 8 7 6 8
...
.. ...
.
...
Group 61 9 10 13 10 11 15 15 9 16 12 14 13 16 14 11
Group 62 9 11 12 15 12 9 13 13 11 14 10 16 15 14 16
Group 63 9 12 10 15 13 14 9 14 15 11 11 13 12 16 10
Table 4.5: Table 4: Allocation of SSCs for secondary SCH (from TS 25.213)
Just like P-SCH, the Secondary SCH is also transmitted in the first 10 % of each
time slot only. The information transmitted on S-SCH repeats after every 15 slots.
Therefore, S-SCH is transmitting a unique sequence of secondary synchronization
codes. These sequences are well defined in 3GPP TS 25.2136 .
SSC is a 256 chip long sequence and there are only 16 Secondary Synchronization
Codes (SSC). By arranging them in different order, different sequences could be
formed. As we know, there are 64 primary scrambling code groups. Therefore,
there are only 64 sequences defined for secondary synchronization codes, as shown
in table 4.5.
From table 4.5, one can say “if a cell belongs to scrambling code group # 0,
the it will broadcast SSC # 1 on slot #0, SSC # 1 on slot # 1, . . . , SSC # 16
on slot # 14 of S-SCH channel.” Similarly for a cell belonging to scrambling
code group # 63, S-SCH will broadcast SSC # 9 on slot # 0, , SSC # 12 on
slot # 1, . . . , SSC # 10 on slot # 14. This principle is illustrated in figure
4.8.
Just like P-SCH, S-SCH is also transmitted without any spreading. Hence, S-SCH
also does not consume any channelization code.
This sequence on the Secondary SCH indicates which of the code groups the cell’s
downlink Scrambling code belongs to. In the cell-search procedure, from 512 options
6
3GPP TS 25.213, section ’Code allocation of SSC’
Figure 4.8: Content of Primary and Secondary SCH ; PSC and SSC
UE has narrowed down to 8. There are 8 cells which belong to one SC group.
Therefore, the information on S-SCH is the same in all the cells of one SC Group.
4.5 is copied from 3GPP TS 25.213.
As shown in figure 4.9, the radio planners have two choices while allocating SC to a
new cell.
Minimize the # of SC Groups: In this scheme, the neighbouring cells are allo-
cated the SC from the same group. Once the SC in that group are all used,
then they start with the next group. This scheme is shown as Option 1 in
figure 4.9.
Minimize the # of SC Groups: In this scheme, the neighboring cells are allo-
cated the SC from two different groups. When all 64 Groups have been used,
then they go to the first group again and pick the next SC from that group,
and so on. This is shown as Option 2 in figure 4.9.
Figure 4.9: Cells belonging to the same SC group can be adjacent or distant
3. Primary Common Pilot Channel (P-CPICH)
P-CPICH, or simply ‘Pilot channel’, is probably the most commonly dis-

cussed channel by radio planners and optimizers. P-CPICH is used for SC
identification and channel estimation. If this channel’s received level is not
satisfactory, UE tries for cell reselection or handover. P-CPICH is measured
by 2 quantities, CPICH RSCP [dBm] & CPICH Ec/No [dB].
The Primary Common Pilot Channel (P-CPICH) has the following characteristics:
• The same channelization code is always used for the P-CPICH (Cch,256,0)7 ,
• The P-CPICH is scrambled by the primary scrambling code of the cell,
• There is one and only one P-CPICH per cell, and
• The P-CPICH is broadcasted over the entire coverage area of the cell.
Due to its fixed SF (256), the bit rate of this DL control channel is also fixed.
P-CPICH can carry 30 kbps information.
7
Cch,256,0 = [1 1 1 1 1 1 1 1 1 1 . . . 1 1 1 1], or 256 chips long sequence of all 1’s
Figure 4.10: Primary Common Pilot Channel
The Primary CPICH is a phase reference for the following downlink channels: SCH,
Primary-CCPCH, AICH, PICH and the Secondary-CCPCH. By default, the Pri-
mary CPICH is also a phase reference for downlink DPCH.
4. P-CCPCH
Although P-CCPCH is a complicated name but it is simply a physical channel

which is used to bring system information from UTRAN to UE.
CCCH V BCH V P-CCPCH
The Primary CCPCH is a DL control channel which has a fixed SF=256 & a fixed
rate 30 kbps. This downlink physical channels used to carry the BCH transport
channel (system information).
As shown in figure 4.11, the Primary CCPCH is not transmitted during the first
256 chips of each slot. Instead, Primary SCH and Secondary SCH are transmitted
during this period. Hence, P-CCPCH has an activity factor of 90% which reduces
the effective bit rate to 27 kbps. System information is organized in blocks known
as System Information Block or SIB # N where N = 1, 2, 3,. . . .
5. S-CCPCH
S-CCPCH can be compared to Swiss Army Knife which is one tool that
perform several functions.
BCCH V FACH V S-CCPCH

Figure 4.11: Primary-CCPCH Structure: ON & OFF periods
DCCH V FACH V S-CCPCH

DTCH V FACH V S-CCPCH
CTCH V FACH V S-CCPCH
CCCH V FACH V S-CCPCH
and
PCCH V PCH V S-CCPCH
S-CCPCH physical channel carries FACH and PCH transport channels. There
could be 1, 2 or more S-CCPCH per cell.
The Secondary CCPCH is used to carry the FACH and PCH. The frame structure
of the Secondary CCPCH is shown in the figure 4.12 above.
S-CCPCH can have a spreading factor in a range from 256 to 4. As usual, the used
spreading factor decides the total number of bits per downlink Secondary CCPCH
slot.
The FACH and PCH can be mapped to the same or to separate Secondary CCPCHs.
By having separate S-CCPCHs for FACH & PCH, the physical layer overhead in-
creases but the paging & FACH capacity can be increased.
• The main difference between a S-CCPCH and a downlink dedicated physical

channel (DPCH) is that an S-CCPCH is not inner-loop power controlled.
• The main difference between the Primary and Secondary CCPCH is that the
transport channel mapped to the Primary CCPCH (BCH) can only have a
fixed predefined transport format combination, while the Secondary CCPCH
support multiple transport format combinations using TFCI.
Figure 4.12: Secondary Common Control Physical Channel
Figure 4.13: Paging Process in UMTS; First Paging Indication & then Paging
6. PICH
PICH is a wake-up call which carries either ‘1’ or ‘0’. Each idle mode UE
keeps on monitoring PICH on periodic intervals.
If PICH = ‘1’: UE wakes up and reads the PCH on S-SCCPCH which fol-
lows 3 slots after PICH.
If PICH = ‘0’: UE stays idle and checks PICH on the next PICH occasion.
Figure 4.13 illustrates the two step paging process in UMTS. First the UEs in sleep-
ing mode wake up and read the paging indicator channel (PICH). If there is a paging
indicator, they read the S-SCCPH and decode the paging message which carries UE
identity (e.g., IMSI).
The Paging Indicator Channel (PICH) is a fixed rate (SF=256) physical channel used
to carry the paging indicators. The PICH is always associated with an S-CCPCH
to which a PCH transport channel is mapped.
Figure 4.14 illustrates the frame structure of the PICH. One PICH radio frame of
length 10 ms consists of 300 bits (b0, b1, . . . ,b299). Of these, 288 bits (b0, b1, . . . ,
Figure 4.14: Slot format of PICH for Np = 18, 36, 72 and 144
b287) are used to carry paging indicators. The remaining 12 bits are not formally
part of the PICH and shall not be transmitted.
In each PICH frame, Np paging indicators, where Np =18, 36, 72, or 144.
Further, the PI calculated by higher layers is associated with the value of the paging
indicator Pq. If a paging indicator in a certain frame is set to “1” it is an indication
that UEs associated with this paging indicator and PI should read the corresponding
frame of the associated S-CCPCH.
7. AICH
AICH channel is used to inform UE that its PRACH preamble has been ac-
quired by Node B. From this, UE concludes that the currently used trans-
mission power is sufficient to communicate with Node B. At this point, Open
Loop Power Control is finished.
AICH is a common DL channel whose operation is closely related to UL PRACH

channel. As shown in figure 4.6, the response to the successful PRACH preamble
is sent on the AICH channel. Hence, AICH is a channel that carries Acquisition
Indicators (AI). The Acquisition Indicator channel (AICH) is spreaded by a fixed
SF = 256. Acquisition Indicator AIs corresponds to signature ‘s’ on the PRACH.
AICH is aligned with Primary CPICH for the phase reference and timing.
Figure 4.15 illustrates the structure of the AICH. The AICH consists of a repeated
sequence of 15 consecutive access slots (AS), each of length 5120 chips. Each access
slot consists of two parts:
Figure 4.15: Acquisition Indication Channel
Acquisition-Indicator (AI) part: an Acquisition-Indicator (AI) part consisting

of 32 real-valued symbols a0 , . . . , a31 .
No Transmission part: For last 1024 chips AICH is switched off8 .
According to 3GPP TS 25.211, the real-valued symbols, aj are given by
∑
15
aj = AIs · bs,j (4.1)
s=0
In equation 4.1, there are two terms on right hand side, AIs and bs,j . Let us inves-
tigate more about them step-by-step.
1. AIs : AI can have 3 values:

• If an Acquisition Indicator is set to +1, it represents a positive acknowl-
edgement.
• If an Acquisition Indicator is set to -1, it represents a negative acknowl-
edgement.
• 0
2. bs : bs is chosen depending on the signature used by UE on PRACH preamble
using table 4.6 which has been defined by 3GPP9 .
The real-valued symbols, aj , are spread and modulated in the same fashion as bits
when represented in +1, -1 form.
8
PRACH Preamble is also 256 × 16 = 4096 chips
9
3GPP TS 25.211
CHAPTER 4. LOGICAL, TRANSPORT & PHYSICAL CHANNELS
S bs,j , where j= 0, 1, 2, . . . , 31
0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1
2 1 1 1 1 -1 -1 -1 -1 1 1 1 1 -1 -1 -1 -1 1 1 1 1 -1 -1 -1 -1 1 1 1 1 -1 -1 -1 -1
3 1 1 -1 -1 -1 -1 1 1 1 1 -1 -1 -1 -1 1 1 1 1 -1 -1 -1 -1 1 1 1 1 -1 -1 -1 -1 1 1
4 1 1 1 1 1 1 1 1 -1 -1 -1 -1 -1 -1 -1 -1 1 1 1 1 1 1 1 1 -1 -1 -1 -1 -1 -1 -1 -1
5 1 1 -1 -1 1 1 -1 -1 -1 -1 1 1 -1 -1 1 1 1 1 -1 -1 1 1 -1 -1 -1 -1 1 1 -1 -1 1 1
6 1 1 1 1 -1 -1 -1 -1 -1 -1 -1 -1 1 1 1 1 1 1 1 1 -1 -1 -1 -1 -1 -1 -1 -1 1 1 1 1
7 1 1 -1 -1 -1 -1 1 1 -1 -1 1 1 1 1 -1 -1 1 1 -1 -1 -1 -1 1 1 -1 -1 1 1 1 1 -1 -1
8 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
9 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1
10 1 1 1 1 -1 -1 -1 -1 1 1 1 1 -1 -1 -1 -1 -1 -1 -1 -1 1 1 1 1 -1 -1 -1 -1 1 1 1 1
11 1 1 -1 -1 -1 -1 1 1 1 1 -1 -1 -1 -1 1 1 -1 -1 1 1 1 1 -1 -1 -1 -1 1 1 1 1 -1 -1
12 1 1 1 1 1 1 1 1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 1 1 1 1 1 1 1 1
13 1 1 -1 -1 1 1 -1 -1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 -1 -1 1 1 1 1 -1 -1 1 1 -1 -1
14 1 1 1 1 -1 -1 -1 -1 -1 -1 -1 -1 1 1 1 1 -1 -1 -1 -1 1 1 1 1 1 1 1 1 -1 -1 -1 -1
15 1 1 -1 -1 -1 -1 1 1 -1 -1 1 1 1 1 -1 -1 -1 -1 1 1 1 1 -1 -1 1 1 -1 -1 -1 -1 1 1
Table 4.6: AICH Signature patterns
104
4.4.3 UL Dedicated Channels

In the uplink, there are only two dedicated physical channels, the uplink ‘Dedi-
cated Physical Data Channel (uplink DPDCH)’ and the uplink ‘Dedicated Physical
Control Channel (uplink DPCCH)’.
Uplink Dedicated Physical Channel
As stated above, there are 2 dedicated physical channels in UL, the DPDCH and
the uplink DPCCH. The DPDCH and the DPCCH are I/Q code multiplexed which
means they are modulated by carrier waves which have 90 degree phase difference.
Figure 4.16: Slot format of UL DPDCH and DPCCH Channel
1. DPDCH: The uplink DPDCH is used to carry the DCH transport channel.
In other words, DPDCH carries user data and L3 control signalling10 .
According to 3GPP specifications, there could be several DPDCHs per radio
link, but in practice however, we use only one DPDCH per radio link (per
user). This channel has a variable spreading factor which can assume any
value from 256 to 4.
2. DPCCH: As shown in figure 4.16, the uplink DPCCH is carries control informa-
tion which is added by Layer 1. Layer 1 control information contains following
fields:
1. Pre-known pilot bits for channel estimation for coherent detection,

10
Note! It is a common misunderstanding that L3 messages are sent using DPCCH. In fact
DPCCH is physical channel which does not have any corresponding transport or logical channel.
Therefore, DPCCH can be called as L1 control channel.
2. Transmit power-control (TPC) commands,

3. Feedback information (FBI) (used only if DL transmit diversity is used
on DL DPCH channel) and
4. A Transport-format combination indicator (TFCI) which is optional.
The transport-format combination indicator (TFCI) serves the duty of inform-

ing the receiver receiver about the current transport format combination of the
transport channels mapped to the uplink DPDCH radio frame sent in the same
slot. It is not allowed to have less than or more than one DPCCH channel per
radio link.
Due to a fixed SF = 256, the DPCCH bit rate equals 15 kbps in UL.
Figure 4.16 shows the frame structure of the uplink DPDCH and the uplink DPCCH.
Each radio frame of length 10 ms is split into 15 slots, each of length Tslot = 2560
chips, corresponding to one power-control period. The DPDCH and DPCCH are
always frame-aligned with each other.
Having one power control command per time slot means 15 power control commands
per radio frame (or 10 ms). This simply implies that in UMTS, when UE is using
dedicated physical channels, its power can be modified 1500 times per second.
Since DPDCH is our main UL data channel, it is crucial to know about the possible
bit rates that can be achieved.
DPDCH can have SF = 256, 128, 64, 32, 16, 8 and 4 which corresponds to
15, 30, 60, 120, 240, 480 and 960 kbps respectively. Hence, variable bit rate
services can be achieved using variable spreading factors. Please refer to table
4.7 for more details.
The modulation used in UL is BPSK.
4.4.4 DL Dedicated Channels

There is only one type of downlink dedicated physical channel, the Downlink Dedi-
cated Physical Channel (downlink DPCH).
Downlink Dedicated Physical Channel
In uplink, L1 control and data are transmitted on two separate physical chan-
nels (DPDCH and DPCCH) but in downlink both L1 control and data is car-
ried by the same physical channel known as DPCH. Here DPCH is a combi-
nation of DPDCH & DPCCH.
Symbol
[ ]Rate (ksps) bit rate (kbps) on DL bit rate (kbps) on UL
SF Rchip [ 3.84 Mcps ]
= SF = SF
DPCH DPDCH
512 7.5 15 -
256 15 30 15
128 30 60 30
64 60 120 60
32 120 240 120
16 240 480 240
8 480 960 480
4 960 1920 960
Table 4.7: SF and the corresponding Channel bitrate
Figure 4.17: Slot format of DL DPCH Channel
As stated above, there is only one type of downlink dedicated physical channel, the
downlink DPCH. Within one downlink DPCH, the following information is trans-
mitted:
User Data, DTCH logical Channel
L3 Control Information, DCCH logical channel
L1 Control Information, Physical signals, generated by L1
The physical control information consistes of (1) pilot bits, (2) TPC commands, and
(3) an optional TFCI ). Therefore, DL DPCH can be considered as time multiplex
of a downlink DPDCH and a downlink DPCCH.
As usual, the timing is organized into 10 ms radio frames which equals 15 time slots.
If we carefully examine the conents of a slot in figure 4.17, various fields of DPCH
can be identified. Since there is one TPC command every 2/3 ms, the DL power
control also happens at 1500 times per second (just like uplink).
DL DPCH can have SF = 512,11 256, 128, 64, 32, 16, 8 and 4 which corre-
sponds to 30, 60, 120, 240, 480, 960 and 1920 kbps respectively. Hence, vari-
able bit rate services can be achieved using variable spreading factors. Please
refer to table 4.7 for more details.
The modulation used in DL is QPSK.
4.4.5 Summary of DCH Channels

DCH is the main channel used for transferring user data in UMTS. Therefore, it is
better to understand the slot format of UL and DL DCH channel. In figure 4.18,
the slot format of both UL and DL DCH channels is shown.
In order to understand the fast inner loop power control of UMTS, this section is
very important.
Figure 4.18: Slot format of UL and DL DPCH Channel
In figure 4.19, an example is illustrated where 3 different UEs are using 3G services
in a cell which is operating at UL frequency fUL and DL frequency fDL . The DL
primary scrambling of the cell is 511 and the UL scrambling codes allocated to the
3 UEs are 1,000,111, 1,000,222 & 1,000,333.
11
Some vendors do not support SF 512
4.5. CELL SEARCH PROCEDURE 109
Figure 4.19: Example of DCH usage, 3 DCH users shown here
This example has been specially included to explain the usage of channelization code
in UL and DL.
• In uplink, the control and data channel from the same UE is identified by UL
channelization codes.
• In downlink, channelization code is used to identify the UEs because frequency

and DL Scrambling code is the same for all users in that cell.
4.5 Cell Search Procedure

Source: 3GPP TS 25.214, Annexure C (quoted Word-by-word)
During the cell search, the UE searches for a cell and determines the downlink
Scrambling code and frame synchronization of that cell. The cell search is typically
carried out in three steps:
Step 1: Slot synchronization
During the first step of the cell search procedure the UE uses the SCHs primary
synchronization code to acquire slot synchronization to a cell. This is typically
done with a single matched filter (or any similar device) matched to the primary
synchronization code which is common to all cells. The slot timing of the cell can
be obtained by detecting peaks in the matched filter output.
Step 2: Frame synchronization and code-group identification
During the second step of the cell search procedure, the UE uses the SCHs sec-
ondary synchronization code to find frame synchronization and identify the code
group of the cell found in the first step. This is done by correlating the received
signal with all possible secondary synchronization code sequences, and identifying
the maximum correlation value. Since the cyclic shifts of the sequences are unique
the code group as well as the frame synchronization is determined.
Step 3: Scrambling code identification
During the third and last step of the cell search procedure, the UE determines
the exact primary Scrambling code used by the found cell. The primary Scrambling
code is typically identified through symbol-by-symbol correlation over the CPICH
with all codes within the code group identified in the second step. After the primary
Scrambling code has been identified, the Primary CCPCH can be detected and the
system- and cell specific BCH information can be read. If the UE has received in-
formation about which scrambling codes to search for, steps 2 and 3 above can be
simplified.
4.6. HSDPA CHANNELS IN SHORT 111
4.6 HSDPA Channels in Short

Although the channels and other details about HSDPA will be discussed in chapter
7, a list of all HSDPA related physical channels is included in this chapter. There
are 3 new physical channels which are illustrated in figure 4.20.
Figure 4.20: HSDPA operation explained using the physical channels.
HS-PDSCH: HS-PDSCH is a shared channel; it is shared between all active HS-

DPA users in the cell. Each radio frame is divided into 2 ms sub-frames in
HSDPA. There are 3 timeslots within one HSDPA sub-frame. The main fea-
tures about HS-PDSCH are listed below:
• High Speed Physical Downlink Shared Channel

• Only in DL
• Carries User data and scheduled by Node B
• SF is fixed, SF = 16
• Uses adaptive modulation, QPSK and 16QAM
• No Soft Handover, no fast power control
• Shorter transmission time interval (TTI), TTI = 2ms
HS-SCCH: The High Speed Shared Control Channel (HS-SCCH) is a downlink

control channel that is specially designed to inform UE about the scheduling
decisions made by Node B. The information on HS-SCCH is absolutely essen-
tial for HS-PDSCH reception. This channel indicates when there is data on
the HS-PDSCH that is addressed to this UE.
• High Speed Shared Control Channel

• Carries control information for HS-PDSCH:
– Channelization code set information
– Modulation scheme
– Transport block size
– Hybrid ARQ process id
– Redundancy and constellation version
– New data indicator
– UE identity = H-RNTI
HS-DPCCH: In the uplink direction, there is the High Speed Dedicated Physical
Control Channel (HS-DPCCH) that is used for sending feedback information
to Node B.
• High Speed Dedicated Physical Control Channel

• Carries L1 feedback information from a UE:
– L1 H-ARQ NACK/ACK
– Channel Quality Indicator (CQI)
4.7. HSUPA CHANNELS IN SHORT 113
4.7 HSUPA Channels in Short

A detailed description of HSUPA can be found in chapter 8. In this section a very
brief introduction to HSUPA channels is given.
Figure 4.21: HSUPA operation explained using the physical channels.
As shown in figure 8.23, there are 2 UL channels and 3 DL channels in relation to

the HSUPA operations.
E-DPDCH: E-DPDCH is the main data channel of HSUPA. In UL, UE can have
1, 2 or 4 E-DPDCHs. The main parameters about E-DPDCH are:
• E-DCH Dedicated Physical Data Channel

• Carries UL user data up to 5.76 Mbps
• Variable SF; SF = 256, 128, 64, 32, 16, 8, 4 & 2
• Uses same modulation as the UL DCH, BPSK
• Uses soft Handover & fast power control
• Shorter transmission time interval (TTI) , TTI = 10 ms & 2ms (optional)
E-DPCCH: E-DPCCH is used to carry L1 control information related to E-DPDCH.

The E-DPCCH is time-aligned with the uplink DPCCH.
• E-DCH Dedicated Physical Control Channel

• Carries control information for E-DPDCH:H:
– Retransmission sequence number (RSN), 2 bits
– E-TFCI, 7 bits
– Happy bit, 1 bit
E-AGCH: The E-AGCH is a downlink physical channel used to transmit absolute

grants to a UE or a group of UEs. The absolute grant consists of a 5 bit grant
value which is between 0 and 31. The definition of grant is the ratio between
the transmit powers of E-DPDCH and DPCCH.
Grant represents the maximum E-DPDCH to DPCCH power ratio the

UE may use in the next transmission.
Ptx,E-DPDCH
Grant =
Ptx,DPCCH
E-RGCH: The E-RGCH carries relative grants that are used in the scheduling
process to gradually increment or decrement the allowed UE grant.
• E-DCH Relative Grant Channel

• Carries relative grants for uplink E-DCH scheduling
• Relative grants transmitted with signature sequences
E-HICH: The E-HICH carries the HARQ acknowledgement indicator, ACK or

NACK.
• E-DCH Hybrid ARQ Indicator Channel

• Carries hybrid ARQ ACK/NACK indicator
• HARQ acknowledgment indicators transmitted with signature sequences
4.7. HSUPA CHANNELS IN SHORT 115
Copyright Notices
Text in section 4.2 on page 83 Section 5.3.1.1.1 of 3GPP TS 25.301 v 7.0.0

Text in section 4.2.1 on page 84 Section 5.3.1.1.1 of 3GPP TS 25.301 v 7.0.0
Text in section 4.2.2 on page 85 Section 5.3.1.1.1 of 3GPP TS 25.301 v 7.0.0
⃝2006.
c TM
Text in section 4.4 on page 88 Section 5 of 3GPP TS 25.211 v 9.1.0.

Text about P-CPICH on page 98 Section 5.3.3.1.1 of 3GPP TS 25.211 v 9.1.0.
Text about S-CCPCH on page Section 5.3.3.4 of 3GPP TS 25.211 v 9.1.0.
100
Text about PICH on page 101 Section 5.3.3.10 of 3GPP TS 25.211 v 9.1.0.
Text about P-SCH on 95 Section 5.3.3.5 of 3GPP TS 25.211 v 9.1.0.
Text about AICH on 103 Section 5.3.3.7 of 3GPP TS 25.211 v 9.1.0.
Text about Cell Search Procedure Quoted word-by-word from Annex C of
in section 4.5 on page 109 3GPP TS 25.214 v 9.1.0.
Figure 4.10 on page 99 Figure 13 of 3GPP TS 25.211 v 9.1.0.
Table 4.4 on page 94 Table 3 of 3GPP TS 25.213 v 8.4.0.
⃝2009.
c TM
BIBLIOGRAPHY
[1] 3GPP TS 25.201 ver. 6.0.0 ;‘Physical layer - General description’
[2] 3GPP TS 25.211 ver. 6.0.0 ;‘Physical channels and mapping of transport chan-
nels onto physical channels (FDD)’
[6] 3GPP TS 25.104 ver. 6.0.0 ;‘Base Station (BS) radio transmission and reception
(FDD)’
[7] 3GPP TS 25.301 ver. 6.0.0 ;‘Radio Interface Protocol Architecture’
& Sons.
[9] Chris Johnson, ‘Radio Access Networks For UMTS ; Principles And
For HSDPA-secific details, the version of these specs should be 5.0.0 or

higher & for HSUPA-specific details, it shold be 6.0.0 or higher.
116
CHAPTER
RADIO RESOURCE MANAGEMENT
Source:
• 3GPP TR 25.922 ver. 7.0.0 ; ‘Radio resource management strategies’
Wiley & Sons.
Radio Resource Management or RRM is a collective term used for the algorithms
and features designed for the optimized operation of radio networks. Radio Resource
is a generic term which is applicable to all radio access technologies. In a TDMA
based system, radio resource is a time slot, whereas, in a FDMA system it is a
frequency channel. Similarly in our CDMA-based cellular systems, UMTS & HSPA,
radio resource can be identified as a combination of:
• frequency,
• Scrambling code,
• channelization code &
• power.
Radio resources are valuable resources which directly contribute to the revenue of
the service provider. Therefore, it is very crucial to have a well-tuned radio resource
117
118 CHAPTER 5. RADIO RESOURCE MANAGEMENT
management working in the network. The tuning is generally performed by various

parameters defined at RNC, Node B or cell level. Other than these, for proper
handover and mobility, there are parameters which can separately affect the mobility
from one source cell to different target cells. The most common approach for RRM
implementation is to take decisions based on cell load where the word load refers to
as received power at Node B receiver for Uplink and transmitted power from Node
B transmitter for downlink.
In short, the functions of Radio Resource Management can be summarized as:
1. Maximize Capacity: If the current load in a cell is less than the planned target
load, there should be a mechanism to increase the resources of Non-real Time
(NRT) data users and utilize the total cell resources.
This feature will have at least two advantages: the increased cell throughput
from the operator perspective and improved user experience from end-user
perspective. This can be achieved by smart packet scheduling in RNC. With
the introduction of HSDPA & HSUPA, there are new schedulers introduced in
Node B which can respond much quicker to the variations in radio conditions
and adapt the throughput according. This well-known concept is called link
adaptation.
2. Guarantee the Planned Coverage: In CDMA-based networks, if a cell ex-

periences overload, then the interference becomes higher than usual. To over-
come this, UEs are asked to increase the transmit power. At this moment,
the UEs at cell edge, which are already transmitting with maximum power,
cannot increase their power and find themselves out-of-coverage area due to
this overload mechanism. This well-known mechanism is called cell breathing.
Therefore, there should be some mechanism, which will prevent the cell to go
into overload. This is achieved by an effective admission control algorithm in
RNC.
If admission control algorithm is too relaxed, then there will be admission of
new users even if the cell is close to overload, which will cause instability. On
the other hand, if admission control algorithm is over-protective, then there
will be very high blocking although there are some free resources left in the
cell. Therefore, proper parameter setting to tune the admission control is very
crucial to the network performance.
3. Provide good Quality of Service: In order to achieve an acceptable bit error

rate (BER), there must be sufficient quality at the physical link. There are
three important QoS attributes which are quite often used in RRM, in order
to guarantee a good link quality. They are:
5.1. INPUTS FOR RRM FUNCTIONALITY 119
1. Signal to Interference Ratio (SIR) [in dB]

2. Bit Energy to Noise Energy Ratio (Eb/No) [in dB]
3. Block Error Rate (BLER) [in %]
While admitting a new bearer, admission control already takes into account
the Planned Required EbNo, BLER target and SIR Target values. Based on
these values, admission control makes an estimate of the increment in the cell
load caused by this particular bearer. Once the bearer is admitted, the power
control mechanism tries to maintain the power level at an absolute minimum
level which will be enough to meet the quality criterion1 .
4. Priority Handling: The services can be broadly categorized into 4 traffic classes
namely: (1 = Highest priority)
1. Conversational
2. Streaming
3. Background
4. Interactive
Generally, Conversational class has the highest priority followed by Streaming,

Interactive and then Background. Therefore, Conversational class users are
given the highest importance while admitting the service. (e.g., Voice or video
calling). Rest 3 classes are subjected to buffering and scheduling according to
their relative priorities.
5.1 Inputs for RRM Functionality

In this section, we will discuss the inputs which are used by RRM functions. There
are 4 main inputs which are illustrated in figure 5.1.
1. Radio parameters stored in RNC’s database
2. Node B measurements
(a) Common Measurements

(b) Dedicated Measurements
3. UE measurements
4. RNC’s internal calculation and measurements

Figure 5.1: Inputs for RRM functionality
Let’s us discuss them one by one.
5.1.1 RNC Parameter Database

RNC is responsible for storing the radio parameters for the whole radio network
subsystem. Among other parameters, it also stores the cell specific uplink load
target and downlink load target.
For example, if the target DL load is 75% and the current load is 65%, RRM can
easily decide about the next strategy. Therefore, the parameters stored in RNC’s
database are an important input for RRM functionality.
Figure 5.2 shows three regions according to the cell load status.
• The planned area is the safe operation area where the load is under con-
trollable limits and neither coverage nor the quality of active connections gets
affected. The threshold which defines the upper limit of planned area is de-
cided in co-ordination with radio network planning strategy.
Generally in this situation, admission control is advised to allow more RABs
and packet scheduler is advised to schedule higher bit rates.
1
Transmit power should be much as required, as little as possible.
• The marginal area is the safety window between ‘normal’ and ‘overload’
states. In this situation, the new real-time calls are generally denied. Ongoing
packet sessions continue but their bit rates are neither throttled not increased.
The threshold which defines the upper limit of marginal area is decided by the
planner and defined relative to the threshold for the planned area, for example,
1 dB above the threshold for planned area.
• The overlaod area is the area where the cell load is beyond the controllable
limits. This can severely affect the quality and coverage of the cell-edge users.
Generally, in this state, the admission control stops allowing more real time
RABs in the cell and packet scheduler tries to reduce the load by scheduling
less bit rates.
Figure 5.2: Load Regions used in Radio Resource Management
5.1.2 Node B Measurements

Source: 3GPP TS 25.433, UTRAN Iub interface Node B Application
Part (NBAP) signalling
One central difference between the RRM of 2G family of systems (GSM, GPRS &
EDGE) and 3G family of systems (WCDMA & HSPA) is the exact knowledge about
current actual load.
• In 2G, the RRM is located at BSC/PCU and it knows exactly how many times
slots have been allocated. The decisions about resource allocation is purely in
the hand of BSC. BTS does not have the authority to modify the resources
autonomously. Thus, there is no confusion about the current load in the
cell.
• In 3G, the RRM is located at the RNC site. But the exact knowledge about
the cell load (UL received power and DL transmitted power) is available at the
Node B. RNC makes decisions about the initial, minimum and maximum
power of each connection but the instantaneous power can be modified by
Node B using power control feature. RNC has to completely depend on the
measurements performed by Node B and reported to RNC.
The interface connecting Node B & RNC is Iub. The signalling protocol on Iub
is called Node B Application Part (NBAP). There are two types of measurement
reports, common measurements and dedicated measurements.
Figure 5.3: Common NBAP measurement management, source: 3GPP TS 25.433
Common Measurement Report
These reports are handled by C-NBAP protocol. The word common here means
“common to the cell”. Hence we have one such report at scheduled intervals decided
by operator specific parameters2 . Typical values reported in this report are:
• Total Carrier Power (TCP)

2
Typically one such report is sent from Node B to RNC at several 100 ms, e.g., 400 ms.
• Transmitted carrier power of all codes not used for HS transmission

• Received Total Wideband Power (RTWP)
• Acknowledged PRACH Preambles
• HS-DSCH Required Power
• E-DCH Provided Bit Rate
Dedicated Measurement Report
These reports are handled by D-NBAP protocol. The word dedicated here means
“dedicated to one radio link”. Using this measurement report, Node B can inform
RNC about the transmit power of a particular radio link in downlink. Typical values
reported in this report are:
• SIR
• SIR Error
• Transmitted Code Power
NBAP protocol uses 2 special identifiers for this purpose. They are called Node B UE
context ID and CRNC Communication Context ID. These IDs are like ‘nicknames’
that were chosen by Node B and RNC at the time of initial radio link establishment.
Due to multitude of dedicated measurements, these reports are sent at lower fre-
quency compared to common measurement reports3 .
5.1.3 UE Measurements
According to 3GPP, the measurements performed by UE can be either periodic
or event-triggered. Event triggered option requires parameters to be set to
clearly define an event.
Source: 3GPP TS 25.215, Physical layer - Measurements (FDD)
Other than the measurements performed by Node B, UE physical layer also performs
various measurements which are reported back to RNC for optimum functionality
of RRM functions e.g., handover mobility, bit-rate modification etc.
According to 3GPP TS 25.215, some of the crucial UE measurements are:
3
Typically every few seconds. e.g., 3s.
Figure 5.4: Dedicated NBAP measurement management, source: 3GPP TS 25.433
• P-CPICH RSCP
• P-CPICH Ec /N0
• UTRA carrier RSSI
• GSM carrier RSSI (BCCH RxLev of GSM)
• Transport channel BLER
• UE transmitted power
• UE Rx-Tx time difference
• SFN-SFN Observed time difference
• ...
In order to read more about the definition of these quantities, please refer to section
5.1 & 5.2 in 3GPP TS 25.215. Section 5.1 describes the UE measurement abilities
and section 5.2 explains UTRAN measurement abilities.
Please note that not all the measurements are performed periodically. According
to 3GPP specifications4 , the measurements can be either periodic, or on demand or
event-based. This simply implies that there is a great deal of freedom which can
be used by infrastructure vendors for controlling the UE reporting whereas the UEs
must be capable of measuring these quantities.
4
TS 25.302, section 9.2 and TS 25.215
It has been observed, that the vendors have opted for event-based triggering
of measurements. Therefore, the UE looks out for some special scenarios to take
place. For example, UE monitors a new target cell whose CPICH signal is almost-
equally-strong as the serving cell. When such a scenario happens, UE sends a RRC:
Measurement Report Message with the details of the target cell scrambling code
and signal strength. Such a scenario is called Event 1A. In the similar fashion,
various events have been defined by 3GPP which will be discussed later in this
module.
5.1.4 Internal RNC Measurements

RNC is the central controlling unit of the RAN. Therefore, RNC keeps on performing
certain calculations, estimations and measurements to guarantee the stability of cells
within its controlling area. For example,
• For packet users, RNC keeps on performing measurement on ‘DL Transport

Channel Traffic Volume’. If the data volume exceeds a given threshold, it can
notify the packet scheduler to:
– Perform state transition from CELL FACH to CELL DCH or

– Upgrade the bit rate of allocated DCH
• Once a DCH channel is established for a UE, RNC keeps on measuring the ‘ac-
tual’ throughput in UL and DL. Based on these measurements, packet sched-
uler can:
– Decrease the allocated bit rate in next scheduling decision, or

– Release the allocated bit rate in next scheduling decision, or
– Increase the allocated bit rate if throughput measurements indicate a
very high utilization.
• Another example is when admission control admits a new real-time (RT) RAB.
Admission control informs the load estimation entity of RRM about this ‘inac-
tive’ bearer. This procedure makes sure that the load-calculation entity always
has the knowledge about load which is as close to reality as possible.
• Similarly, after scheduling a PS bearer, packet scheduler informs the load-

calculation entity about its estimate of the load caused by PS bearers.
• ...
5.2 Load Estimation

Source:
• 3GPP TR 25.922 ver. 7.0.0 ; ‘Radio resource management strategies’
Wiley & Sons.
The following section is inspired from the book ‘WCDMA for UMTS’ by
H.Holma and A. Toskala, where these topics are explained with a step-
by-step mathematical analysis and description. In ‘Let’s Learn 3G in 10
Days’, the author has tried to summarize the final result of the analysis.
The advanced readers should refer to the above mentioned reference to
get more details.
For the proper functionality of RRM, the RNC must periodically estimate the UL
& DL load in order to decide the actions for admission control and packet scheduler.
The following section explains the procedure of ‘current cell load estimation’,
in both uplink and downlink. Let us start the discussion with uplink cell load
estimation.
5.2.1 Uplink Load Estimation

RNC can estimate the current uplink load in 2 different ways.
1. Uplink cell load estimation based on ‘Received Total Wideband Power

(RTWP)’, and
2. Uplink cell load estimation based on ‘Total Uplink Throughput’
Option 1: Received Total Wideband Power-based UL load Estimation
In all CDMA-based systems, UL capacity is directly affected by the noise rise gen-
erated by users in the uplink. Typically, an operator restricts the acceptable uplink
load to a certain UL noise rise. The noise rise in the UL is the increase in noise
compared to the noise floor of the Node B:
Prx,total
Noise Rise, NRUL = (5.1)
Pnoise
5.2. LOAD ESTIMATION 127
Without going into the mathematical derivation, we will write the final relation
between Noise Rise (NR) and the cell load ηUL :
1 1
NR = or ηUL = 1 − (5.2)
1 − ηUL NR
Received Total power (RTWP) consists of three components:
1. System and equipment noise (or background noise),
2. Interference caused by ‘OWN CELL USERS’ &
3. Interference caused by ‘OTHER CELL USERS’
Or,
RTWP = PNoise + IntOwn cell + IntOther cell (5.3)
As explained earlier, Node B keeps on reporting the current Received Total Wide-
band Power (RTWP) to RNC. RNC uses this RTWP measurements and compares
it with the Pnoise . This indicates the amount of noise which has risen.
This scheme has a limitation, because:
• RTWP does not differentiate between own cell interference and other cell in-
terference. RTWP is simply the measured received power at Node B receiver
which might be caused by users in the own cell or neighbouring cells.
• RTWP also includes PN oise , as depicted in equation 5.3. If the noise level itself
fluctuates, then the RTWP cannot indicate the UL loading in an accurate
manner.
In order to overcome the problems listed above, it is better to combine the power-
based load estimation with another scheme described below.
Option 2: Throughput-based UL Load Estimation
Throughput-based UL load estimation utilizes the concepts of fractional load caused

by one user and summing the load of all the users to calculate the total cell load.
Throughput based UL load can be depicted by LT hr,Cell where
∑
LT hr,Cell = LDCH,i (5.4)
i∈All DCH in Cell
where the individual DCH of bit rate Ri kbps, causes a load LDCH,i which is calcu-
lated by:
1
LDCH,i = (5.5)
W/Ri 1
1+ ·
(Eb/N o)i AFi
where Eb/No is the signal energy per bit divided by noise spectral density that is
required to meet a predefined block error rate, W is WCDMA chip rate, Ri is the
bit rate of user i & AFi is the activity factor5 for uses i.
5.2.2 Downlink Load Estimation
Transmitted Power-based DL load Estimation
In the section related to Node B measurements, it was shown that Node B keeps on
reporting the current Total Transmitted Carrier Power (TCP) or Ptx,total to RNC.
RNC uses this Ptx,total measurements and compares it with the PBT S,M ax . This
indicates what percentage of the Node B Power Amplifier’s power has been utilized
in the current measurement period.
Ptx,total
ηDL = (5.6)
PBT S,M ax
The operator must define the DL load target. DL load target is defined as a ratio
of maximum Node B power amplifier value. For example, in a 20 W carrier, if we
plan to use ηDL = 75%, then the cell is in normal state up to Ptx,total < 15W .
Throughput-based DL Load Estimation
In principle, the throughput-based DL load estimation can be utilized in the same

manner as discussed in the previous section for Uplink. But in DL, the power based
measurements are quite reliable. Therefore, there is not much need for a separate
estimation of DL load based on throughput. The implementation is vendor specific.
5
For voice 0.5-0.7 & for Data service 1.0
5.3. RADIO RESOURCE MANAGEMENT STRATEGIES 129
5.3 Radio Resource Management Strategies

Source: ‘Section 12: Congestion Control’ of 3GPP TR 25.922,
‘Radio resource management strategies’
In UMTS, congestion control mechanism takes care of the situations where system
has reached a congestion state and therefore the QoS guarantees can be at at risk.
This feature is implemented in the packet scheduler of RNC. 3GPP only gives rough
guidelines about these feature. The exact rules of this feature are decided by the
equipment vendors. Some of these features are optional. Therefore, it is possible
for the operators to enable only those feature, which sound useful to them. But in
principle, the congestion control mechanism should perform the following tasks:
1. Congestion detection: Periodically Node B reports the cell load to RNC and
RNC compared the reported load with the target load. After this comparison,
RNC declares whether congestion has been detected.
2. Congestion resolution. Various steps can be taken by RNC’s packet scheduler

to resolve the state of congestion.
• Prioritization: Ordering the different users from lower to higher priority

(e.g., from those that expect a lower grade of service to those with more
stringent QoS requirements).
• Load reduction: Two main actions could be taken:
(a) Selective blocking of new connections while in congestion
(b) Reducing the maximum transmission rate
• Load check: Load reduction actions can be carried on until the considered
load factor is below a given threshold for a certain amount of time (i.e.,
the system can enter the congestion recovery status).
3. Congestion recovery: It is possible to attempt to restore the transmission pa-

rameters used before the congestion was triggered, by using a “time schedul-
ing” on a user by user basis.
5.4 Admission Control

Imagine an empty party hall. The first two guests arrive and start their small-
talk at a comfortable volume. As few more guests arrive, they also start talking
in pairs or groups. Later, when the room is full and everyone is busy in
the conversation with their partner, the first two guests realize that they are
actually speaking much louder compared to the situation when they were all
alone in the hall.
From this small story, one can understand that every subscriber that gets admitted
in UMTS cell, adds its contribution to the overall interference. If we want to keep
the interference within a controlled limit, the admission control must play an active
role and stop admitting new users after a certain limit.
For admission control, the following strategies must be used:
• Admission control should be performed according to the Quality of Service.

Typically, the admission control is very strict while admitting guaranteed bit
rate (GBR) services like voice, because once admitted, RNC has no authority
to drop the connection if resource congestion is detected.
On the contrary, for non-GBR services like email, web-browsing, FTP, etc.,
admission control is quite relaxed. These bearers are allowed to setup be-
cause later if congestion is detected, the resource allocation can be reduced or
eliminated.
• Admission control should take the decision after considering the current system
load and the required service. The quality can be defined in terms of required
Block Error Rate (BLER) or required Eb/No.
Admission control should use these quality parameters and estimate the in-
crement in load that will be caused if this bearer is admitted.
Imagine a room with 10 chairs where already 8 chairs are occupied. 3

more persons want to enter this room. Should admission control allow
them to enter?
I am sure your answer is No. From this simple example, we can learn that admission
control not only considers the existing load but also the hypothetical or simulated
load for the connections for which admission control is deciding. This clearly shows
that admission control algorithm prepares for the worst-case scenario before saying
yes to a new bearer.
There are various scenarios where admission control must step in and make the
decisions. The following section describes these situations.
1. AC at the time of RRC Connection Setup. This signalling is depicted

in figure 5.5
5.4. ADMISSION CONTROL 131
Figure 5.5: Admission Control in RNC at RRC Connection Establishment
In RRC Connection request, UE specifies the cause of establishment. For

example, mobile originated call, mobile terminated call, interactive session,
emergency call, registration and so on. At this moment, admission control
can prioritize the RRC connection for certain causes. It is quite obvious that
RRC connection to set up an emergency call must be treated with the highest
priority.
2. AC at the time of RAB Setup. This signalling is depicted in figure 5.6.
The procedure of RAB establishment is started by core network. Either MSC
or SGSN requests RNC to establish a RAB with certain QoS parameters.
For example, traffic class, max bit rate, guaranteed bit rate, SDU error ratio,
traffic handling priority, allocation retention priority, etc. From these QoS
parameters, RNC finds out the radio bearer attributes like Eb/No target,
Signal-to-Interference target & block error rate (BLER) target. RNC typically
uses some look-up table to do so.
Using these attibutes, admission control can estimate the increment in load
caused by the RAB in question.
(a) For RT RAB setup, AC works independently.
RT RABs have certain guaranteed bit rates. Therefore, if the resources
for these GBR service are not available, the RT RABs are denied.
(b) For NRT RAB setup, AC works in close co-ordination with packet sched-
uler (PS). Therefore, NRT RAB admission is performed by AC but the
subsequent scheduling of resources is performed by PS.
3. AC at the time of SHO diversity branch addition. This signalling

is depicted in figure 5.7. The decision about handover is taken in SRNC
Figure 5.6: Admission Control in RNC at RAB Establishment
whereas the admission control takes place in the target cell’s CRNC. In general,
admission control is a little bit relaxed for the handover decisions. Admission
control allows handover to take place up to a higher load limit compared to
the admission control for a new RAB setup.
5.5 Code Allocation

As discussed in the chapter related to CDMA, Spreading and air interface technology,
we have learnt that there are 4 types of codes used in WCDMA which are:
1. DL Scrambling Code
2. DL Channelization Code
3. UL Scrambling code
4. UL Channelization Code
1. DL Scrambling Code: Used as the physical cell id. There are totally 512
Primary-Scrambling codes in DL, which are used as L1 identity of any WCDMA
5.5. CODE ALLOCATION 133
Figure 5.7: Admission Control in RNC at Inter-RNC SHO
cell. After 512, these codes can be repeated. Therefore, we never face conges-
tion or blocking in DL Scrambling. Therefore, RRM has not much role to play
in DL SC.
2. DL Channelization Code: The channelization codes used for spreading are

Orthogonal Variable Spreading Factor (OVSF) codes that preserve the or-
thogonality between physical channels. In DL, Channelization codes are used
to differentiate among the individual users. Hence, as the need for capacity in-
creases, the DL Channelization codes face congestion. Code-tree optimization
procedure is explained in section 5.5.1.
3. UL Scrambling Code: UL Scrambling codes are used as user Id for Uplink

signal separation. According to 3GPP specification, more than 16 Million
UL SC have been defined. Out of which, one RNC can utilize a subset of
those based on the hardware limitation of RNC (for example 50,000 codes).
Therefore, shortage of UL SC is also not a very common cause for congestion.
4. UL Channelization Code: UL channelization code is used to differentiate among

the various channels transmitted from the same UE. For example:
• In Rel-99 Configuration: DPDCH & DPDCH

• In Rel-5 configuration: DPDCH, DPDCH & HS-DPCCH

• In Rel-6 configuration: DPDCH, DPDCH, HS-DPCCH, E-DPCCH &
E-DPDCH
In Uplink, every user uses a different Scrambling code. Therefore, every UE

has its own code tree. Hence, the same UL CC can be re-used within the
same cell. This is the reason why we never observe congestion in the UL
channelization code tree.
Summary: DL channelization code is a rare radio resource and must be used

very efficiently. In most of 3G cellular networks, 3G and HSDPA are deployed.
HSDPA makes use of multiple code allocation to one user. This further in-
creases the code utilization. In order to reduce the code blocking, a technique
called code tree optimization is used by RNC (see section 5.5.1).
Code allocation deals with the problem how different codes are allocated to different
connections. The channelization codes used for spreading are Orthogonal Variable
Spreading Factor (OVSF) codes that preserve the orthogonality between physical
channels. The OVSF code is shown in figure 5.8.
5.5.1 Code Tree Optimization

RNC has a smart algorithm which either periodically or based on some threshold,
re-organizes the DL channelization code tree. The main purpose of this feature is to
avoid the fragmentation of a code tree. Figure 5.9 depicts the same with example
where CC16,2 code was allocated to user 1 and CC16,10 is allocated to another user.
As a result, CC8,1 and CC8,5 are forbidden to be used in the same cell. This happens
due to the fragmented nature of code allocation.
In RRM framework, there should be a smart code allocation algorithm that can
release CC16,10 and re-assign CC16,3 to the same UE. Because the SF remains un-
changed, the net bit rate does not get affected. Therefore, this procedure happens
only at physical layer, without disturbing the higher6 protocols layers.
5.6 Packet Scheduler

With the introduction of GPRS into the mobile world, it became clear that packet
switched IP-based data services are going to be an important part of the services
6
MAC, RLC and PDCP
5.6. PACKET SCHEDULER 135
Figure 5.8: OVSF code Tree
offered by future mobile systems. That is why Packet Scheduler is introduced in

RNC to handle the packet traffic more efficiently. The main function of packet
scheduler are:
• Transport Channel Type Selection: Logical channel DTCH can be mapped

on either common channels, dedicated channels or on shared channels. PS is
responsible to select the channel type and later on, if needed, channel type
switching7 .
• Transport Format Combination Set (TFCS) construction: At the time
7
HS-DSCH ,→ DCH channel type switching can be understood as HSDPA to R99 handover.
Figure 5.9: DL Channelization Code Tree Optimization to avoid code congestion
of radio bearer setup, the PS decides about the possible transport formats
(transport block size, TB set size, TTI, channel coding scheme, coding rate,
etc.).
• RRC state handling: PS is responsible to handle the UE state. This concept

is explained later in section 5.6.1.
• Priority handling: All the PS bearers to be scheduled are put into queue
and PS picks the bearer according to their relative priorities.
• Overload Control: If the cell load goes to overload, it is PS which reduced

the bit rates and thereby tries to bring back the load to normal state.
• Bit Rate Adaptation: Other than these, PS also keeps an eye on the re-
source allocation & utilization. For example, if allocated bit rate is higher
and actual throughput is not high, then the bit rate can be reduced to avoid
wastage of resources.
In order to transmit data in uplink, UE can use RACH, DCH or E-DCH transport
channels. Similarly UE can receive downlink data on FACH, DCH or HS-DSCH
transport channels. This mapping between logical channels and transport channels
is performed by the MAC layer which is implemented in RNC’s packet scheduler
algorithm. With the introduction of HSDPA & HSUPA, the packet scheduling
function is distributed, which is described below:
RACH (↑), FACH (↓) & DCH (↕): For these transport channels, the packet
scheduling is performed by RNC. The main input for the scheduler decision
are: the amount of data to be transmitted, actual throughput measured in
past few TTIs, cell load status, priorities of the bearers etc8 .
HS-DSCH (↓) HS-DSCH is the DL transport channel used by HSDPA system.
The scheduler for this channel is located at Node B and known as MAC-hs
scheduler. CQI plays a central role in selecting which HSDPA user will be
served in the next TTI and what transport block size will be selected.
E-DCH (↑) Finally, E-DCH is the UL transport channel used by HSUPA. The
scheduler for this channel is also located at Node B and known as MAC-e
scheduler. The main input to these schedulers are the feedback reports from
UE. Each UE keeps on reporting the status of its buffer, power control head-
room and the priority of the logical channel whose data is to be transmitted.
Scheduling request happens periodically, e.g., every 100 ms. Meanwhile UE
keeps on reporting one bit information called ‘Happy Bit’ which indicated the
UE’s wish for an upgrade in UL resources.
5.6.1 RRC States

Source : 3GPP TS 25.331 RRC Protocol Specification9
RRC is the central L3 protocol in UTRAN. RRC protocol is implemented in UE

and RNC. Therefore, whenever UE & RNC want to communicate, they use RRC
protocol. Some important procedures of RRC protocols are RRC connection estab-
lishment, Radio Bearer Management, Measurement control and reporting, System
information transfer, Paging etc.
The RRC states introduced in 3G are a compromise of the following aspects:
8
Please note that Radio conditions (CPICH Ec/No or CQI) is not a factor for RNC based
packet scheduler. This happens because UE reporting to RNC is so slow that RNC cannot keep
track of radio condition of all the users.
9
TS 25.331 is perhaps the most bulky specification of UTRAN. Developments in HSDPA,
HSUPA & HSPA+ domain have further increased the details available in this this document.
• Which physical channels that are allocated to the UE, and thus which trans-
port channels that can be used. This factor affects the effective utilization of
UTRAN resources.
• Which type of RRC connection mobility procedures that are used. For exam-
ple, in one state UE performs handovers whereas in another one Cell Reselec-
tion.
• The level of UE activity, e.g. whether it is known on cell or URA level and
whether or not it uses DRX. This is a deciding factor for UE battery consump-
tion and longer standby time. In principle, UE should be in a power saving
state, if inactive. At the same time, it should be possibly to quickly make a
state transition from stand by state to active state10 .
In nutshell, the UE behaviour is broadly decided by the state in which it currently

is. Therefore, the knowledge about RRC state is very crucial in 3G understanding.
There are two modes: idle mode and connected mode. When UE is in connected
mode, its behaviour is decided by the sub-state in which it is. There are 4 sub-states
defined. They are, Cell DCH, Cell FACH, Cell PCH & URA PCH.
• [1. IDLE Mode]

When a UE is in Idle Mode, there is no RRC connection between the UE and
the RNC. In other words, RNC does not even know that this UE exists in
its area. In such a situation, UE keeps on listening to system information of
the cell and periodically reads paging channel. After being paged, UE can
establish an RRC connection.
Similarly, to initiate a call, UE can establish and RRC connection with RNC
and use it to perform call control signalling.
• [2. Connected mode]
2.a Cell DCH: The CELL DCH state is characterized by:

– A dedicated physical channel is allocated to the UE in uplink and
downlink.
– The UE is known on cell level according to its current active set.
– UE shall use the connected mode measurement control information
received in other states until new measurement control information
has been assigned to the UE.
10
The words standby and active mentioned above are used as English words rather than telecom
specific technical words.
– It shall perform measurements and transmit measurement reports

according to the measurement control information.
– UE performs handover in this state - soft, softer or hard handover.
– Battery consumption is the highest in Cell DCH state (≈ 300 -400
mA11 ).
– From Operator’s perspective, this state is very expensive because cer-
tain dedicated radio resources have to be reserved for one subscriber.
2.b Cell FACH: The Cell FACH state is characterized by:
– Neither an uplink nor a downlink dedicated physical channel is allo-
cated to the UE.
– The UE continuously monitors FACH tranport channel in the down-
link (mapped on S-CCPCH physical channel).
– The UE is assigned a default common transport channel in the up-
link (e.g. RACH) that it can use anytime according to the access
procedure defined by system information.
– The UE is known on cell level according to the cell where the UE last
made a cell update. It performs cell reselection and upon selecting a
new UTRAN cell, initiates a cell update procedure.
– UE is identified by a C-RNTI on common transport channels. The
scope of C-RNTI is limited to a cell. If a new cell is selected, a new
C-RNTI must be allocated.
– UE must monitor a FACH to receive signalling messages or user data
addressed to the UE or any broadcast messages.
– UE performs measurements and transmits measurement reports ac-
cording to the measurement control information.
– Battery consumption in this state is lower than that in Cell DCH
state but yet very high(≈ 150-200 mA).
Therefore, Cell FACH should not be considered as standby state. It
is an active state. The difference compared to Cell DCH is the usage
of common channel rather than a dedicated channel.
2.c Cell PCH: The Cell PCH state is characterized by:
cated to the UE.
– The UE uses DRX for monitoring a PCH via an allocated PICH.
11
UE battery consumption strongly depends on the handset’s hardware, features and configura-
tion. Therefore, the number mentioned here should be used as approximate value for understanding
purpose.
– No uplink activity is possible. If the UE wants to make an uplink

access, it autonomously shall enter the Cell FACH state and inform
RNC about it using cell Update signalling message.
– The UE is known on cell level according to the cell where the UE
last made a cell update in CELL FACH state.
– In this state, UE shall monitor the paging occasions according to the
DRX cycle and receive paging information on the PCH.
– UE shall acquire system information on the BCH and use the mea-
surement control information according to that system information
when no dedicated measurement control information has been as-
signed to the UE.
– Perform cell reselection and upon selecting a new UTRA cell, enter
the CELL FACH state and initiate a cell update procedure.
– Perform measurements according to the measurement control infor-
mation. Consequently, when needed, enter CELL FACH state and
transmit measurement reports.
– In Cell PCH state, the UE battery consumption is very small (≈ 5-15
mA).
2.d URA PCH: The URA PCH state is very similar to the CELL PCH
state. Therefore, a [X] sign has been printed in front of those points
which differentiate between these two states. Other points are common
in both the states. The URA PCH state is characterized by:
cated to the UE:
– The UE uses DRX for monitoring a PCH via an allocated PICH.
– No uplink activity is possible. If the UE wants to make an uplink
access it autonomously enters the Cell FACH state.
X The UE is known on URA level according to the URA assigned to
the UE during the last URA update in CELL FACH state.
– In this state, the UE shall monitor the paging occasions according to
the DRX cycle and receive paging information on the PCH.
– Acquire system information on the BCH and use the measurement
control information according to that system information when no
dedicated measurement control information has been assigned to the
UE.
X Perform cell reselection and upon selecting a new UTRA cell that
does not match the URA assigned to the UE, enter the CELL FACH
state and initiate a URA update procedure.
– Perform measurements according to the measurement control infor-

mation when needed according to the measurement control informa-
tion, enter CELL FACH state and transmit measurement reports.
– Just like the CELL PCH state, in URA PCH state also, the UE
battery consumption is very small (≈ 5-15 mA).
Some advanced readers might notice that there are a lot of details about RRC
states that could be added in the previous section. Their thoughts are absolutely
right. I wanted to keep is simple and short. For more details, readers are
advised to refer to TS 25.331.
5.6.2 RRC States Transitions

For the discussion about RRC State transition, URA PCH will not be discussed.
This will simplify our learning. Afterwards, the same concepts can be extended by
involving URA PCH as well.
From inactive to active transitions
This subsection will mainly treat the transition, which results in Idle to connected
mode transition, DCH allocation or DCH bit rate upgrade.
1. RRC Idle to CELL DCH Transition: From RRC IDLE, UE can directly
enter CELL DCH or Cell FACH state depending on the establishment cause
specified by UE in the RRC Connection Request message. The complete
signalling flow is shown in figure 5.5.
2. CELL FACH to CELL DCH Transition: This transition takes place
when UE has no DCH allocated. In this scenario, it can use RACH in UL
& FACH in DL. But if the UE requires higher bitrates in either DL or UL,
a request is received at RNC either from UE or from within RNC. This is
typically called as Capacity Request.
This capacity request is generated when the UE or RNC buffer contains data
[in Bytes] which exceeds a certain threshold. In UL, the capacity request is
officially known as Event 4A.
3. CELL DCH to CELL DCH Transition: This special case is not a state
transition but we should still discuss it. When a UE has been allocated some
bit rates in UL & DL and yet the amount of data [in Bytes] exceeds a certain
threshold, then DCH is upgraded to a higher bit rate, if allowed by the cell
load condition.
Figure 5.10: RRC State Transition: From Inactive Active behaviour
4. Cell PCH to Cell FACH Transition: If a packet session remains inactive

for several seconds or minutes, the UE will enter Cell PCH state. In this state,
there is no possibility to transmit or receive any data.
If RNC receives data from SGSN for the UE in DL: RNC will page the
UE in the Cell where it last performed a Cell Update. UE in return re-
sponds to this paging with another Cell Update message where the cause
will be explicitly specified as Paging Response. This response will go to
RNC using RACH and UE will enter Cell FACH state where once again
the data transmission can take place.
If UE has some data to send in UL: On the contrary, if the UE has some
data to send, it autonomously enters into the CELL FACH state. Once
again, on RACH it sends a Cell Update message to RNC where the cause
is specified as Uplink Data transmission.
From Active to Inactive Transitions
In contrast to the discussion in the previous section, this subsection will mainly
treat the transition which happens, if the UE becomes inactive. We will start by
imagining the UE has been allocated some DCH channel with N kbps in UL and
M kbps in DL. Now let us discuss the UE behaviour if it becomes inactive for a few
seconds.
Figure 5.11: RRC State Transition: From Active Inactive behaviour
1. CELL DCH to Cell FACH Transition: In CELL DCH state, UE has

a dedicated code and power allocation. If RNC’s Packet scheduler detects
inactivity in UL & DL, the dedicated resources are taken back from UE and
it can be sent to CELL FACH state. The timer value used in figure 5.11 is
to give a rough idea about the range which this parameter should take. In
practice, network optimizers can change these values to control the wastage of
resources in cell.
2. CELL FACH to Cell PCH Transition: As it was shown in section 5.6.1,

CELL FACH state is a state where UE constantly monitors FACH channel.
This causes very high battery consumption in UE. Therefore, if inactivity is
detected in this state, the UE moves to the real power saving state known as
Cell PCH.
3. Cell PCH to RRC IDLE Transition: In Cell PCH, UE can generally stay
inctive for a longer period because neither it is holding any network resource
nor it is wasting its battery power.
5.7 Power Control

As we have seen in the sections 5.2.1 & 5.2.2, transmit power in any CDMA-based
system is directly connected to the capacity of a cell. Therefore, it is desired to
keep the transmit power level at a minimum level which will be just enough to
meet the quality target but not exceed the desired quality. In UMTS, this task is
accomplished by 3 types of power control algorithms, which are explained in this
section.
DL Common Channels UL Common Channels

P-SCH Primary Synchronization Ch.
S-SCH Secondary Synchronization Ch.
P-CPICH Primary Common Pilot Ch.
P-CCPCH Pri. Common Control Physical Ch. PRACH Physical Random Access Ch.
S-CCPCH Sec. Common Control Physical Ch.
PICH Paging Indication Channel Ch.
AICH Acquisition Indication Channel Ch.
DL Dedicated Channels UL Dedicated Channels

DPDCH Dedicated Phy. Data Ch.
DPCH Dedicated Physical Channel
DPCCH Dedicated Phy. Control Ch.
Table 5.1: List of all R99 Physical channels
Table 5.1 shows a list of all UL & DL physical channels of R99 UMTS. Among these:
• The DL common channels do not undergo any power control. The power of
these channels is decided by radio network planners and remains fixed through-
out the operation. Their power values can be changed as an optimization effort
by the optimization engineers but RRM plays no role in dynamically changing
the power of DL common channels.
• UL Common channel PRACH is used for making initial access to the net-
work. Additionally, in UMTS, PRACH can carry small amount of UL NRT
data traffic. The power control on PRACH is known as Open Loop Power
Control.
• From the table 5.1, the only remaining channels are UL & DL dedicated chan-
nels. These are the main traffic channels in 3G. These channels undergo two
power control mechanisms in parallel, known as Inner Loop Power Control
and Outer Loop Power Control.
5.7. POWER CONTROL 145
5.7.1 Open Loop Power Control

Source : 3GPP TS 25.211, 25.214, 25.331
According to Open Loop Power Control of PRACH channel, UE transmits a PRACH

preamble with a certain initial power (see equation 5.7). If it does not receive any
response in downlink on the Aquisition Indication channel (AICH), it ramps up the
power and sends the next preamble with a higher power. UE keeps on doing it until
it receives the response from Node B.
According to the procedure defined by 3GPP TS 25.331 (section 8.5.7), UE calcu-
lates the power for the first preamble as:
Preamble Initial Power = Primary CPICH TX power

− CPICH RSCP
+ UL interference
+ Constant Value (5.7)
• “Primary CPICH Tx power” and “Constant value” are broadcasted by

system information in System Information Block type 5;
• “UL interference” is broadcasted by system information in System Infor-

mation Block type 7;
• and the CPICH RSCP is measured by UE;
As expressed by equation 5.7, the initial preamble’s strength can be controlled by

a constant value. This parameter can be in the range of [-35 . . . -10] dB. Once, the
value of this parameter is fixed, then the equation can be simplified as
Preamble Initial Power ∝ Primary CPICH TX power − CPICH RSCP

∝ Path Loss (5.8)
From equation 5.8, we can conclude that transmission power of first preamble is
directly proportional to the path loss experienced by the UE. Hence, further away
the UE is, stronger will be the initial preamble.
After transmitting the initial preamble UE will wait for a certain time12 . Within this
period if there is no response from the Node B, UE will send the next preamble with
an increased power. This power ramping is called Open Loop power Control.
The word Open Loop means that this power control works autonomously in the
transmitter (UE) without any feedback from the receiver (Node B). The moment UE
receives a feedback from Node B, open loop PC is finished because its purpose was
only to calculate the minimum initial UL power which will allow UE to communicate
with Node B.
As defined in 3GPP TS 25.214 (section 6.1), before the physical random-access
procedure can be initiated, Layer 1 shall receive the following information from the
higher layers (RRC): (The parameters related to Open Loop Power Control are indicated
by [X].)
• The message length in time, either 10 or 20 ms.
X The AICH Transmission Timing parameter [0 or 1].
• The set of available signatures and the set of available RACH sub-channels for each
Access Service Class (ASC).
X The power-ramping factor Power Ramp Step [integer > 0].
X The parameter Preamble Retrans Max [integer > 0].
X The Power offset P p-m = (Pmessage-control Ppreamble ), measured in dB, between the
power of the last transmitted preamble and the control part of the random-access
message.
In order to know more about the RACH procedure in UMTS, advanced readers are advised
to refer to 3GPP TS 25.214, (section: ‘Physical random access procedure’). PRACH
procedure has also been discussed in chapter 4 of this book in section ULcomCH. As a
quick summary, please refer to figure 5.12.
5.7.2 Inner Loop Power Control

In order to understand the fast inner loop power control of UMTS, let us review our
knowledge about UL and DL dedicated channel. As shown in figure 5.13, there are two
physical channels in UL (DPDCH and DPCCH) and only one physical channel in DL
(DPCH).
12
The exact time can be calculated by reading the “AICH transmission timing” from system
information.
Figure 5.12: Open loop Power Control on PRACH physical Channel
Figure 5.13: Slot format of UL and DL DPCH Channel
• On UL DPCCH, UE sends Pilot bits whose quality is measured by Node

B. In response, Node B sends TPC Command on DL DPCH. Based
on this TPC Command, UE can increase or decrease its transmission
power. In figure 5.13, this phenomenon is highlighted by oval shapes.
• Similarly, on DL DPCH, Node B sends Pilot bits whose quality is mea-
sured by UE. In response, UE sends TPC Command on UL DPCCH.
Based on this TPC Command, Node B can increase or decrease its trans-
mission power used on that particular radio link. 5.13, this phenomenon
is highlighted by triangle shapes.
Source : 3GPP TS 25.214;

Section 5.1 Uplink power control,
Section 5.2 Downlink power control
The concept of power control mechanism is very easy but to understand the mathematical
description available in TS 25.214, we require some acquaintance with these procedures.
In the following section, we will try to simplify the explanation. The exact details should
be studied from the reference mentioned above.
Let us discuss the uplink and downlink power control procedures one by one. First we will
start with uplink.
Uplink Inner Loop PC
3GPP TS 25.214 (section 5.1.2.2.1) provides the general description of uplink inner-loop
power control. UL inner loop PC adjusts the UE transmit power in order to keep the
received uplink signal-to-interference ratio (SIR) at a given SIR target, SIRTarget .
The serving cells (cells in the active set) should estimate signal-to-interference ratio SIREst
of the received uplink using the Pilot Bits in UL DPCCH.
On Node B side, this decision has to be taken:
• if SIREst > SIRTarget then the TPC command to transmit is “0”.
• if SIREst < SIRTarget then the TPC command to transmit is “1”.
If UE is in soft handover with 2 or more cells, it is possible that it received different TPC
Commands from different cells. For example, in 2 cells TPC Command = 1 and one cell
TPC command = 0.
UE must combine the multiple TPC commands and derive one final TPC command that
will be effective in that slot. TPC Command is “0” if at least one cell is sending
TPC command = “0” and TPC Command is “1” only if all the cells are sending TPC
command =“1”.
To convert the binary values (0 or 1) to the power step (+1 dB, +2 dB, -1 dB, 0 dB or
any other value), UE uses following guidelines:
• If the received TPC command is equal to 0, then TPC cmd for that slot is -1.
∆DPCCH = ∆TPC · TPC cmd

(or) Ptx,DPCCH (n + 1) = Ptx,DPCCH (n) − ∆TPC (5.9)
• If the received TPC command is equal to 1, then TPC cmd for that slot is +1.
∆DPCCH = ∆TPC · TPC cmd

(or) Ptx,DPCCH (n + 1) = Ptx,DPCCH (n) + ∆TPC (5.10)
On UE side, the TPC command is interpreted according to the power control algorithm
selected by operator.
[PCA 1 Power Control Algorithm 1 (3GPP TS 25.214 section 5.1.2.2.2)]
• When PCA 1 is selected, UE responds to TPC commands every time slot. In

other words, Power control happens at a rate of 1500 times per second. The
rules for TPC cmd calculation are explained in equations 5.10 & 5.9.
• ∆TPC = 1 dB or 2 dB, which is derived from the UE-specific higher-layer
parameter “TPC-StepSize”. This parameter value is signalled to UE by RNC
using L3 RRC signalling at the time of DCH allocation.
[PCA 2 Power Control Algorithm 2 (3GPP TS 25.214 section 5.1.2.2.3)]
• When the PCA 2 is selected, then UE responds to TPC command every 5th
time slot. This reduces the frequency of power control from 1500 to 300 times
per second.
– For first four slots in set, TPC cmd = 0.
– For the 5th time slot, UE follows following rule:
∗ If all 5 TPC commands within a set are 1 (i.e., 11111) then
TPC cmd = +1 in the 5th slot.
∗ If all 5 TPC commands within a set are 0 (i.e., 00000) then
TPC cmd = −1 in the 5th slot.
∗ Otherwise, TPC cmd = 0 in the 5th time slot.
• ∆TPC = 1 dB. For Algorithm 2, ∆TPC shall always take the value 1 dB.
After doing all this analysis, UE knows TPC cmd = ‘0’ or ‘1’ in every slot.
Two algorithms shall be supported by the UE for deriving a TPC cmd. Which of these
two algorithms is used is determined by a UE-specific higher-layer parameter, “PowerCon-
trolAlgorithm”, and is signalled to UE by RNC using L3 RRC signalling at the time of
DCH allocation.
Summary of uplink fast power control algorithms:

Power Control Algorithm 1: If the power control algorithm is PCA 1,

then the UE responds of TPC commands as following:
If TPC bit = ‘1’ ⇒ Increase the power by 1 or 2 dB

If TPC bit = ‘0’ ⇒ Decrease the power by 1 or 2 dB
Power Control Algorithm 2: PCA 2 means:
If 5 consecutive TPC bits are = ‘11111’ ⇒ Increase the power by 1 dB
If 5 consecutive TPC bits are = ‘00000’ ⇒ Decrease the power by 1 dB

If 5 consecutive TPC bits are = ‘01101’ ⇒ Ignore the commands
If 5 consecutive TPC bits are = ‘. . . ’ ⇒ Ignore the commands
Please refer to section 5.1 Uplink power control in 3GPP TS 25.214 for the exact math-
ematical analysis and more details about the UL inner loop power control. Now let us
focus on the DL power control mechanism.
Downlink Inner Loop PC
We must remember, Node B is transmitting several physical channels simul-

taneously. The power control explained in this section works independently
on all the DL DPCHs. In other words, if there are 10 users using speech
service in a cell, the power used for each user is calculated separately and
independently.
As explained in the introductory remarks about power control, the DL inner loop PC ad-
justs the Node B transmit power to maintain the received Downlink signal-to-interference
ratio (SIR) at a given SIR target, SIRTarget . Node B adjusts it transmit power according
to the TPC commands received from UE in UL DPCCH. UE calculates the value of TPC
command by comparing the desired Target SIR and actually measured SIR.
Figure 5.14, shows that DPDCH and DPCCH are time-multiplexed to form DPCH. The
DL power control algorithm controls the DL transmit power of the ’pilot bits’ field of
DPCCH. From this figure, one can notice the power offsets as following:
P01: The power offset between TFCI fields of DPCCH and the DPDCH.
P02: The power offset between TPC fields of DPCCH and the DPDCH.
PO3: The power offset between PILOT BITS fields of DPCCH and the DPDCH.
Figure 5.14: Slot format of DL DPCH Channel
As power control takes place, the relative power offsets between the DPCCH and DPDCH
are not changed.
According to 3GPP TS 25.214 (section 5.2.1.2.1 UE behaviour), the UE shall generate
TPC commands to control the network transmit power and send them in the TPC field
of the uplink DPCCH. The UE shall check the downlink power control mode (DPCMode )
before generating the TPC command. The DPC MODE parameter is a UE specific
parameter controlled by the UTRAN.
• If DPCMode = 0: the UE sends a unique TPC command in each slot and the TPC
command generated is transmitted in the first available TPC field in the uplink
DPCCH;
• If DPCMode = 1: the UE repeats the same TPC command over 3 slots and the new
TPC command is transmitted such that there is a new command at the beginning
of the frame.
According to 3GPP TS 25.214 (section 5.2.1.2.2 UTRAN behaviour), upon receiving the
TPC commands, UTRAN shall adjust its downlink DPCCH/DPDCH power accordingly.
For DPCMode = 0, UTRAN shall estimate the transmitted TPC command TPCest to be
0 or 1, and shall update the power every slot. If DPCMode = 1, UTRAN shall estimate
the transmitted TPC command TPCest over three slots to be 0 or 1, and shall update the
power every three slots.
According to 3GPP TS 25.214, the power control step size can take four values: 0.5, 1,
1.5 or 2 dB. It is mandatory for UTRAN to support the step size of 1 dB, while support
of other step sizes is optional.
Summary of downlink fast power control algorithms:

DPCMode = 0: If the power control algorithm is DPC Mode=0, the then

Node B responds of TPC commands as following:
If TPC bit = ‘1’ ⇒ Increase the power by a fixed step size
If TPC bit = ‘0’ ⇒ Decrease the power by a fixed step size

DPCMode = 1: If the power control algorithm is DPC Mode=1, the then
Node B responds of TPC commands as following:
If 3 consecutive TPC bits are = ‘111’ ⇒ Increase the power by a fixed step size
If 3 consecutive TPC bits are = ‘000’ ⇒ Decrease the power a fixed step size
If 3 consecutive TPC bits are = ‘. . . ’ ⇒ Ignore the commands
5.7.3 Outer Loop Power Control

Outer Loop Power Control adjusts the SIR target (SIRTarget ), in order to achieve a desired
Target Block Error Rate (BLERTarget ). Therefore, the decisions to increase or decrease
the SIR Target are made based on the comparison of estimated (measured) BLER with
Target BLER.
DL Outer Loop PC
DL outer loop power control is mainly implemented within the user equipment. At the
beginning of connection setup, RNC informs UE about the desired value of block error
rate (BLERTarget ). When UE receives the data, it calculates the actual value of BLER
received in the current TTI. This procedure is illustrated in figure 5.15.
• If Estimated BLER is < Target BLER then the DL Target SIR is reduced.
• If Estimated BLER is > Target BLER then the DL Target SIR is increased.
• If Estimated BLER is = Target BLER then the DL Target SIR is not modified.
Figure 5.15 illustrates both DL innerloop and DL outerloop power control mechanisms.
The DL outerloop function appears to be an autonomous algorithm which tries to reach
the BLERTarget as informed by the RNC at the beginning of connection setup. Hence, the
UE handset vendors have some degree of freedom while implementing the DL outer loop
PC.
Figure 5.15: Functionality of DL Outer Loop & Inner Loop PC
UL Outer Loop PC
Figure 5.16: Functionality of UL Outer Loop & Inner Loop PC
In uplink, the Outer Loop Power Control takes place in RNC. The whole procedure is
illustrated in figure 5.16. The same sequence of steps are described in the following text:
1. At connection setup, (RRC or RAB), RNC’s admission control decides the UL BLERTarget .
2. Admission control also decides the initial, minimum and maximum SIRTarget .
3. RNC informs Node B about the initial SIRTarget .
4. On physical layer between UE and Node B, UL inner-loop power control tries to

achieve this target value of SIR. The process is briefly described below.
(a) UE transmits pilot bits on UL DPCCH channel.

(b) Node B estimates the Signal-to-interference-ratio (SIREst ) & decides the po-
larity of TPC bits.
• if SIREst > SIRTarget then the TPC command to transmit is ‘0’
• if SIREst < SIRTarget then the TPC command to transmit is ‘1’
(c) This communication between UE and Node B happens once every slot (once
every 2/3 ms).
5. After receiving the data from UE, the Node B forms a frame protocol frame. This
frame has 2 parts, header and payload. Payload is for the received data from UE,
but the header contains some control information. Among other things, the header
field contains frame reliability information.
6. (In case of Soft handover), UE is connected to more than one cell or Node B. RNC
receives the frames from all the Node Bs and looks into the frame reliability infor-
mation. Based on this information, RNC decides, which frame should be forwarded
to the core network.
7. After combining the frames from all the Node Bs, RNC estimates the BLEREst and
compares it with BLERTarget . Based on the result from this last step, the SIR target
is either reduced, increased or kept unchanged.
8. RNC informs Node B about the modified target of SIR and the whole process repeats
once again (steps 3, 4, 5, 6 & 7).
5.8 Handover Control

In early 90s, people were amazed to know that while talking they can move
from one cell to another, without disconnecting the call. Now a days, we treat
it as a basic functionality of cellular networks. We have certainly come a long
way.
Handover is a mechanism where a UE in connected mode can move from one WCDMA cell
to another cell. The target cell can be of the same radio access technology or a different
one e.g., GSM. This brings us to the point where we should classify the type of handovers
5.8. HANDOVER CONTROL 155
in WCDMA. In RRM framework, the handover control makes decisions that will be made
based on the measurement results reported primarily by the UE but also by measurements
in the network or various parameters set for each cell. In general, the handovers in all
the systems can be categorized into two families, namely Soft HO & Hard HO. A brief
introduction to both is given below.
(a) Soft Handover: Soft Handover is a handover in which the mobile station adds and
removes radio links in such a manner that the UE always keeps at least one ra-
dio link to UTRAN. This can be performed on the same carrier frequency
only. For this reason, Soft Handover allows easily the provision of macro diversity
transmission. As a result of this definition, there are areas of the UE operation in
which the UE is simultaneously communicating via a number of radio links towards
different cells.
With reference to Soft Handover, the Active Set is defined as the set of radio links
simultaneously involved in the communication between the UE and UTRAN (i.e.,
the UTRA cells currently assigning a downlink DPCH to the UE constitute the
active set). Typically, max Active Set Size = 3.
(b) Hard Handover: A Hard handover is a handover in which the mobile station has to
remove all the active radio links before establishing a new radio link with the target
cell. A need of hard handover arises when:
• The target cell is a WCDMA cell but operating at a frequency other than the
frequency used in the source cell.
• The target cell belongs to a different radio access technology.
• The source and target cell are both operating at same frequency but a SHO is
not possible13 .
Another way of classification of handover is based on the Radio frequency and technology
used in the source cell and the same used in the target cell. Based on this criterion, the
handover in WCDMA can be categorized in 3 groups:
1. Intra Frequency Handover: This scenario happens when the source cell is a WCDMA
cell with operating frequency f1 & the target cell is also a WCDMA cell with the
same operating frequency. These kinds of handovers are typically:
• Soft HO: Inter Node B soft HO

• Softer HO: Intra Node B soft HO
• Hard HO: Inter-RNC HO but no Iur interface between the two RNC’s.
13
This happens in the case of Inter-RNC Handover without Iur interface support.
2. Inter Frequency Handover (IFHO): In GSM, the neighbouring cells generally op-
erate on different frequency. Therefore, while moving from one cell to another is
simply an Inter Frequency HO, but there is a big difference between TDMA-based
2G system and CDMA-based 3G system. In CDMA systems, UE is constantly
receiving & transmitting on its serving frequency. Therefore, UE cannot measure
another carrier without interrupting its reception on the serving UTRAN frequency.
Hence we need some kind of scheme where some well-defined gaps are created in
which UE can perform measurements of signal strength of P-CPICH of the inter-
frequency target cell. This concept is called Compressed Mode and will be discussed
later in this section.
Concept of compressed measurement is also needed for 3G to 2G Handover or ISHO.
3. Inter System Handover (ISHO): In the early days of UMTS deployment, it can be
anticipated that the service area will not be as contiguous and extensive as existing
second generation systems. It is also anticipated that UMTS network will be an
overlay on the 2nd generation network and utilize the latter, in the minimum case,
as a fall back to ensure continuity of service and maintain a good QoS as perceived
by the user.
Therefore, the majority of 3G mobile devices will be a multimode equipment, capable
of using both 2G & 3G. This concept is beneficial for both the technologies. Where
3G gets some kind of coverage safety belt from the underlying legacy 2G network,
at the same time, 2G investments can be reused in the modern 3G technology. This
backward compatibility of 3G to 2G is a major driving force in the success of UMTS.
5.8.1 Active, Monitored and Detected cells

According to 3GPP TS 25.331 (section 8.4.0 ‘Measurement related definitions’), cells that
the UE is monitoring are grouped in the three mutually exclusive categories:
Active Set Cells: Cells, which belong to the active set. User information is sent from
all these cells. The cells in the active set are involved in soft handover. The UE
shall only consider active set cells included in the variable CELL INFO LIST for
measurement; i.e., active set cells not included in the CELL INFO LIST shall not
be considered in any event evaluation and measurement reporting.
Monitored Cells: Cells, which are not included in the active set, but are included in
the CELL INFO LIST belong to the monitored set. In common man’s language, we
can call these cells as defined neighbours.
Detected Cells: Cells detected by the UE, which are neither in the CELL INFO LIST
nor in the active set belong to the detected set. Reporting of measurements of the
detected set is only applicable to intra-frequency measurements made by UEs in the
CELL DCH state. These cells can be understood as missing neighbours.
5.8.2 Soft/Softer Handover

The only difference between soft and softer handover is:
• In Soft Handover, the cells taking part in HO are served by two different Node Bs,
whereas, in Softer handover, they belong to the same Node B.
• In Soft Handover, RNC receives the data from two (or more) Node Bs. Both of
these data flow can have different block error rates (BLER). RNC can select the
data with less BLER and ignore the other one. This procedure in called Macro
Diversity Combining (MDC). An example of this was shown in the UL outer loop
PC section (see figure 5.16).
In Softer HO, there is no MDC because it is Node B which performs the combining
of two uplink radio links.
• Another difference between the Soft & Softer HO is in terms of Iub utilization. In
Softer Handover, the data is sent/received on Iub only on one link, where as in
Sot handover at least two Iub links are used and in worst case, even an Iur link is
required if the two Node Bs are controlled by two different RNCs.
Otherwise from the RF perspective, Soft and Softer HO are very similar. Therefore, in
the next sections the word Soft Ho will be used for both types of HO.
Soft handovers are Mobile Evaluated Handovers, MEHO. Therefore, it is UE which initiates
the handover procedure. As defined in section 5.1.3, UE can inform RNC about the need
for handover either periodically or based on some events.
According to 3GPP TS 25.331 (section 14.1.1 ‘Intra-frequency measurement quantities’),
a measurement quantity is used to evaluate whether an intra-frequency event has occurred
or not. It can be:
1. Downlink Ec/No.
2. Downlink path loss. For FDD:
Pathloss in dB = Primary CPICH Tx power − CPICH RSCP
For Primary CPICH Tx power, the IE “Primary CPICH Tx power” shall be used
which is signalled to UE in system information (SIB 5). The unit is dBm. CPICH
RSCP is the result of the CPICH RSCP measurement. The unit is dBm.
3. Downlink received signal code power (RSCP) after despreading.
In practice, most commonly, CPICH Ec/No is chosen as a measurement quan-

tity for Soft HO decisions. For Inter-frequency and Inter-System handover,
both CPICH RSCP and CPICH Ec/No are used to trigger the handover mea-
surements.
For Soft handover, there are three main events defined in the specifications 3GPP TS
25.331. Within Measurement Control message, the UTRAN notifies the UE which events
should trigger a measurement report. The listed events are the toolbox from which the
UTRAN can choose the reporting events that are needed for the implemented handover
evaluation function, or other radio network functions.
In the description about the SHO related events, we will assume that Intra-
frequency measurement quantity is CPICH Ec/No. The explanation is a sim-
plified version of the complicated (and complete) procedure explained in 3GPP
TS 25.331.
• [Event 1A:] A Primary CPICH enters the reporting range.
Figure 5.17: Event 1A triggered
Commonly network planners and optimizers define event 1A as Event

1A is used to ADD a cell to the active set.
As shown in figure 5.17, event 1A can take place when the UE has an active set =
1 or 2. The threshold value of CPICH Ec/No is calculated with reference to the
best active set cell. Therefore, if a neighbour cell is to be added to the active set,
its CPICH Ec/No should be greater than the threshold shown in the figure. The
threshold does not have an absolute value but relative to the best active set cell.
In right sub-figure of figure 5.17, there are 2 cells in AS but the threshold for
handover evaluation is calculated with reference to the cell with SC ‘a’ because it is
the strongest cell in AS.
(CPICH Ec/No)Neighbour Cell > (CPICH Ec/No)Best, AS Cell − Add Window (5.11)
– UE RNC: Measurement Report

After event 1A gets triggered, UE reports this to RNC by sending a L3 RRC:
Measurement Report massage. In this, UE specifies the DL SC of the neigh-
bour cell along with the CPICH Ec/No value. This signalling scenario was
illustrated in figure 5.7 in admission control section.
– RNC UE: Active Set Update
At this moment, RNC performs admission control for the target cell. On
successful addition decision, RNC informs UE by sending a L3 RRC: Active
Set Update message.
– UE RNC: Active Set Update Complete
In response, UE finally replies with RRC: Active Set Update Complete.
Adding another cell to the active set makes the neighbours of the added cell also
the neighbours for UE. Therefore, RNC performs neighbour list combining and
informs UE about its decision using RRC: Measurement Control message.
• [Event 1B:] A primary CPICH leaves the reporting range .
Figure 5.18: Event 1B triggered
Commonly network planners and optimizers define event 1B as Event

1B is used to DELETE a cell from the active set.
As shown in figure 5.18, e1B takes place when the UE has an active set = 2 or
3. Just like e1A, here also the threshold value of CPICH Ec/No is calculated with
reference to the best active set cell. Therefore, if a neighbour cell is to be deleted
or removed from the the active set, its CPICH Ec/No should be weaker than the
threshold shown in the figure. The threshold does not have an absolute value but
relative to the best active set cell.
In the left sub-figure of figure 5.18, there are 2 cells in the AS and in the right
sub-figure there are 3 cells in AS. In both the scenarios, the threshold for handover
evaluation is calculated with reference to the cell with SC ‘a’ because it is the
strongest cell in AS.
(CPICH Ec/No)AS,Cell < (CPICH Ec/No)Best, AS Cell − Drop Window (5.12)

The signalling procedures explained in the case of event 1A are also valid in this
case. The name of messages are the same. In short:
– UE RNC: Measurement Report
– RNC UE: Active Set Update
– UE RNC: Active Set Update Complete
After deleting an AS cell, RNC performs neighbour list combining and informs
UE about its decision using RRC: Measurement Control message.
• [Event 1C:] A non-active primary CPICH becomes better than an active primary
CPICH.
Figure 5.19: Event 1C triggered
Commonly network planners and optimizers define event 1C as Event 1C is

used to REPLACE a ‘weak AS Cell’ with a ‘Stronger one outside
the AS’.
As shown in figure 5.19, e1C can only take place when the UE has an active set = 3. In
other words, when the AS is full. In contrast to e1A & e1B, where the threshold value of
CPICH Ec/No is calculated with reference to the best active set cell, for e1C, the threshold
is calculated with reference to the Weakest active set cell. Therefore, if a neighbour cell
is to be replaced with one of the AS cells, its CPICH Ec/No should be stronger than the
threshold shown in figure 5.19.
In figure 5.18, there are 3 cells in AS. The threshold for handover evaluation is calculated
with reference to the cell with SC ‘c’ because it is the weakest cell in AS.
(CPICH Ec/No)Neighbour Cell > (CPICH Ec/No)Weakest, AS Cell + Replacement Window

(5.13)
The signalling procedures explained in the case of event 1A & 1B.
As a summary, the SHO mechanism can be summarized by figure 5.20. This figure has
been copied from ‘Figure 5-1: Example of Soft Handover Algorithm’ of 3GPP TR 25.922
V7.0.0 which explains Radio resource management (RRM) strategies. Advanced readers
who might be interested in more details, are advised to refer to section 5.1.4.2 in TR
25.922.
Figure 5.20: Summary of Soft Handover Mechanism (from TR 25.922)

5.8.3 ISHO and IFHO Triggering

In CDMA, the UEs with only one receiver are only monitoring the DL frequency used by
the active set cells. Therefore, to start the inter-frequency or inter-system measurements,
certain events must take place. In general, there are several reasons to start an IFHO or
ISHO. The following is a non-exhaustive list for causes that could be used for the initiation
of a handover process.
• Uplink quality (e.g.BLER)

• Downlink quality (e.g. Transport channel BLER)
• Downlink signal measurements (e.g. CPICH RCSP, CPICH Ec/No, Pathloss)
• UE transmit power
• Node B radio link Power
• Traffic load (or Load Based HO)
• Pre-emption
• Change of service (service based HO)
• ...
• ...
The exact strategies implemented in the RAN depends on infrastructure vendors. From
those strategies, the network optimizers can enable only a subset (or all the strategies)
that will control inter-system and inter-frequency handover. In this book, we will discuss
the ISHO/IFHO due to downlink pilot channel measurements (e.g. CPICH RCSP, CPICH
Ec/No).
As depicted by the left sub-figure of figure 5.21, the downlink signal of the active set cell
has become very weak. According to 3GPP TS 25.331, there are specific events described
for these scenarios.
Event 1F: A Primary CPICH becomes worse than an absolute threshold. The
strength of P-CPICH can be measured in terms of CPICH RCSP, CPICH Ec/No. In
order to trigger an event 1F, either of the two quantities has to fall below a certain
threshold. In figure 5.21(see left sub-figure), these thresholds are depicted as ‘N’ dB
for Ec/No and ‘M’ dBm for RSCP.
Please note: A UE can be in SHO with 2 or 3 cells. If 1F is triggered for one of
the AS cells, UE reports this to RNC but RNC does not start the measurement
mechanism because there are still other AS cells, which can maintain the service
with adequate quality. Only when the e1F is triggered for the last AS cell, the
measurements procedure is started.
Figure 5.21: Event 1E & 1F triggered
Event 1E: A Primary CPICH becomes better than an absolute threshold. In

order to trigger an event 1E, either of the two quantities has to rise above a certain
threshold. In figure 5.21 (see right sub-figure), these thresholds are depicted as ‘N
+ ∆1 ’ dB for Ec/No and ‘M + ∆2 ’ dBm for RSCP.
In simple words, event 1E can be called as Cancel previously reported event 1F.
Summary: Event 1F is a method by which UE informs RNC about its poor

3G coverage and the need for an IFHO or ISHO and Event 1E is a method by
which UE informs RNC about its 3G reception with acceptable signal quality.
For a more detailed information, readers should refer to 3GPP TS 25.331. Section 14.1.2.5
describes the details of Event 1E & 14.1.2.6 illustrates Event 1F.
5.8.4 Inter-Frequency Measurements

Source: 3GPP TS 25.331, section 14.2.0a Inter-frequency measurement
quantities
Within the measurement reporting criteria field in the MEASUREMENT CONTROL mes-
sage, UTRAN notifies the UE which events should trigger the UE to send a MEASURE-
MENT REPORT message. The listed events are the toolbox from which the UTRAN
can choose the reporting events that are needed for the implemented handover evaluation
function or other radio network functions. The measurement quantities are measured on
the monitored primary common pilot channels (CPICH) in the FDD mode. In order to
understand the events of IF measurements, we need to define 2 terms:
1. Non-used Frequency: A “non-used frequency” is a frequency that the UE has been

ordered to measure upon but is not used for the connection.
2. Used Frequency: A “used frequency” is a frequency that the UE has been ordered
to measure upon and is also currently used for the connection.
The following events are described in section 10.3.7.19 of 3GPP TS 25.331. This section
is about Inter-frequency measurement reporting criteria.
1. Event 2a: Change of best frequency.
2. Event 2b: Event 2b is triggered when following 2 conditions are fulfilled:
• The estimated quality of the currently used frequency is below a certain thresh-
old, and
• the estimated quality of a non-used frequency is above a certain threshold.
3. Event 2c: The estimated quality of a non-used frequency is above a certain threshold.
4. Event 2d: The estimated quality of the currently used frequency is below a certain
threshold.
5. Event 2e: The estimated quality of a non-used frequency is below a certain threshold.
6. Event 2f: The estimated quality of the currently used frequency is above a certain
threshold.
5.8.5 Inter-System Measurements

Source: 3GPP TS 25.331, section 14.3.0a Inter-RAT measurement quantities
At the time of writing of this book, the commonly used inter-system handover from an
UTRAN cell are towards a GERAN cell (2G) or a E-UTRAN cell (LTE). We will discuss
only the handovers from 3G to 2G.
A measurement quantity is used by the UE to evaluate whether an inter-RAT measurement
event has occurred or not is described below:
Measurement quantity for UTRAN: The measurement quantity for UTRAN is used
to compute the frequency quality estimate for the active set, as described in the next
subclause, and can be:
• Downlink Ec/No.
• Downlink received signal code power (RSCP) after despreading.
Measurement quantity for GSM: The measurement quantity for GSM can be:
• GSM Carrier RSSI
Within the measurement reporting criteria field in the MEASUREMENT CONTROL mes-
sage, UTRAN notifies the UE which events should trigger the UE to send a MEASURE-
MENT REPORT message. The listed events are the toolbox from which the UTRAN
can choose the reporting events that are needed for the implemented handover evaluation
function or other radio network functions. The measurement quantities are measured on
the monitored primary common pilot channels (CPICH) in the FDD mode. In order to
understand the events of inter-system measurements, we need to define 2 terms:
1. Other System: “Other system” is e.g., GSM or E-UTRA14 . But in this book, we will
discuss on the GSM case.
2. Used Frequency: A “used UTRAN frequency” is a frequency that the UE have been
ordered to measure upon and is also currently used for the connection to UTRAN.
Following events are described in section 10.3.7.30 of 3GPP TS 25.331. This section is
about Inter-RAT measurement reporting criteria.
1. Event 3a: Event 3a is triggered when the following two conditions are fulfilled:
• The estimated quality of the currently used UTRAN frequency is below a

certain threshold, and
• The estimated quality of the other system is above a certain threshold.
2. Event 3b: The estimated quality of the other system is below a certain threshold.
3. Event 3c: The estimated quality of the other system is above a certain threshold.
4. Event 3d: Change of the best cell in the other system.
5.8.6 Compressed Mode

In the previous section, we saw how a UE informs RNC about the need for handover to
another frequency UTRAN cell or a cell with another RAT (e.g. GSM). In this section,
we will try to investigate the method by which the UE can perform measurements on
14
LTE
another frequency while resuming the service on its serving frequency. This method is
called Compressed Mode15 .
According to 3GPP TR 25.922, Compressed Mode can be avoided if the device supports
dual-receiver. UE can signal this capability to RNC using at the time of RRC establish-
ment. But the majority of UEs, which are commercially available, have only one receiver,
therefore, the radio planners cannot rely on this option. It is assumed that UEs do not
support dual-receivers and therefore, compressed mode is very much needed.
Methods of Compressed Mode
Spreading Factor by 2 or SF/2: This method has advantages and also disadvantages:
Adv: This method allows us to achieve the same bitrate in compressed frames as
in the normal frame.
Disadv: In compressed frames, the SF becomes half, therefore, the power require-
ment becomes double. This causes problems in terms of coverage and capacity.
Higher Layer Scheduling: This method also has advantages and disadvantages:
Adv: This method allows us to transmit with the same power in compressed frames
and normal frames.
Disadv: The bit rate in compressed mode is reduced because “higher” layers have
scheduled less data in compressed frame.
5.8.7 Inter System HO Signalling

The signalling procedures involved with Inter-system HO is explained in chapter section
9.9. In short, the steps involved in this procedure are:
1. Phase 1: ISHO triggers
2. Phase 2: Compressed Mode measurements for BCCH RSSI
3. Phase 3: Measurement Reports (UE to RNC)
4. Phase 4: Compressed Mode measurements for BSIC verification
6. Phase 6: HO decision
7. Phase 7: Signalling between SRNC & BSC

15
This has nothing to do with data compression as we know from our computer and IP knowledge.
8. Phase 8: Communication between UE and GERAN
9. Phase 9: Confirmation about successful HO to RNC
Please refer to section 9.9 for the signalling flow and more explanation.
Copyright Notices
In order to create some figures, tables and text-sections, the following reference material
has been used. Information has been interpreted and presented in a simplified manner.
The original references are provided here.
Main reference material for this book has been technical specifications (TSs) and technical
reports (TRs) of 3rd Generation Partnership Project (3GPP).

Figure 5.20 on page 161 Figure 5-1 of 3GPP TS 25.922 v 7.0.0.
Text about RRM Strategies in Section 12 of 3GPP TS 25.922 v 7.0.0.
section 5.3 on page 129
Text about Common-NBAP mea- Section 8.2.9.2 of 3GPP TS 25.433 v 7.0.0.
surements on page 122
Text about Dedicated-NBAP Section 8.2.9.2 of 3GPP TS 25.433 v 7.0.0.
measurements on page 123
Text about UE measurements on Section 5.1 & 5.2 of 3GPP TS 25.215 v 7.0.0.
page 123
Text about Initial PRACH Section 8.5.7 of 3GPP TS 25.331 v 6.9.0.
Preamble on page 145
Text about Active, Monitored Section 8.4.0 of 3GPP TS 25.331 v 6.9.0.
and Detected cells on page 156
Text about Intra-frequency mea- Section 14.1.1. of 3GPP TS 25.331 v 6.9.0.
surement quantities on page 157
Text about IF measurement Section 14.2.0a of 3GPP TS 25.331 v 6.9.0.
quantities on page 164
Text about Event 2A to 2F on Section 10.3.7.19 of 3GPP TS 25.331 v 6.9.0.
page 164
Text about IS measurement Section 14.3.0a of 3GPP TS 25.331 v 6.9.0.
quantities on page 164
Text about Event 3A to 3D on Section 10.3.7.30 of 3GPP TS 25.331 v 6.9.0.
page 165
⃝2006.
Text about Open Loop PC pa- Section 6.1 3GPP TS 25.214 v 6.9.0.
rameters on page 146
Text about UL Inner Loop PC on Section 5.1.2.2.1 3GPP TS 25.214 v 6.9.0.
page 148
Text about UL PC Algorithm 1 Section 5.1.2.2.2 3GPP TS 25.214 v 6.9.0.
on page 149
Text about UL PC Algorithm 2 Section 5.1.2.2.3 3GPP TS 25.214 v 6.9.0.
on page 149
Text about DL PC (UE be- Section 5.2.1.2.1 3GPP TS 25.214 v 6.9.0.
haviour) on page 151
Text about DL PC (UTRAN be- Section 5.2.1.2.2 3GPP TS 25.214 v 6.9.0.
haviour) on page 151
⃝2009.
BIBLIOGRAPHY
[1] 3GPP TS 25.211 ver. 6.0.0 ;‘Physical channels and mapping of transport channels
onto physical channels (FDD)’
[5] 3GPP TS 25.214 ver. 6.0.0 ;‘3GPP TS 25.215, Physical layer - Measurements (FDD)’
[8] 3GPP TS 25.413 ver. 6.0.0 ;‘UTRAN Iu interface RANAP signalling’
[9] 3GPP TS 25.433 ver. 6.0.0 ;‘UTRAN Iub interface Node B Application Part (NBAP)
signalling’
[10] 3GPP TS 25.331 ver. 7.0.0 ;‘Radio Resource Control (RRC) protocol specification’
[11] 3GPP TR 25.922 ver. 7.0.0 ;‘Radio resource management strategies’
[12] 3GPP TR 25.931 ver. 8.0.0 ;‘UTRAN functions, examples on signalling procedures’
[13] H.Holma and A. Toskala, ‘WCDMA for UMTS’ , 5th Edition, John Wiley & Sons.
[14] Chris Johnson, ‘Radio Access Networks For UMTS ; Principles And Prac-
tice’ , John Wiley & Sons.
For HSDPA-specific details, the version of these specs should be 5.0.0 or

higher & for HSUPA-specific details, it should be 6.0.0 or higher.
170
CHAPTER
PROTOCOLS & INTERFACES
Abbreviations
In this module, a lot of abbreviation will be used. Therefore, it is better to introduce a
list of all the abbreviations used in the coming sections.
• AAL2/5: ATM adaptation Layer type 2 / Type 5
• ATM: Asynchronous Transfer Mode
• BMC: Broadcast/Multicast Control Protocol
• BSSAP: Base Station System Application Part Protocol
• FP: Frame Protocol
• GMM: GPRS Mobility Management
• SM: (GPRS) Session Management
• GTP: GPRS Tunneling Protocol
• luUP: Iu User Plane Protocol
• MAC: Medium Access Control
171
172 CHAPTER 6. PROTOCOLS & INTERFACES
• MAP: Mobile Application Part
• MM: Mobility Management
• MTP-3B: Message Transfer Part Level 3B
• NBAP: NBAP Node B Application Part
• PDCP: Packet Data Convergence Protocol
• ALCAP: Access Link Control Application Part
• RANAP: Radio Access Network Application Protocol
• RLC: Radio Link Control Protocol
• RNSAP: Radio Network Subsystem Application Part
• RRC: Radio Resource Control
• RTCP: Real Time Control Protocol
• RTP: Real Time Protocol
• SCCP: Signalling Connection Control Part
• SCTP: Stream Control Transmission Protocol
• SMS: SMS Short Message Service
• SS: Supplementary Services
• SSCOP: Service Specific Connection-Oriented Protocol
• SSCF-NNI: Service Specific Coordination Function - Network-Network Interface
• SSCF-UNI: Service Specific Coordination Function - User-Network Interface
• UDP: User Datagram Protocol
6.1 Overview
Source: 3GPP TS 25.401; UTRAN overall description
Figure 6.1 shows the general protocol model for UTRAN interfaces. While designing this
structure, it was planned to keep the layers and planes logically independent of each other.
This strategy was designed so that protocol stacks and planes can be modified according
to the future requirements.
6.1. OVERVIEW 173
Figure 6.1: General Protocol Model for UTRAN Interfaces (TS 25.401)
6.1.1 Horizontal Layers

The Protocol Structure consists of two main layers, Radio Network Layer, and Transport
Network Layer. A description for both is available in 3GPP TS 25.401 (section 11.1.2).
1. Radio Network Layer: All UTRAN related issues are visible only in the Radio Net-
work Layer. It defines the procedures related to the operation of Node B. The radio
network layer consists of a radio network control plane and a radio network user
plane.
2. Transport Network Layer: Transport Layer defines the procedures for establishing
physical connections between Node B and the RNC. It represents standard transport
technology that is selected to be used for UTRAN, but without any UTRAN-specific
requirements.
6.1.2 Vertical Planes

Similarly, the UTRAN protocol structure is vertically divided into 3 planes. The descrip-
tion is available in section 11.1.3 of 3GPP TS 25.401.
Interface Control Plane User Plane

Iub NBAP FP
Iur RNSAP FP
Iu-CS RANAP
Iu-PS RANAP GTP-U
Table 6.1: Main Protocols used on UTRAN Terrestrial Interfaces
1. Control Plane: The Control Plane consists of protocols which have functionality
purely designed for the UMTS operation. On the Iu-CS & Iu-PS interface, the
control plane protocol is RANAP. On the Iur interface it is RNSAP and on Iub in-
terface it is NBAP. In addition, the control plane also includes the Signalling Bearer
for transporting the Application Protocol messages.
Application Protocol is used for setting up bearers. The Signalling Bearer for the
Application Protocol may or may not be of the same type as the Signalling Protocol
for the ALCAP. The Signalling Bearer is always set up by O & M actions.
2. User Plane: The User Plane Includes the Data Stream(s) and the Data Bearer(s) for
the Data Stream(s). The Data Stream(s) is/are characterized by one or more frame
protocols specified for that interface.
3. Transport Network Control Plane: The Transport Network Control Plane does
not include any Radio Network Layer information, and is completely in the Trans-
port Layer. It includes the ALCAP protocol(s) that is/are needed to set up the
transport bearers (Data Bearer) for the User Plane. It also includes the appropriate
Signalling Bearer(s) needed for the ALCAP protocol(s).
4. Transport Network User Plane: The Data Bearer(s) in the User Plane, and the
Signalling Bearer(s) for Application Protocol also belong to Transport Network User
Plane. As described in the previous section, the Data Bearers in the Transport Net-
work User Plane are directly controlled by the Transport Network Control Plane
during real time operation but the control actions required for setting up the Sig-
nalling Bearer(s) for Application Protocol are considered O & M actions.
Figure 6.2 shows the UMTS network architecture with only the most essential network
elements. Here, various network elements are connected using well-defined standard in-
terfaces called Iub, Iur & Iu, whre Iu itself has 2 versions. One towards CS core network,
called as Iu-CS and the other one towards the Packet core network, called as Iu-PS.
These four are also called as UTRAN interfaces. All of these interfaces are used to carry
signalling as well as the traffic which is depicted by dashed and solid lines respectively in
the figure 6.2. On each interface, a shaded box is drawn to indicate the name of Interface,
protocol used for control plane and the protocol used for user plane data transfer.
6.2. QOS AND BEARER 175
Other than the UTRAN interfaces, the figure 6.2 also illustrated the UTRAN Radio
Interface protocols. The network element which controls the whole radio network is RNC.
Therefore, UE & RNC need to communicate very often in UMTS. This communication
happens using the radio protocols. Physical realization of this signalling transfer happens
using the Uu Interface ( UE Node B) and Iub Interface (Node B RNC).
Figure 6.2: Overview of all UTRAN Interfaces and Protocols
6.2 QoS and Bearer

Source : 3GPP TS 23.107 ; Quality of Service (QoS) concept and architecture
End-to-End Service: End-to-end service means the service as perceived by the end user.
For example, the end-to-end service from one Terminal Equipment (TE) to another TE,
or from laptop to web server. In order to provide a certain QoS to a user, there must be
a bearer with well-defined characteristics and functionality.
End-to-end service is like a chain of several smaller links (or bearers) and
it is a well-known fact that a chain is never stronger than the weakest list.
Therefore, the weakest bearer in the chain will define the QoS of end-to-end
service.
End-to-end service = UMTS bearer “ + ” External Bearer.
External bearer is beyond the scope of UMTS technology. Therefore, the operator has to
rely on the QoS provided by the external bearer. If the external bearer is between GMSC
Figure 6.3: UMTS QoS Architecture and Bearer Concept (3GPP TS 23.107)
and external PSTN exchange, then these links can be the PCM lines which have excellent
QoS with guaranteed bit rate. On the other hand, if these external bearers are between
GGSN and some web server, then the external bearer is implemented on the IP link. The
QoS in IP is a configurable thing. But we will not discuss it here and restrict ourself to
the UMTS bearer.
The UMTS bearer can be understood as a chain of three smaller bearers.
UMTS Bearer = [Radio Bearer] “ + ” [Iu Bearer] “ + ” [Core

Network Bearer].
where , [Radio Bearer “ + ” Iu Bearer] is often called as Radio

Access Bearer (RAB).
Radio Access Bearer can be considered as a service provided by lower layers to higher
layers. Using RAB, the information is transferred between UE and core network (MSC
or SGSN). In order to have a RAB, UE must have a radio bearer and Iu bearer. Radio
bearers are managed by RNC. Therefore, while RAB setup, core network requests RNC
and after successful response from RNC, the RAB is established.
Please note! RB Reconfiguration and RAB Reconfiguration sound very similar

and quite often people mix them up.
6.2. QOS AND BEARER 177
We should remember that Radio Bearer (RB) Reconfiguration is a local sig-

nalling procedure between UE and RNC, whereas, RAB Reconfiguration hap-
pens with the involvement of core network. RB reconfiguration happens very
often and can be seen from L3 radio messages, but to analyze the signalling
of RAB reconfiguration we must use the signllinng traces on Iu-CS or Iu-PS
interface.
Please refer to section 6.1 of TS 23.107 for more details.
6.2.1 UMTS QoS Classes

The QoS is simply a phrase. For implementation, we define it using a list of parameters.
One of these parameters is the Traffic Class. According to 3GPP TS 23.107, all the
services can be classified into 4 groups:
• Conversational class
• Streaming class
• Interactive class
• Background class
The delay sensitivity of traffic is the main criteria for this classification. Conversational
class traffic is affected very badly the bearer is lost for few hundred ms where as the
bearer background class will not be affected so badly even if the bearer is unavailable for
few seconds.
Other than this classification, we can also group the services in two groups: Real-Time
(RT) and Non-Real-Time (NRT) services. Conversational and Streaming classes are
mainly used for carrying real-time traffic flows whereas the Interactive and Background
traffic classes are suitable for carrying Non-Real-Time traffic.
Conversational Class
The most well-known use of this scheme is telephony speech (e.g. GSM). But with Internet
and multimedia, a number of new applications will require this scheme, for example,
voice over IP and video conferencing tools. Real time conversation is always performed
between peers (or groups) of live (human) end-users. This is the only scheme where the
required characteristics are strictly given by human perception. Real time conversation -
fundamental characteristics for QoS:
• Preserve time relation (variation) between information entities of the stream;

• Conversational pattern (stringent and low delay).
Streaming Class
When the user is looking at (listening to) real time video (audio), the scheme of real time
streams applies. The real time data flow is always aiming at a live (human) destination.
It is a one way transport.
Real time streams - fundamental characteristics for QoS:
• Preserve time relation (variation) between information entities of the stream.
Interactive Class
When the end-user, that is either a machine or a human, is on line requesting data from
remote equipment (e.g. a server), this scheme applies. Examples of human interaction with
the remote equipment are: web browsing, data base retrieval, server access. Interactive
traffic - fundamental characteristics for QoS:
• Request response pattern;

• Preserve payload content.
Background Class
When the end-user, that typically is a computer, sends and receives data files in the
background, this scheme applies. Examples are background delivery of E-mails, SMS,
download of databases and reception of measurement records. Background traffic - fun-
damental characteristics for QoS:
• The destination is not expecting the data within a certain time;

• Preserve payload content.
6.3 Access Stratum and Non-Access Stratum

According to 3GPP TR 21.905 ‘Vocabulary for 3GPP Specifications’ , the definition of
Stratum is as follows:
Stratum: Grouping of protocols related to one aspect of the services

provided by one or several domains.
In simple words, Stratum is similar to ‘a stack of protocols’. There are two types of
stratums that are often discussed. They are Access Stratum (AS) & Non-Access-Stratum
(NAS). The same concept is illustrated in figure 6.4.
6.3. ACCESS STRATUM AND NON-ACCESS STRATUM 179
Figure 6.4: Access Stratum & Non-access Stratum Signalling
Access Stratum: Access Stratum protocols are defined in close co-ordination with the
technology and medium of transport. AS protocol in radio interface is RRC, which
clearly defines the communication between UE and RNC. Similarly, the AS protocol
in Iu Interface is RANAP. RANAP is used to control the communication between
RNC and Core network. AS also works like a delivery service for NAS messages. For
example, PAGING REQUEST is a NAS signalling message that must be delivered
from MSC to UE. Higher layers (NAS) use the services of access stratum protocols
RANAP and RRC to deliver this signalling message to UE. This mechanism is called
Direct Transfer (DT).
Please note that in UMTS, the paging procedure between RNC and UE is differ-
ent from the paging procedure in GSM between BSC and MS. Therefore, the AS
protocols are access-aware protocols.
Non-access Stratum: Non-access stratum is a set of protocols which are access-agnostic.

In other words, these protocols are higher layer end-to-end protocols which do not
depend on the underlying access network. One example of such protocol is Mobility
Management protocol of UMTS. The same MM is used in GSM for procedures like
location update, authentication, paging etc.
NAS protocol messages can be carried over a TDMA-based 2G access network

or CDMA-based 3G access network. The structure of these protocols remain un-
changed.
There are totally 6 NAS protocols defined which will be discussed in section 6.9.
6.4 Radio Protocols

Source:
3GPP TS 25.301: Radio Interface Protocol Architecture.
3GPP TS 25.321: MAC Protocol Specification.
3GPP TS 25.322: RLC Protocol Specification.
3GPP TS 25.323: PDCP Protocol Specification.
3GPP TS 25.324: BMC Protocol Specification.
3GPP TS 25.331: RRC Protocol Specification.
These specifications contain the details of UMTS, HSDPA as well as HSUPA.

But we should pay attention to the version. For HSDPA, the version number
should be 5.0.0 or higher. Similarly, for HSUPA-specific information, the
version number has to be 6.0.0 or higher.
Radio Protocols are the set of protocols which control the communication between UE
and RNC. This section will investigate those set of protocols. As usual, we will focus on
control plane and user plane separately.
6.4.1 Control Plane

The main signalling protocol in 3G is RRC protocol but RRC is a higher layer protocol,
which uses the services of underlying layers L2 (MAC and RLC) and L1 (PHY layer). The
complete protocol stack is shown in figure 6.5. The functions of each individual protocol
layer is explained in the coming sections. This figure also shows the protocol termination
point. The physical layer is implemented by UE and Node B. Similarly, it can be seen
that MAC, RLC and RRC protocols are implemented in UE and RNC.
Figure 6.5: Protocol Termination for DCH, control plane(from TS 25.301)

6.4. RADIO PROTOCOLS 181
As seen in figure 6.5, downlink signalling messages can be either generated by RNC or they
might arrive from the core network which must be forwarded to the user(s). Similarly, in
uplink, the signalling messages from UE can be either processed by RNC or forwarded to
core network.
• Signalling message coming from/going to Core Network: for example, Paging re-
quest/response, authentication request/response, etc.
NAS Signaling from CN → RRC Signalling → RLC → MAC → PHY
Hence, we can identify the first function of RRC layer which is NAS message trans-
port in the uplink and downlink.
• Signalling message generated from/terminated within RNC: for example measure-

ment control/report, handover commands, system information broadcast, etc.
RRC Signalling → RLC → MAC → PHY

This category of RRC messages are used by RNC to control the behaviour of UE.
Similarly, UE can contact RNC and inform about some event that took place.
Note! The details shown in figures 6.5 & 6.6 are applicable to DCH transport channel
only. In order to keep this book at an overview level, the protocol termination for transport
channels RACH & FACH is not shown here. Readers are advised to refer to section 5.6.2
of 3GPP TS 25.301 to learn more. Details about of HS-DSCH and E-DCH will be shown
in their respective module.
6.4.2 User Plane

There are many similarities between the control plane and user plane protocols on the
radio interface. By comparing the figures 6.5 & 6.6, we observe that the RRC protocol is
only for CP whereas in UP we have 2 new protocols: PDCP for packet switched UP and
BMC for the broadcast services.
As we know, in UMTS, the same transport channel (DCH) is used for voice, video, text,
data, streaming and more. Therefore, depending on the service carried by it, the user plane
protocol stack gets slightly modified. In this section, we will learn the set of protocols in
the path of CS service, PS services and broadcast & multicast service.
CS Services
On the transmitter side, the protocol stack for UP is as follows:
CS data streams → RLC → MAC → PHY

Figure 6.6: Protocol Termination for DCH, User Plane(from TS 25.301)
PS Services
On the transmitter side, the protocol stack for UP is as follows:
IP Data flow → PDCP → RLC → MAC → PHY
Broadcast & Multicast Services
On the transmitter side, the protocol stack for BC services is as follows:
Common Traffic or CBS → BMC → RLC → MAC → PHY
6.4.3 RRC-layer Functions

3GPP TS 25.331 is a bulky document with more than 1200 pages (in Rel-6). The details
about all the RRC procedures, RRC messages and their parameters can be found in it.
According to Section 5.1 of TS 25.331, RRC layer performs following functions:
• Non-access stratum message broadcast
• Access stratum related information broadcast
• RRC Connection Management
• Radio Bearer Management

• Management of radio resources for RRC Connection and radio bearers
• Connected mode mobility functions (handover, cell update, URA update, etc.)
• Paging
• Control of requested QoS
• Control of UE measurement reporting
• Outer loop power control
• Control of ciphering
• Initial cell selection and re-selection in idle mode
• Initial Configuration for CBS
• ...
6.4.4 RLC-layer Functions

This section provides an overview on services and functions provided by the RLC sublayer.
The RLC sublayer is a part of L2 in the Radio interface protocol stack. The detailed
description of RLC is available in 3GPP TS 25.322. Depending on the type of information
carried in the RLC SDU, the RLC layer can be configured in 3 modes:
1. Transparent Mode (TM): In this mode, RLC layer processing is very minimal. The
name transparent mode shows that it appears as if the RLC layer is not present in
the processing chain. This mode is generally used for real time user plane services
like voice or video telephony. In this mode, there is no feedback from the receiver
and there is no re-transmission mechanism.
The service provided by RLC layer in TM are:
• Segmentation and reassembly,

• Transfer of user data, and
• SDU discard.
Please note! Ciphering is an important function of the RLC layer. But in the
list above, ciphering is missing. Does it mean that there is no ciphering for the
services which use RLC transparent mode? In other words, is our voice sent without
encryption in UMTS?
Answer is No. When the RLC-sublayer is configured in the Transparent mode, the
ciphering is performed by the MAC sublayer.
2. Unacknowledged Mode (UM): In the unacknowledged mode, there is no guaran-

tee of delivery because there is no retransmission mechanism. This mode can be
used for Voice over IP which is possible with HSPA solution. The following functions
are needed to support unacknowledged data transfer:
• Segmentation and reassembly.

• Concatenation.
• Padding.
• Transfer of user data.
• Ciphering.
• Sequence number check.
• SDU discard.
• Out of sequence SDU delivery.
• Duplicate avoidance and reordering.
• Provisioning of sequence number.
Unacknowledged mode of RLC can be compared to UDP transport, which does

not provide guarantee of delivery but is still a popular transport method due to its
reduced protocol overhead compared to more expensive alternative, i.e., TCP.
3. Acknowledged Mode: The third mode of RLC configuration uses a ACK/NACK

feedback from the receiver and performs re-transmission. Therefore, it is the most
reliable mode which provides some guarantee of delivery. But at the same time,
this mode is most expensive one if we compare the size of the RLC header and the
processing delay. The following functions are needed to support acknowledged data
transfer:
• Segmentation and reassembly.

• Concatenation.
• Padding.
• Transfer of user data.
• Error correction.
• In-sequence delivery of upper layer PDUs.
• Duplicate detection.
• Flow Control.
• Protocol error detection and recovery.
• Ciphering.
• SDU discard.
Other than this, RLC layer also performs the following functions:
• Maintenance of QoS as defined by upper layers.

• Notification of unrecoverable errors.
6.4.5 MAC-layer Functions

Source: 3GPP TS 25.321; Medium Access Control (MAC) protocol specifica-
tion
It can be said that the MAC sublayer is the brain of modern communication
systems like UMTS, HSDPA, HSUPA & LTE. It is the MAC layer who takes
decisions about scheduling and bit rate adjustments. Without the MAC layer’s
priority handling capability, we would not be discussing QoS concept in modern
telecom systems.
The functions of MAC include:
• Mapping between logical channels and transport channels;

• Selection of appropriate Transport Format for each Transport Channel depending
on instantaneous source rate;
• Priority handling between data flows of one UE;
• Priority handling between UEs by means of dynamic scheduling;
• Identification of UEs on common transport channels;
• Identification of MBMS services on common transport channels;
• Multiplexing/demultiplexing of upper layer PDUs into/from transport blocks deliv-
ered to/from the physical layer on common transport channels;
• Multiplexing/demultiplexing of upper layer PDUs into/from transport block sets
delivered to/from the physical layer on dedicated transport channels;
• Segmentation and reassembly of upper layer PDUs;
• Traffic volume measurement;
• Transport Channel type switching and
• Ciphering for transparent mode RLC.
HSDPA-specific MAC (MAC-hs) and HSUPA-specific MAC(MAC-e/es) will

be discussed in their respective modules.
6.4.6 PDCP-layer Functions

Source: 3GPP TS 25.323; Packet Data Convergence Protocol (PDCP) speci-
fication
This section provides an overview on services and functions provided by the Packet Data
Convergence Protocol (PDCP).
Header compression and decompression: Header compression and decompression of

IP data streams (e.g., TCP/IP and RTP/UDP/IP headers) at the transmitting and
receiving entity, respectively. The header compression method is specific to the
particular network layer, transport layer or upper layer protocol combinations e.g.
TCP/IP and RTP/UDP/IP.
Transfer of user data: Transmission of user data means that PDCP receives PDCP
SDU from the NAS and forwards it to the RLC layer and vice versa.
Support for lossless SRNS relocation or lossless DL RLC PDU size change: Maintenance
of PDCP sequence numbers for radio bearers that are configured to support lossless
SRNS relocation or lossless DL RLC PDU size change.
6.5. IU-CS INTERFACE PROTOCOLS 187
Till now, we were focussing on the radio interface protocols. Now, we will draw our
attention towards the protocols used on the UTRAN interfaces Iu-PS, Iu-CS, Iub and Iur.
Due to various options available in transport (IP, ATM, IP over ATM) and then separate
protocol stacks for control plane and user plane, it is very difficult to keep an overview of
the protocol stacks. Therefore, instead of going into the details of every protocol, we will
aim at getting a big picture about the protocols used on every interface. The interested
readers are advised to refer to the 3GPP specs mentioned in the following sections1 .
6.5 Iu-CS Interface Protocols

From protocol description description, Iu-CS and IU-PS are simply referred to as Iu interface.
The following section is written with the reference from following specifications.
Source :
3GPP TS 25.410: ‘‘UTRAN Iu Interface: general aspects and principles’’
3GPP TS 25.411: ‘‘UTRAN Iu Interface Layer 1’’
3GPP TS 25.412: ‘‘UTRAN Iu Interface Signalling Transport’’.
3GPP TS 25.413: ‘‘UTRAN Iu Interface RANAP Signalling’’.
3GPP TS 25.414: ‘‘UTRAN Iu Interface Data Transport and Transport
Signalling’’
3GPP TS 25.415: ‘‘UTRAN Iu Interface User Plane Protocols’’.
6.5.1 Control Plane - Iu-CS

Iu-CS interface connects RNC to the CS-domain of the core network. Therefore, the
protocols stack shown here is implemented in RNC and MSC.
The protocol stacks for the Iu-CS Domain are shown in figure 6.7.
As shown in figure 6.7, there are two options for the realization of transport network, they
are:
• ATM-based transport, &
• IP-based transport
6.5.2 User Plane - Iu-CS

User plane protocols on Iu-CS are shown in figure 6.8. Both ATM-based transport option
and the IP-based transport options are shown.
1
TS 25.41x for Iu, 25.42x for Iur and 25.43x for Iub.
Figure 6.7: Iu-CS control plane protocol architecture (TS 25.410)
Figure 6.8: Iu-CS user plane protocol architecture (TS 25.410)
Figures 6.7 & 6.8 are drawn with the help of Figure 6.1 in 3GPP TS 25.410.
6.5. IU-CS INTERFACE PROTOCOLS 189
6.5.3 RANAP Functions

RANAP provides the signalling service between UTRAN and CN, which are described in
3GPP TS25.413. In this book, we will not dig into the details of each function. A list of
the functions performed by RANAP lyer are listed below:
Relocating serving RNC,
Overall RAB management,
Queuing the setup of RAB,
Requesting RAB release,
Release of all Iu connection resources,
SRNS context forwarding function,
Controlling overload in the Iu interface,
Resetting the Iu,
Sending the UE Common ID to the RNC,
Paging the user,
Transport of NAS information between UE and CN. This function has two sub-
classes:
• 1. Transport of the initial NAS signalling message from the UE to CN.

• 2. Transport of subsequent NAS signalling messages between UE and CN.
Controlling the security mode in the UTRAN,
Controlling location reporting,
Location reporting,
Data volume reporting function,
Reporting general error situations,
Location related data, and
Information Transfer.
6.6 Iu-PS Interface Protocols

Iu-PS interface connects RNC to the PS-domain of core network. Therefore, the protocols
stack shown here is implemented in RNC and SGSN.
6.6.1 Control Plane - Iu-PS

The protocol stacks for the Iu PS Domain is shown in figure 6.9. The standard allows
operators to choose one out of the three standardized protocol suites for transport of SCCP
messages.
Figure 6.9: Iu-PS control plane protocol architecture (TS 25.410)
• ATM-based transport,
• IP-based transport &
• IP over ATM-based transport
6.6.2 User Plane - Iu-PS

There are two options for the transport layer for data streams over Iu-PS.
6.6. IU-PS INTERFACE PROTOCOLS 191
• ATM-based Transport (ATM transport option)
• IP-based Transport (IP transport option)
Figure 6.10: Iu-PS user plane protocol architecture (TS 25.410)
Figures 6.9 & 6.10 are drawn with the help of Figure 6.3 in 3GPP TS 25.410.
6.7 Iub Interface Protocols

Source :
3GPP TS 25.430: ‘‘UTRAN Iub Interface: general aspects and principles’’.
3GPP TS 25.431: ‘‘UTRAN Iub Interface Layer 1’’.
3GPP TS 25.432: ‘‘UTRAN Iub Interface Signalling Transport’’.
3GPP TS 25.433: ‘‘UTRAN NBAP Specification’’.
3GPP TS 25.434: ‘‘UTRAN Iub Interface: Data Transport & Transport
Signalling for Common Transport Channel Data Streams’’.
3GPP TS 25.435: ‘‘UTRAN Iub Interface: User Plane Protocols for
Common Transport Channel Data Streams’’.
Iub interface is used to connect Node B and RNC. For network operation, they must
communicate with each other at regular periods. Whenever a radio link is established,
NBAP protocol is used. Similarly, Node reports the measurements about current UL
interference and DL transmission power to RNC. Based on these reports, RNC performs
Radio Resource Management.
Figure 6.11: Iub control plane protocol architecture (TS 25.430)
6.7.1 Control Plane - Iub CP

The Signalling Bearer for NBAP is a point-to-point protocol. There may be multiple
point-to-point links between an RNC and a Node B. As shown in figure 6.11, the standard
allows operators to choose one out of two protocol suites for transporting the NBAP
messages.
6.7. IUB INTERFACE PROTOCOLS 193
• IP-based transport
6.7.2 User Plane - Iub UP

This section specifies the transport layers that support Common Transport Channel
(FACH, RACH, PCH, DSCH, HS-DSCH) data streams. As usual, there are two op-
tions for protocol suites for transport of RACH, FACH, DSCH and HS-DSCH Iub data
streams, which are shown in figure 6.12.
• IP-based transport.
Figure 6.12: Iub user plane protocol architecture (TS 25.430)
6.7.3 NBAP Functions

The functions performed by NBAP protocol layer are specified in section 7 of 3GPP
TS 25.433. NBAP procedures are divided into common procedures and dedicated
procedures.
• NBAP common procedures or C-NBAP are procedures that are not related
to one particular subscriber or radio link. C-NBAP procedures are common to a
cell.
• NBAP dedicated procedures or D-NBAP are procedures that are related to

a specific subscriber who is identified by Node B Communication Context in Node
B.
The full NBAP specifications are available in 3GPP TS 25.433. From the same specifica-
tion, the functions performed by NBAP are listed below:
Cell Configuration Management,
Common Transport Channel Management,
System Information Management,
Resource Event Management,
Measurements on Common Resources,
Radio Link Management,
Radio Link Supervision,
Compressed Mode Control,
Measurements on Dedicated Resources,
Reporting of General Error Situations,
Physical Shared Channel Management,
Information Exchange,
Bearer Rearrangement, and
MBMS Notification.
6.8. IUR INTERFACE PROTOCOLS 195
6.8 Iur Interface Protocols

Source :
3GPP TS 25.420: ‘‘UTRAN Iur interface general aspects and principles’’
3GPP TS 25.421: ‘‘UTRAN Iur Interface: Layer 1’’
3GPP TS 25.422: ‘‘UTRAN Iur Interface: Signalling Transport’’
3GPP TS 25.423: ‘‘UTRAN Iur Interface: RNSAP Signalling’’
3GPP TS 25.424: ‘‘UTRAN Iur Interface: Data Transport & Transport
Signalling’’
3GPP TS 25.426: ‘‘UTRAN Iur & Iub Interface: Data Transport & Transport
Signalling for DCH Data Streams’’.
Iur interface is the link between any two RNCs within the UTRAN. Its main purpose is to
handle Inter-RNC mobility within UTRAN and hide this mobility from the core network.
If Iur is not present between the two RNCs, then the Inter-RNC soft handover cannot
take place. In this case, a hard handover will be performed instead. For multi-vendor
operability, it is recommended that Iur should be an open interface. Iur interface is not
only used for signalling but also for carrying data streams. RNC-to-RNC interface is a
logical description. It can be implemented even if there is no direct physical connection
between two RNCs.
6.8.1 Control Plane - Iur CP

Due to the similarity between the control plane protocol stack of Iur and Iu-PS, the
description is not given in order to avoid repetition. The protocol stack of control plane
signalling over Iur is shown in figure 6.13. The main control plane protocol on Iur interface
is RNSAP. The word RNS in UMTS means one RNC and several Node B controlled by
it.
All three transport options are shown in figure 6.13.
6.8.2 User Plane - Iur UP

The user plane protocol stack on Iur interface is illustrated in figure 6.14. As we can easily
identify, the protocol stack resembles the user plane protocol stack on Iub. Therefore, the
description can be avoided here as well.
6.8.3 RNSAP functions

The full RNSAP specifications are available in section 7 of 3GPP TS 25.423. The functions
performed by RNSAP are listed below:
Figure 6.13: Iur Interface Protocol Architecture for Control Plane
Figure 6.14: Iur Interface Protocol Architecture for User Plane
Radio Link Management,
Physical Channel Reconfiguration,
Radio Link Supervision,
Compressed Mode Control,

6.8. IUR INTERFACE PROTOCOLS 197
Measurements on Dedicated Resources,
DCH Rate Control,
CCCH Signalling Transfer,
Paging,
Common Transport Channel Resources Management,
Relocation Execution,
Reporting of General Error Situations,
Measurements on Common Resources,
Information Exchange, and
Resetting the Iur.

6.9 Non-Access Stratum Protocols

Till now, in this chapter we have discussed the access stratum. Now it is time for some
NAS signalling. The term access stratum and non-access stratum was explained in section
6.3 at the beginning of this chapter. The fact, that NAS protocols are access-agnostic,
is illustrated on figure 6.15. In this figure, there are 2 access technologies, TDMA-based
BSS (2G) and CDMA-based UTRAN (3G). The NAS messages are depicted with the
bidirectional arrows which flow between UE and core network. The structure of NAS
message does not depend on the underlying access network.
Figure 6.15: Principle of NAS signalling
In figure 6.16, we can see that there are three sublayers in the overall protocol architecture.
These sublayers are:
The Access Stratum (AS) sublayer: The AS sublayer performs the duties of a post-
man and transports NAS signalling messages between UE & core network.
The Mobility Management sublayer: The MM sublayer provides its services to CM.
The MM sublayer contains two protocol entities:
• The MM protocol for mobility related signalling towards the CS core network
domain, and
• The GMM protocol for mobility related signalling towards the PS core network
domain.
The Connection Management sublayer: The CM sublayer consists of four basic pro-
tocol entities: CC, SM, SMS and SS.
If we ignore the AS sublayer and focus on only NAS sublayers, we can conclude that
there are following protocol entities which together constitute the NAS domain. Those six
entities are identified by their protocol discriminator field as shown in table 6.2.
In LTE/EPS, the concept of AS and NAS protocols is reused and the definitions are also
not changed. The protocols which carry signalling messages between UE and Evolved
6.9. NON-ACCESS STRATUM PROTOCOLS 199
Figure 6.16: NAS protocols in UMTS
Name of NAS protocol Protocol Discrimina-

tor
Call Control (CC) 3
Mobility Management 5
GPRS Mobility Management 8
SMS 9
Session Management 10
Supplementary Services 11
Table 6.2: NAS protocols and the protocol discriminator values
Packet Core (EPC) are called NAS protocols and they include 2 protocols: EMM and
ESM. The words MM and SM are already known from 2G & 3G, ‘E’ stands for EPS or
Evolved packet System.
Copyright Notices
Text in section 6.5.3 on page 189 Section 7 of 3GPP TS 25.413 v 7.0.0.

⃝2005.

Figure 6.7 on page 188 Figure 6.1 of 3GPP TS 25.410 v 7.0.0.
Text about RRC Protocol func- Section 5.1 of 3GPP TS 25.331 v 6.9.0.
tions on page 182
Text about Protocol Layers on Section 11.1.2 of 3GPP TS 25.401 v 7.0.0.
page 173
Text about Protocol Planes on Section 11.1.3 of 3GPP TS 25.401 v 7.0.0.
page 173
⃝2006.
6.9. NON-ACCESS STRATUM PROTOCOLS 201

Text in section 6.2.1 on page 177 Section 6.3 of 3GPP TS 23.107 v 7.0.0.
⃝2007.

⃝2010.
BIBLIOGRAPHY
[1] 3GPP TS 23.107 ver. 7.0.0 ;‘Quality of Service (QoS) concept and architecture’
[3] 3GPP TS 25.321 ver. 7.0.0 ;‘MAC protocol specification’
[4] 3GPP TS 25.322 ver. 7.0.0 ;‘RLC protocol specification’
[5] 3GPP TS 25.323 ver. 7.0.0 ;‘PDCP protocol specification’
[6] 3GPP TS 25.324 ver. 7.0.0 ;‘BMC protocol specification’
[9] 3GPP TS 25.410 Ver. 7.0.0 ;‘UTRAN Iu Interface: general aspects and principles’
[10] 3GPP TS 25.411 Ver. 7.0.0 ;‘UTRAN Iu Interface: Layer 1’
[11] 3GPP TS 25.412 Ver. 7.0.0 ;‘UTRAN Iu Interface: Signalling Transport’
[12] 3GPP TS 25.413 Ver. 7.0.0 ;‘UTRAN Iu Interface: RANAP Signalling’
[13] 3GPP TS 25.414 Ver. 7.0.0 ;‘UTRAN Iu Interface: Data Transport and Transport
Signalling’
[14] 3GPP TS 25.415 Ver. 7.0.0 ;‘UTRAN Iu Interface: User Plane Protocols’
[15] 3GPP TS 25.420 Ver. 7.0.0 ;‘UTRAN Iur Interface: general aspects and principles’
[16] 3GPP TS 25.421 Ver. 7.0.0 ;‘UTRAN Iur Interface: Layer 1’
[17] 3GPP TS 25.422 Ver. 7.0.0 ;‘UTRAN Iur Interface: Signalling Transport’
[18] 3GPP TS 25.423 Ver. 7.0.0 ;‘UTRAN Iur Interface: RNSAP Signalling’
202
BIBLIOGRAPHY 203
[19] 3GPP TS 25.424 Ver. 7.0.0 ;‘UTRAN Iur Interface: Data Transport and Transport
Signalling’
[20] 3GPP TS 25.426 Ver. 7.0.0 ;‘UTRAN Iur & Iub Interface: Data Transport & Trans-
port Signalling for DCH Data Streams’
[21] 3GPP TS 25.430 Ver. 7.0.0 ;‘UTRAN Iub Interface: general aspects and principles’
[22] 3GPP TS 25.431 Ver. 7.0.0 ;‘UTRAN Iub Interface: Layer 1’
[23] 3GPP TS 25.432 Ver. 7.0.0 ;‘UTRAN Iub Interface: Signalling Transport’
[24] 3GPP TS 25.433 Ver. 7.0.0 ;‘UTRAN Iub Interface: NBAP Signalling’
[25] 3GPP TS 25.434 Ver. 7.0.0 ;‘UTRAN Iub Interface: Data Transport & Transport
Signalling for Common Transport Channel Data Streams’
[26] 3GPP TS 25.435 Ver. 7.0.0 ;‘UTRAN Iub Interface: User Plane Protocols for Com-
mon Transport Channel Data Streams’
For HSDPA-specific details, the version of these specs should be 5.0.0 or

higher & for HSUPA-specific details, is should be 6.0.0 or higher.
CHAPTER
HIGH SPEED DOWNLINK PACKET

ACCESS
Source: 3GPP TS 25.308,

High Speed Downlink Packet Access (HSDPA); Overall description;
Overview of 3GPP Release 5; available at:

http://www.3gpp.org/ftp/Information/WORK PLAN/Description Releases/
7.1 Why HSDPA?

Actually the question should be Why HSPA? HSDPA (and later HSUPA) was designed
to overcome the limitations of the Rel-99 WCDMA air interface. If an operator disables
HSDPA services from any cell, the maximum bit rate drops from Mbps to kbps range.
UMTS in its basic form (Rel-99 and Rel-4) can theoretically achieve 2 Mbps, both
in uplink and downlink. But these theoretical numbers are very far from the popular
implementation. In most common deployments across the globe, Rel-99 UMTS is able to
show the peak bit rates of only 384 kbps and that too with a very limited coverage. Due
to this, the end-user experience is very poor.
From an operator’s perspective, in order to get high cell throughput, it should be possible
to have several simultaneous users with high bit rates. But due to high fractional load of
204
7.2. HSDPA STANDARDIZATION, 3GPP RELEASES AND EVOLUTION 205
data bearers, unfortunately only a few simultaneous users are possible.

This indirectly also affects the handset manufacturers because all the smart phones, pads
and tablets are useless if they cannot provide fast wireless internet access to the subscribers.
Let us discuss some limitations of Rel-99 UMTS.
End user experience: Due to limited practical bit rates, the end user does not experi-
ence good throughput.
Poor coverage for data bearers: In WCDMA, coverage is separately calculated for
each service. As the service bit rate increases, the coverage area decreases. User
must be in excellent radio condition and the cell load should be quite low, only then
the user can experience the bit rates of several hundred kbps.
Cell capacity: Although the load in cell depends on various factors, but it has been
observed that only a few users of 384 kbps bearer can block the entire cell capacity.
This is very bad for the operator’s revenue and also network accessibility KPI.
Cost of usage: 3G was expected to fulfill the dream which was started by GPRS. Ev-
eryone expected that affordable “unlimited data usage” plans will become popular.
But unfortunately due to the high cost of operation, it did not happen. Hence, one
of the requirements while designing HSDPA was to reduce the cost-per-bit from the
operator’s perspective so that more affordable data plans could be introduced.
Latency: UMTS experiences very high control plane and user plane latency.
Revenue vs. Investment: Due to high cost of spectrum licences, mobile operators ex-
pected a huge revenue which unfortunately did not happen.
3G or no 3G?: People often described 3G as “a system with 2 new services – Video

telephony and broadband data access”. Video telephony never became popular
and data rates in 3G were quite limited. Therefore, the GSM operators were unable
to decide whether they should go for 3G or just settle down with EDGE1 . At the
same time operators started comparing 3G with Mobile-WiMAX solution.
7.2 HSDPA Standardization, 3GPP Releases and

Evolution
Source: 3GPP TS 25.306 ; UE Radio Access capabilities
HSDPA is just a milestone in the journey of High Speed Packet Access (HSPA). Due to
the urgency and demand of higher bit rates in DL, the HSDPA standard was released and
1
EDGE can offer > 200 kbps (practically) & operators do not need to wait/pay for new 3G
licences.
206 CHAPTER 7. HIGH SPEED DOWNLINK PACKET ACCESS
in the next 3GPP release, its counterpart HSUPA was standardized. The terminology
of 3GPP specifications & releases is quite complicated. Therefore, we will try to explain
only the most important features of each 3GPP release in terms of PS NRT data access.
Table 7.1 describes the new categories that were defined when HSDPA was standardized
in Rel. 5. In later releases, newer devices with more advanced features were introduced.
The following section will take us through this journey in a few steps.
UE DC- Peak
Release Mod MIMO
Category HSDPA Bitrate
QPSK,
Release 5 1 to 12 No No 14.4 Mbps
16QAM
Release 6 Same as Rel-5
QPSK,
2X2 with 28 or 21
Release 7 13 to 18 16QAM, No
16QAM Mbps
64QAM
QPSK,
2X2 with
Release 8 19 to 24 16QAM, 2 Carriers 42 Mbps
64QAM
64QAM
Table 7.1: HSDPA features in REL-5, REL-7 & REL-8 (Source TS 25.306, Table
5.1a)
7.2.1 Release 99 & Rel-4

• Basic 3G
• Downlink data services available on FACH and DCH transport channels
• Uplink data services available on RACH and DCH transport channels
• RACH, FACH & DCH are scheduled by RNC’s packet scheduler
• Peak bit rates UL: 384 kbps & DL: 384 kbps
• No concept of CQI reporting, UE categories etc.
• DCH uses a fast power control but no link adaptation mechanism
7.2.2 Release 5
• Commonly called as 3.5G
• DL HSDPA operation without UL HSUPA

7.2. HSDPA STANDARDIZATION, 3GPP RELEASES AND EVOLUTION 207
• DL HSDPA and UL R99 DCH
• DL packet scheduling is done by Node B based on CQI feedback from the UE
• Supported UE categories: 1 to 12
• Peak bit rates in UL: 384 kbps & DL: 14.4 Mbps
7.2.3 Release 6
• HSDPA + HSUPA = HSPA
• Just like HSDPA R5, HSPA is also commonly called as 3.5G
• DL HSDPA operation is a must for UL HSUPA. Hence, HSPA is a synonym for

HSUPA.
• Channel scheduling is done by Node B based on feedback from the UE (e.g., data
buffer status, power headroom, etc.)
• Supported HSDPA UE categories: 1 to 12 (no change compared to R5)
• Supported HSUPA UE categories: 1 to 6
• Peak bit rates in UL: 5.76 Mbps & DL: 14.4 Mbps
7.2.4 Release 7
• Commonly called as evolved HSPA or HSPA+
• Supported HSDPA UE categories: 1 to 12 & 13 to 18
• Support of 2 X 2 MIMO or 64QAM modulation in DL
• Supported HSUPA UE categories: 1 to 6 & 7
• Supported 16QAM Modulation in UL
• Peak bit rates UL: 11.2 Mbps & DL: 28 Mbps
7.2.5 Release 8
• Commonly called as evolved HSPA or HSPA+ (just like Rel-7)
• Supported HSDPA UE categories: 1 to 12 & 13 to 18 & 19 to 24
• Support of Simultaneous “64QAM with MIMO operation” or DC-HSDPA

• Supported HSUPA UE categories: 1 to 6 & 7
• Peak bit rates UL: 11.2 Mbps & DL: 42 Mbps
The points listed in previous section are summarized in table 7.1.
7.3 HSDPA Operation

This section explains the operation of HSDPA from an higher-layer perspective. There
will be a detailed discussion about L1 physical channels and L2 protocols in the later
sections. In this section, we are trying to find an answer to the question ‘ ‘how does
HSDPA operation start?” We will analyze in this process by breaking it into two steps.
1. HSDPA Operation: Between UE and RNC
2. HSDPA Operation: Between Node B and RNC
7.3.1 HSDPA Operation: Between UE and RNC
Figure 7.1: Signalling to initiate an HSDPA session

7.3. HSDPA OPERATION 209
The HSDPA-capable user equipment (mobile phone, smart phone, USB stick modem,
tablet etc.) starts the connection setup in the same manner as a R99 device. Therefore,
on higher layers (L3 and NAS protocols), there are no HSDPA specific messages and
procedures. In other words, the call flow of packet switched connection setup of Rel-99
and Rel-5 are the same which is illustrated in figure 7.1.
At the time of transport channel type selection, if the DL transport channel is HS-DSCH,
in uplink, RNC can choose either DCH or E-DCH based on the UE device capability. UE is
informed about this channel selection by RRC: Radio Bearer Setup or RRC: Radio Bearer
Reconfiguration messages. Using this message, UE comes to know about its HSDPA-
specific id H-RNTI and the HSDPA configuration of the cell.
HSDPA without HSUPA: HS-DSCH in DL and DCH in UL, or
HSDPA with HSUPA: HS-DSCH in DL and E-DCH in UL. This option is available
only for Rel-6 or newer UEs.
7.3.2 HSDPA Operation: Between Node B and RNC

The most remarkable difference between UMTS and HSDPA is the presence of an addi-
tional scheduler in Node B for scheduling the resources to HSDPA users. If the transmitted
packets are not acknowledged, then Node B performs re-transmission. Therefore, it is re-
quired to buffer the user data at Node B. The transfer of data from RNC to Node B takes
place in such a way that the buffer at Node B does not over flow. This procedure is called
Iub flow control and accomplished by the two messages illustrated in figure 7.2.
Figure 7.2: Iub Flow Control
Step 1: RNC asks Node B, “How much can I send for a particular UE”? As shown
in the first message in figure 7.2, the ‘Capacity Request’ message provides the
Node B with information regarding the RNC buffer occupancy for a specific priority
queue belonging to a specific MAC-d flow.
Step 2: Node B informs RNC about the suitable amount. As shown in the sec-
ond message in figure 7.2, the ‘Capacity Allocation’ message is sent from the
serving Node B to the controlling RNC. Its primary purpose is to provide the RNC
with permission to transfer MAC-d PDU belonging to a specific MAC-d flow pri-
ority queue towards the Node B at a specific maximum rate. This message has 3
important parameters:
1. number of credits,
2. time interval, and
3. repetition period.
For example, if the number of credits is 50, the time interval is 20 ms and the repetition
period is 10, then the RNC is permitted to transfer 50 MAC-d PDU every 20 ms during
the next 200 ms. A repetition interval of ‘0’ is interpreted as unlimited repetition, i.e.,
if the repetition period in the previous example was ‘0’, the RNC would be permitted to
transfer 50 MAC-d PDU every 20 ms for an indefinite period.
7.4. WHAT’S NEW IN HSDPA? 211
7.4 What’s new in HSDPA?

HSDPA can be better understood by comparing it with the Rel-99 DCH transport channel.
In other words, we can focus on the new features introduced for HS-DSCH transport
channel.
• Adaptive modulation and coding
• Shorter and fixed TTI (2 ms)
• Node B based packet scheduling
• Multi-code Operation
• L1 H-ARQ retransmission
• MAC-hs protocol in Node B
• Serving Cell Change instead of Soft Handover
7.4.1 Adaptive Modulation & Coding

The Node B selects the modulation and the coding for each TTI for each user
based on an estimate of the downlink. Each UE reports an indicator of the
DL channel quality in the uplink signalling.
One of the main drawbacks of R99 DCH channel is its inflexibility. If the UE comes close
to Node B, power control decreases the transmission power but the bit rate remains the
same. In DCH, bit rate modification is not very easy because the scheduler is located
at RNC and it does not know anything about the current radio conditions. In contrast
to this, in HSDPA, the transport block size for HS-DSCH channel can be changed every
TTI. In other words, 500 times in one second, the bit rates can be adjusted to match
the radio conditions. Table 7.2 illustrates the effect of modulation and coding on the net
user throughput. The number of codes is also a deciding factor in determining the net bit
rates.
7.4.2 Shorter and Fixed TTI

Transmission Time Interval is defined as the inter-arrival time of Transport Block Sets,
i.e. the time it should take to transmit a Transport Block Set. In general, if this time
is big, then the information bits from higher layer will be buffered at MAC layer before
being delivered to the lower layers for transmission.
Gross Bit Net Bit

Modulation Coding Rate # codes
Rate Rate
QPSK 1/4 5 2.4 Mbps 600 kbps
QPSK 1/2 5 2.4 Mbps 1.2 Mbps
16QAM 1/2 10 9.6 Mbps 4.8 Mbps
16QAM 3/4 10 9.6 Mbps 7.2 Mbps
16QAM 4/4 10 9.6 Mbps 9.6 Mbps
16QAM 1/2 15 14.4 Mbps 7.2 Mbps
16QAM 3/4 15 14.4 Mbps 10.8 Mbps
16QAM 4/4 15 14.4 Mbps 14.4 Mbps
Table 7.2: Effect of Modulation and Coding scheme on net bit rate
For the DCH Transport channel, TTI can be either 10, 20, 40 or 80 ms. For HS-DSCH,
TTI has been fixed and its value is 2 ms. In simple words, every 2ms one2 MAC-hs
transport block can be delivered to the physical layer for transmission.
Shorter TTI interval helps in reducing the round trip time (RT) for the user plane.
If HS-DSCH is used for L3 signalling, then the control plane latency can also be reduced.
7.4.3 Node B-based Packet Scheduling

In R99, the packet scheduling is purely handled by RNC. Due to the dynamic nature of the
radio conditions, it is impossible to inform the scheduler about the user’s radio channel’s
quality. Therefore, the bit rate upgrade/downgrade is only possible by RNC. To illustrate
this, two methods are briefly explained below:
High Traffic Volume Measurement: User data might be buffered at UE for Uplink
transmission or in RNC for DL transmission:
• If the amount of data (in Bytes) buffered in user-specific buffer at RNC’s side
exceeds a certain threshold, then RNC automatically tries to upgrade the DL
DCH bitrate (For example, DCH128 to DCH256).
2
From R7 onwards, more than one TB can also be transmitted but that is possible only with
MIMO. From R8 onwards, DC-HSDPA operation can also deliver 2 TABS per TTI.
• If the amount of data (in Bytes) buffered in user equipment’s buffer exceeds a
certain threshold, then UE sends a measurement report to RNC and informs
about this event3 . After receiving this measurement report, RNC automati-
cally tries to upgrade the UL DCH bitrate.
High Throughput Measurement: If a DCH has been allocated to a user in UL & DL,
RNC constantly keeps on measuring the actual throughput in terms of kbps. If the
throughput in UL or/and DL drops/exceeds some operator specific thresholds, then
the allocated bitrates in that direction can be reduced or increased. This mechanism
is called Throughput Based Bitrate Adaptation.
Although the two methods explained above are very effective in adjusting the bitrate
allocation to the UE’s requirements but this mechanism is very slow and it takes
several hundred ms before the bit rate modification takes place. These delays are
caused because the scheduler is residing in RNC and the signalling between UE &
RNC is not very frequent.
By introducing a MAC-hs scheduler at Node B and CQI reporting mechanism, it
is possible to look into the instantaneous channel quality and select the scheduled
user in current TTI. Furthermore, the TB size in that TTI can also be adapted to
the current radio conditions. This is explained in more details in CQI section.
In fact, the dynamic sharing of HS-PDSCH among users is only possible if the
decisions are made by Node B-based scheduler. This changed behaviour is beneficial
for both end-user and the operator. The end-user benefits by always getting the
suitable bitrate and reduced number of retransmission. On the other hand, the
operator can more often allocate resources to the users in favorable conditions and
improve the cell throughput.
7.4.4 Multi-code Operation

• In Rel-99 DCH, the flexibility in bit rates (8, 16, 32, . . ., 384) is achieved by using
variable spreading factor from SF4 to SF256.
• Whereas, in HSDPA, the SF is fixed to 16. Therefore, the flexibility in bit rates
comes from:
– varying the number of SF16 codes simultaneously allocated to a user,

– varying the modulation scheme, and
– varying the channel coding scheme.
CQI reporting is a mechanism where UE suggests the Node B about the suitable modu-
lation, number of codes and suitable transport block size.
3
Commonly known as Capacity Request or Event 4a
A user can be allocated up to 15 HS-PDSCH channel codes. But the instantaneous actual
multicode allocation is decided by UE handset category, instantaneous CQI and the current
load in the cell.
CQI reports one value at a time from the CQI report definition. CQI report definition is a
table containing 31 values, each of which is defined with N parameters. These parameters
shall consist of one or more of the following:
• the transport block size,
• the coding rate,
• the number of HS-PDSCH codes,
• modulation,
• power offsets, etc.
For every UE category, there is a CQI table defined in 3GPP TS 25.214. Since these
specifications are readily available on 3GPP website, we will not show all the tables.
Instead, we will use only two table and try to understand its fields. In the examples, we
will take a low-end device category 6 & a high-end device category 14.
CQI table for UE Category 6

HS-DSCH Category 6 UE has following features
Modulation: QPSK & 16QAM only
Max. # of codes: 5
Category 6 HSDPA device uses CQI table A which is shown in table 7.3
CQI table for UE Category 14

Category 14 has following features
Modulation: QPSK, 16QAM & 64QAM
Max. # of codes: 15
For example, category 14 device uses CQI table D (from 3GPP TS 25.214, not included
in this book), if 64QAM is not configured and table G if 64QAM is configured. CQI table
G is shown in table 7.4.
Transport Block Number of Reference power

CQI value Modulation
Size HS-PDSCH adjustment ∆
0 N/A Out of range
1 137 1 QPSK 0
2 173 1 QPSK 0
3 233 1 QPSK 0
4 317 1 QPSK 0
5 377 1 QPSK 0
6 461 1 QPSK 0
7 650 2 QPSK 0
8 792 2 QPSK 0
9 931 2 QPSK 0
10 1262 3 QPSK 0
11 1483 3 QPSK 0
12 1742 3 QPSK 0
13 2279 4 QPSK 0
14 2583 4 QPSK 0
15 3319 5 QPSK 0
16 3565 5 16QAM 0
17 4189 5 16QAM 0
18 4664 5 16QAM 0
19 5287 5 16QAM 0
20 5887 5 16QAM 0
21 6554 5 16QAM 0
22 7168 5 16QAM 0
23 7168 5 16QAM -1
24 7168 5 16QAM -2
25 7168 5 16QAM -3
26 7168 5 16QAM -4
27 7168 5 16QAM -5
28 7168 5 16QAM -6
29 7168 5 16QAM -7
30 7168 5 16QAM -8
Table 7.3: CQI Table A, taken from Table 7A of TS 25.214
Observations from the CQI tables
By carefully analyzing the information available in CQI tables and comparing the same
for two different device categories, we can make following observations:
Transport Block Number of Reference power

CQI value Modulation
Size HS-PDSCH adjustment ∆
0 N/A Out of range
1 136 1 QPSK 0
2 176 1 QPSK 0
3 232 1 QPSK 0
4 320 1 QPSK 0
5 376 1 QPSK 0
6 464 1 QPSK 0
7 648 2 QPSK 0
8 792 2 QPSK 0
9 928 2 QPSK 0
10 1264 3 QPSK 0
11 1488 3 QPSK 0
12 1744 3 QPSK 0
13 2288 4 QPSK 0
14 2592 4 QPSK 0
15 3328 5 QPSK 0
16 3576 5 16QAM 0
17 4200 5 16QAM 0
18 4672 5 16QAM 0
19 5296 5 16QAM 0
20 5896 5 16QAM 0
21 6568 5 16QAM 0
22 7184 5 16QAM 0
23 9736 7 16QAM 0
24 11432 8 16QAM 0
25 14424 10 16QAM 0
26 15776 10 64QAM 0
27 21768 12 64QAM 0
28 26504 13 64QAM 0
29 32264 14 64QAM 0
30 38576 15 64QAM 0
Table 7.4: CQI Table G, taken from Table 7G TS 25.214
Observation # 1. TB Size divided by 2ms TTI length gives the MAC-hs throughput.
Observation # 2. As the CQI becomes better, TB size, # of HS-PDSCH codes and

modulation scheme is improved.
Observation # 3. Cat 6 & Cat 14 UEs have a similar TB size for poor & medium CQIs.
Therefore, a high-end device experiences better throughput only in the excellent
radio conditions.
Observation # 4. 64QAM modulation of Cat. 14 is only available at CQI ≥ 26.
Observation # 5. In table 7.3, the maximum TB size, max # of codes and the best
modulation is already used at CQI = 15. Therefore, as the CQI becomes better,
there is a reference power adjustment factor. This factor is a negative factor whose
absolute value increases as the radio channel becomes better.
7.4.5 L1 H-ARQ Retransmission

Here the word ARQ stands for Automatic Retransmission Query. In other words, if the
packet received by receiver is erroneous, it will send a negative-acknowledgement which
will trigger the retransmission of the same packet. Some books also call it backward error
correction (BEC) because we take the action after the errors have occurred.
In contrast to backward error correction, there is another scheme called forward error
correction (FEC) or channel coding. In FEC, we add some extra redundant bits to improve
the channel conditions and to fight against the errors. FEC is called so because FEC steps
are performed at the transmitter end before the errors have actually occurred.
The scheme used in HSDPA is a mixture of both FEC and BEC. Therefore, it is called
hybrid -ARQ. The specialty of HSDPA is that this H-ARQ happens at MAC-hs layer
between Node B and UE. UE also needs to play an active part in this scheme. If UE
receives a packet with a lot of errors, it sends a negative-Ack and stores a copy of this
erroneous reception. Later on, after receiving the retransmitted packet, UE has to softly
combine these two versions. This soft combining capacity is decided by the number of soft
channel bits in the handset.
Retransmission on negative acknowledgement can be done in many ways, e.g.,
• Stop-and-Wait
• Go Back ‘N’
• Selective Repeat
• ...
The method chosen for HSDPA retransmission is Stop-and-Wait (SAW) proce-

dure, where the transmitter sends a transport block and waits for the receiver’s response
before sending a new block or retransmitting the erroneous one.
In its basic form, stop-and-wait mechanism is not very efficient, since the transmitter is
inactive until it gets a response. This eventually reduces the throughput. Therefore, in
HSDPA, 3GPP chose a smart way to improve the existing stop-and-wait algorithm. In
HSDPA, Node B can configure up to six parallel H-ARQ processes active for one user.
While Node B is waiting for a feedback from UE for process # 1, data can be transmitted
from process # 2, 3, 4, 5 or 6. Hence, Node B can transmit without interrupting the data
flow.
Figure 7.3: Ilustration of parallel processes of HSDPA H-ARQ scheme
7.4.6 MAC-hs Protocol in Node B and UE

It won’t be any exaggeration if we say that MAC-hs is the brain of HSDPA.
Prior to HSDPA, MAC layer was implemented at RNC. Therefore, only RNC
had the authority to perform packet scheduling for Rel-99 channels.
Please refer to section 7.5 for detailed information about MAC-hs protocols and also its
interworking with it others protocols. In short, the MAC-hs protocol is responsible for:
• packet scheduling,
• transport format combination (TFC) selection,
• L1 Hybrid-ARQ, and
• Iub flow control etc.

7.4.7 Serving Cell Change Instead of Soft HO

UE in HSDPA connected mode does not perform soft handover. While moving from one
HSDPA cell to another HSDPA cell, UE undergoes serving cell change. As a result of
serving cell change, UE stops receiving data from one Node B and starts receiving from
another one. This topic is explained in more details in carefully in section 7.10. In short,
the serving cell change mechanism is divided into three phases (as shown in figure 7.4).
Figure 7.4: HS-DSCH Serving Cell Change; 3 phases
The figure 7.4, explains the serving cell change procedure by dividing into three chrono-
logical steps.
1. When UE is in Source Cell: UE has no radio link with the target cell. HS-DSCH
as well as the associated-DCH channels are only between the UE and the Node B
of the source cell.
2. When UE is in overlapping area of the 2 cells: In the overlapping area, UE sends

a measurement report to RNC and performs soft handover for the associated-DCH
(A-DCH) channel. But the HS-DSCH channel is only received from the source cell.
3. When UE is in Target Cell After leaving the overlapping area, if UE comes to the
target cell’s area, it will maintain the radio link only with the Node B of the target
cell.
When the cell change action is triggered, there is always some interruption of HS-DSCH
but the end-user sees it as a reduced throughput. During this procedure, the user data
buffered at old Node B cannot be transferred to the new Node B. In case of Inter-Node
B serving cell change, the old Node B flushes (or discards) the buffered data and the new
Node B receives the same data from RNC. In case of Intra-Node B serving cell change,
both the source and the target cells are served by the same Node B. Therefore, the same
data can be delivered to UE in the target cell.
7.5. HSDPA PROTOCOL ARCHITECTURE 221
7.5 HSDPA Protocol Architecture
Figure 7.5: MAC-hs Protocol in UE and Node B
Figure 7.5 shows the user plane protocol stack of HSDPA operation. In conventional Rel-
99 operation, MAC-d PDUs are transmitted from RNC to Node B using Frame Protocol
(FP) for DCH. For HSDPA operation, a new ‘FP for HS-DSCH’ is introduced. MAC-d
flows from RNC are buffered at Node B. The data flow on Iub is controlled by MAC-hs
protocol and the procedure is known as Iub Flow Control. Figure 7.5 illustrates a FP data
frame from RNC to Node B.
After getting the CQI reports from UE, Node B can decide the size of MAC-hs transport
block, which is used by Node B to calculate the number of MAC-d PDUs that can be
multiplexed in MAC-hs PDU. Please note that the size of MAC-hs PDU can change every
TTI. Therefore, UE must also be informed about it. The information about the number
of MAC-d PDUs and their sizes is signalled to UE using the header field of MAC-hs PDU.
7.5.1 MAC-hs entity - UE Side

According to section 4.2.3.3 of 3GPP TS 25.321, the functions performed by MAC-hs
entity on UE side is depicted in figure 7.6. These functions are listed in table 7.5. Let’s
discuss them one-by-one.
1. HARQ: The HARQ functional entity handles all the tasks that are required for hy-
brid ARQ. It is responsible for generating ACKs or NACKs. In the case of re-
transmission, UE has to perform soft combining of previous erroneous reception and
new received transport block. There are two popular algorithms for this: Chase
Combining CC and Incremental Redundancy IR. These two schemes are de-
scribed using figure 7.7.
On Node B Side On UE side
1. Flow Control 1. HARQ
2. Scheduling/Priority 2. Reordering Queue dis-

Handling tribution:
3. HARQ 3. Reordering
4. TFRC selection 4. Disassembly
Table 7.5: Summary of MAC-hs protocol functions
Figure 7.6: MAC-hs Protocol in UE Side (from TS 25.321)
Chase Combining: Chase combining is also called as ‘identical retransmis-

sion’. As shown in the upper part of figure 7.7, in chase combining, when
Node B gets a negative acknowledgement for an MAC-hs transport block, it
retransmits exactly the same amount of bits as the original transmission. In
other words, the same Redundancy Version (RV) is used for the original trans-
mission and re-transmission. We can also say that the coding schemes used in
Figure 7.7: Chase Combining (upper) and Incremental Redundancy (lower)

schemes for HSDPA HARQ
transmission and subsequent re-transmissions are identical.

Incremental Redundancy: Incremental redundancy scheme is illustrated in the
lower subfigure of figure 7.7. IR has the liberty to change the redundancy
version after getting a negative acknowledgement.
2. Reordering Queue distribution: Using the QUEUE ID field of MAC-hs header,

UE’s MAC-hs protocol entity forwards the MAC-hs PDUs to the correct reordering
buffer.
3. Reordering: On UE side, one reordering entity is configured for each Queue ID. The
main purpose of this function is to deliver the MAC-hs PDUs with consecutive
Trasnmission Sequence Number (TSN) to the disassembly function. If MAC-hs
PDUs with lower TSN are missing, MAC-hs PDUs are not delivered to the disas-
sembly function.
4. Disassembly: A MAC-hs PDU contains three fields: (1) MAC-hs header, (2) MAC-d
PDUs & and (3) padding bits. Disassembly function removes the other two parts
and extracts the useful part, which is MAC-d PDUs. These MAC-d PDUs are
delivered to the MAC-d protocol layer.
7.5.2 MAC-hs entity - UTRAN Side

In the previous section, we discussed the MAC-hs entity on the UE side. Now we will
focus on the same protocol entity on UTRAN side. In UTRAN, MAC-hs is implemented
in Node B which is shown in figure 7.8. These functions are described in section 4.2.4.3
of 3GPP TS 25.321 and listed in table 7.5.
Figure 7.8: MAC-hs Protocol in UTRAN Side (from TS 25.321)
1. Flow Control: Flow control mechanism has already been discussed in section 7.3 and
figure 7.2.
Flow control function in MAC-d provides a controlled data flow between the MAC-
d (RNC) and MAC-hs (Node B), taking the transmission capabilities of the air
interface into account in a dynamic manner. In other words, the flow control’s
function is to negotiate the numbers of MAC-d PDUs transferred from RNC to
Node B. Node B is in a better position to decide this for individual HSDPA user
because of the received CQI feedback from each user.
The aim of flow control is to limit the layer 2 signalling latency and minimize the
discarded and retransmitted data which can happen due to HS-DSCH congestion.
In case of congestion, Node B can decrease the number of credits which means RNC
will send less amount of MAC-d data. This avoids buffer overflow and makes the
Iub transmission more effective. Flow control is provided independently by MAC-d
flow for a given MAC-hs entity.
2. Scheduling & Priority Handling: Every TTI Node B has to allocate HS-DSCH
resources between HARQ entities and data flows according to their priority class.
Based on UE’s feedback in uplink, Node B decides whether new transmission or
retransmission should be transmitted.
3. HARQ: One HARQ entity is responsible for managing the hybrid ARQ functionality
for one user. As explained in an earlier section (see figure 7.3), we can have up to
six parallel processes per HARQ entity. These multiple processes are used to avoid
the interruption in continuous data flow caused by stop-and-wait HARQ algorithm.
There can be only one HARQ process per HS-DSCH per TTI.
In HSDPA, up to six parallel HARQ processes can be configured. There can be one
HARQ process per TTI, whose identity is signalled to UE using L1 signalling. For
more information, please read about the information delivered on HS-SCCH channel
in a later part of this chapter (section 7.6.2).
4. TFRC selection: Transport Format and Resource Combination selection for the data
to be transmitted on HS-DSCH is very strongly attached to the link adaptation. As
discussed earlier, after receiving the feedback from UE, Node B decides:
• the size of MAC-hs Transport block,

• number of HS codes,
• channel coding rate, &
• modulation scheme etc.
7.6 Channels and Physical Layer

Source: 3GPP TS 25.211 Physical channels and mapping of transport channels
onto physical channels
In chapter 4, we discussed about the logical, transport and physical channels and restricted
our discussion to only Release 99 channels. With HSDPA development, there is no new
logical channel introduced in the system. But a new transport channel is designed which
is known as High speed- downlink shared channel (HS-DSCH). This transport channel is
specially used to carry DTCH logical channel4 . In R99, the logical channel DTCH5 could
be mapped to FACH and DCH transport channels. But with Rel-5, RNC has the options
to select from the choices shown below.
From Rel-5 onwards, the DL logical channel DTCH is mapped to:

 FACH if data volume is very small
= DCH if data volume is large but HSDPA not supported

HS-DSCH if data volume is large and HSDPA is supported
Supported means that both UE device and the UTRAN must be capable of HSDPA
functionality.
The transport channel HS-DSCH is further mapped to HS-PDSCH (High
Speed-Physical Downlink Shared Channel).
Log. Ch. DTCH → Tra. Ch. HS-DSCH → Phy. Ch. HS-PDSCH
In the final section of chapter 4, there was brief overview of the HSDPA related channels
in section 4.6. For clarity, the same figure is shown in figure 7.9.
Now, we will focus on the functionality of L1 signalling for HSDPA operation. As shown in
figure 7.1, the decision to use HS-DSCH is taken by RNC. After this, RNC informs Node
B and UE about the HSDPA configuration to kick-start the HSDPA operation. RNC can
only select the transport channel type but the actual scheduling is done by Node B. As we
know, HS-DSCH is a shared channel which is shared among all the users in a cell. Node
B has to notify the UEs about its scheduling decisions.
The procedure described in figure 7.9 can be understood in 4 steps.
Step 1: Every UE reports its radio conditions in the form of a Channel Quality Indicator
(CQI ). The UL channel used for this feedback is HS-DPCCH.
4
Optionally DCCH can also be carried by HS-DSCH. This is called Signalling Radio Bearer
(SRB) on HSPA.
5
Dedicated Traffic Channel
7.6. CHANNELS AND PHYSICAL LAYER 227
Figure 7.9: HSDPA related physical channels
Step 2: The MAC-hs scheduler at Node B calculates the Priority Metric for all the users
and selects the User (or Users)6 , who will get scheduled in the next TTI.
Each scheduled user is individually notified using an HS-SCCH channel.
Step 3: Exactly 2 slots after the HS-SCCH, Node B transmits data on HS-PDSCH chan-
nel to the scheduled users. There can be maximum 15 HS-PDSCH per cell. One
user can be allocated 1 to 15 HS-PDSCH codes. Therefore, it is also possible to
allocate the whole cell resources to one user.
Step 4: After receiving and decoding the data, each scheduled UE transmits ACK or
NACK in UL. The uplink channel used for this purpose the same as used in step 1,
that is, HS-DPCCH.
In the section below, we will try to investigate these 3 physical channels in more depth.
7.6.1 HS-DPCCH
HS-DPCCH is a dedicated UL channel for sending HSDPA related feedback
information to Node B.
• HS-DPCCH is a dedicated channel. In simple words, if there are, for example, 50

users in HSDPA active mode, then each user will transmit its own UL feedback
channel.
• The timing of HS-DPCCH is organized in sub-frame which is 2ms or 3 slots long.

6
The number of scheduled users is decided by the number of HS-SCCH configured in the cell.
We can have at least one and at most 4 such channels. The most popular choices are 3 and 4.
Figure 7.10: Frame structure for uplink HS-DPCCH (TS 25.211)
• The HARQ-ACK is carried in the first slot of the HS-DPCCH sub-frame.
• The CQI is carried in the second and third slot of a HS-DPCCH sub-frame.
• SF for HS-DPCCH is 256.
• Bit Rate = 15 kbps. Therefore, 30 bits can be sent in UL every TTI.
• 10 bits are used for ACK/NACK and 20 bits for CQI7 .
• CQI repetition cycle can be configured by operator.
Figure 7.10 shows that there are ‘N’ users in a cell and every UE is sending L1 feedback in
uplink using HS-DPCCH channel. The same figure also shows that a 10 ms radio frame is
broken down into 5 sub-frames of 2ms. Each sub-frame can accommodate three slots and
these three slots of HS-DPCCH sub-frame carry two fields.
1. CQI: An active HSDPA UE is bound to report the DL channel conditions back to the
Node B. The network signals the periodicity of channel condition indicator (CQI )
reporting, and whether it is repeated (optionally). The UE measures the received
P-CPICH & uses a proprietary algorithm to calculate CQI. CQI value also strongly
depends on the ratio of HS-PDSCH Power to Total Carrier power. For example,
7
After channel coding 1 bit of ack/nack becomes 10 bits and 5 bits of CQI become 20 bits
6W out of 20W is allocated to HSDPA. Therefore, UE must get this information by

higher layer signalling.
The reported value indicates the maximum amount of data the UE estimates it could
receive given the current channel conditions and UE capabilities. The network can
then use this value as a guideline when it schedules the next block of data. Node
B can of course, perform some vendor specific compensation to this reported CQI.
There are 30 different CQI values for each UE category, so a CQI can be addressed
using 5 bits. However, CQI values are coded using a robust (20,5) code, so the
channel coder output is 20 bits long and fills completely the two slots allocated for
CQI.
2. ACK/NACK: After the UE has received the HS-PDSCH frame and successfully
decoded it, it has to send an ACK (or NACK in case of errors) back to Node B
using a HS-DPCCH channel. The UE has approx. 7.5 slots (5 ms) to complete this
procedure. ACK/NACK channel coding is very robust, because the input consists
of only one bit (ACK=1, NACK=0), and the channel coder simply repeats this ten
times, so the output is ten bits long.
7.6.2 HS-SCCH
Figure 7.11: Subframe structure for the HS-SCCH (TS 25.211)

HS-SCCH is a common DL channel which can be read by every HSDPA users.

Each user reads this channel (or channels) every 2 ms to find out if he has
been scheduled.
If not: UE ignores the content of HS-SCCH (or HS-SCCHs).

If Yes: UE finds out which codes, how many codes, which modulation &,
which Transport Block (TB) Size has been scheduled for him.
• HS-SCCH is a common channel. Operator can configure 1, 2, 3 or 4 such channels

per cell.
• SF for HS-SCCH is 128.
• Bit Rate = 60 kbps. Therefore, 120 bits can be sent in DL on each channel every
TTI.
• It is used to informs all the UEs how and when to receive the HS-PDSCH.
• For example, if 3 such channels are configured then 15 HS-PDSCH codes can be
divided into 3 ‘blocks’ every TTI ( e.g., ‘5+5+5’ or ‘2+8+5’ or ‘3+10+2’ etc.).
Figure 7.11 shows a cell with several users. In this example, the cell has been configured
with only one HS-SCCH channel. In this example, only one UE can be scheduled in
one TTI. Therefore, the cell uses pure time-multiplexing principle. It is also allowed to
have more than one HS-SCCH in a cell. This alternative, increases the overhead in code
and power domain but allows the operator to serve more than one UE in one TTI which
allows us to have code multiplexing of resources. Figure 7.11 also shows that HS-SCCH
transmission is two slots ahead of actual data transmission of HS-PDSCH. In short, we
can say that HS-SCCH informs and prepares the UE to receive HSDPA data on shared
resources.
HS-SCCH channel carries the following fields: .
Channelization Code Set, 7 bits: The CCS field indicates the number of SF16 codes
and the code offset that are used for the HS-DSCH during the specific 2 ms TTI.
Modulation Type, 1 bit: This bit indicates the modulation type. In Rel-5 & Rel-6,
there are only two options. Therefore, one bit is sufficient. But from Release 7,
the third option of 64QAM is also available. Hence, if 64QAM is configured in the
cell, then 7 bits of CCS and 1 bit modulation type should be considered together to
identify the modulation.
Transport Block Size, 6 bits:
Hybrid-ARQ Process ID, 3 bits:
Redundancy and Constellation Version, 3 bits:

New Data Indicator, 1 bit: This bit toggles (0 to 1 or 1 to 0) for every new transmis-
sion and remains the same in case of retransmission.
• 7 bits of ‘Channelization Code Set’ and 1 bit of ‘Modulation Type’ are

multiplexed together. These 8 bits are channel coded and the result is
sent on the first slot of HS-SCCH sub-frame.
• 6 bits of ‘Transport Block Size’, 3 bits of ‘HARQ process ID’, 3 bits of
‘Redundancy and Constellation Version’ & 1 bit of ‘New Data Indicator’
fields are multiplexed together. These 13 bits are channel coded and sent
on 2nd and 3rd slot of HS-SCCH sub-frame.
Several times, it has been stated that HS-SCCH carries the UE identity. But that identity
field is missing from the list shown above. This list is actually copied from section 4.6.2
of 3GPP TS 25.212. Are we missing something?
Yes, we are missing the concept of masking UE identity on the CRC field.
From the aforementioned 21 bits (8 + 13 bits) of HS-SCCH fields, a 16-bit CRC is calcu-
lated by Node B. The CRC is masked with a 16-bit user specific identity called H-RNTI.
H-RNTI is allocated by RNC at the time of radio bearer setup or radio bearer reconfig-
uration, if the HS-DSCH transport channel is selected. Although HS-SCCH transmission
is on three slots of a sub-frame, UE can read the UE identity from the first slot itself.
UE must monitor all HS-SCCHs in the HS-SCCH set. If the UE did detect control
information intended for this UE in the previous subframe, it is sufficient to only monitor
the same HS-SCCH used in the previous subframe. If a UE detects that one of the
monitored HS-SCCHs carries control information intended for this UE, the UE shall start
receiving the HS-PDSCHs indicated by this control information.
For more details, readers are advised to refer to 3GPP TS 25.212; Multiplexing and channel
coding (FDD).
7.6.3 HS-PDSCH
HS-PDSCH is the main DL channel which carries DL data for the subscribers.
• HS-PDSCH is a shared channel. There can be up to 15 such channels per cell
• SF for HS-PDSCH is 16
• Bit rate = 240 ksps per code8
• No soft handover
8
To get kbps, multiply by #bits per symbol, 2 for QPSK, 4 for 16QAM and 6 for 64QAM
Figure 7.12: Subframe structure for the HS-PDSCH (TS 25.211)
• No fast inner-loop power control
The High Speed Physical Downlink Shared Channel (HS- PDSCH) is used to carry the
High Speed Downlink Shared Channel (HS-DSCH). A HS-PDSCH corresponds to one
channelization code of fixed spreading factor SF=16 from the set of channelization codes
reserved for HS-DSCH transmission. Multi-code transmission is allowed, which translates
to UE being assigned multiple channelization codes in the same HS-PDSCH subframe,
depending on its UE capability. According to the principles of channelization codes, there
are 16 codes of SF=16, but one of them CC16,0 is forbidden to use because a SF 256
(CC256,0 ) code from the same branch is used for P-CPICH in the same cell. Therefore, to
maintain orthogonality on DL, it is decided to use only 15 codes for HSDPA transmission.
This concept is described in figure 7.12. The same figure also shows the subframe and slot
structure of HS-PDSCH.
An HS-PDSCH may use QPSK, 16QAM or 64QAM modulation symbols. All relevant
Layer 1 information is transmitted in the associated HS-SCCH i.e. the HS-PDSCH does
not carry any Layer 1 information. The slot formats for HS-PDSCH are shown in table
7.6. The three rows of this table emphasize the effect of modulation on channel bit rate.
Slot format Channel Bit Channel Symbol Bits/ HS-DSCH

SF
#i Rate (kbps) Rate (ksps) subframe
0 (QPSK) 480 240 16 960
1 (16QAM) 960 240 16 1920
2 (64QAM) 1440 240 16 2880
Table 7.6: HS-DSCH fields (TS 25.211)
Figure 7.13: All Channels in REL-5 Configuration (including A-DCH)
7.6.4 Associated DCH

A-DCH or associated DCH is the new name used for the well-known R99 DCH
channels when these channels are used in association with HSDPA channels.
Uplink: In UL, the Control channel (DPCCH) and Data channel (DPDCH) are code
multiplexed. DPCCH is used for carrying L1 Control9 bits & DPDCH is used for
carrying for user data and signalling radio bearer (SRB or L3 signalling)
Downlink: In DL Control channel and Data channel are time multiplexed. The multi-
plexed channel is called DPCH. Hence, DPCH is used for L1 control, User Data and
SRB.
One again, we would emphasize that A-DCHs are dedicated channels. Therefore, if there
are 50 active HSDPA users then there will be 50 UL channels and 50 DL channels. Due
to this, every active user’s A-DCH will cause additional UL interference and DL code &
power congestion.
9
TFCI, Pilot Bits and TPC
Figure 7.14: Fractional DPCH Channel as reduced version DL DPCH (TS 25.211)
7.6.5 Fractional-DPCH
As the name implies, F-DPCH is a fractional version of the normal DL DPCH

channel. For every active HSDPA user, one DL DPCH is needed but one F-
DPCH can be used by upto 10 users. This solves DL code and power congestion
up to some extent.
An F-DPCH carries control information generated at layer 1 (TPC com-

mands) for one uplink DPCCH.
As explained in section 7.6.4, every active HSDPA user requires one SF256 from DL
channelization code tree. At the time of writing this book (August 2012), vendors are
supporting more than 70 active HSDPA users per cell. If conventional A-DCH is used,
then for every active user a DL SF256 code will be reserved for DPCH. To solve this
problem, 3GPP has introduced DL Fractional-DPCH which can be used as a replacement
for DL DPCH. But there are a few prerequisites for using F-DPCH.
• F-DPCH is possible for HSDPA+HSUPA.
• SRB on HSPA must be configured because DL RRC signalling cannot be conveyed

on F-DPCH.
As shown in figure 7.14, Normal DPCH with SF 256 can be used to transmit 20 bits per
time slot. But in Fractional DPCH, the transmitter is ‘OFF’ for 18 bits and ‘ON’ for only
two bits. These two bits are DL TPC (Transmit Power Control) command. The users are
allocated a slot format number (0, 1, 2, . . . , 9). Based on the slot number, UE finds out
when TPC bits are transmitted for him. In the remaining 90% of time, other nine users
are provided with their respective TPC commands. In the same figure, an example of slot
format # 4 is shown. The exact definition of each slot format # can be found in table 7.7.
7.7. TIMING OF HSDPA CHANNELS 235
Slot Format Total NOFF1 NTPC NOFF2

SF
# Bits/Slot Bits/Slot Bits/Slot Bits/Slot
0 256 20 2 2 16
1 256 20 4 2 14
2 256 20 6 2 12
3 256 20 8 2 10
4 256 20 10 2 8
5 256 20 12 2 6
6 256 20 14 2 4
7 256 20 16 2 2
8 256 20 18 2 0
9 256 20 0 2 18
Table 7.7: F-DPCH fields (from 3GPP TS 25.211)
7.7 Timing of HSDPA Channels

Source: 3GPP TS 25.211;
section 7; Timing relationship between physical channels
A simplified HSDPA operation is depicted in figure 7.15. In the example shown in this
figure, we have assumed that there is only one HS-SCCH in the cell and the UEs are
expected to send CQI reports every 2 ms. UE # 1 is scheduled in first TTI, UE #2 and
UE # 3 in the 2 next TTIs and UE #2 is again scheduled in the 4th TTI. The same
figure (fig. 7.15) also shows the behaviour of UE # 1 and UE # 2 from the reception and
transmission perspective.
x
It can be seen that CQI reports are sent periodically. If the HSDPA user gets scheduled,
it receives data and sends either positive or negative acknowledgement. A/NACK are sent
on the first time slot of HS-DPCCH channel.
Timing of HS-SCCH: This downlink channel has the same reference and frame timing
as P-SCH, S-SCH, P-CPICH and P-CCPCH. The start of HS-SCCH subframe #0
is aligned with the start of the P-CCPCH frames.
Timing of HS-PDSCH: Figure 7.15 illustrates the timing structure for the HS-DSCH
control signalling. The fixed time offset between the HS-SCCH information and the
start of the corresponding HS-DSCH TTI equals 2 × time slots (2*Tslot=5120chips).
Timing of HS-DPCCH: The timing of HS-DPCCH is calculated in relation to the DL
HS-PDSCH reception time and UL DPCCH/DPDCH transmission time. The rela-
tive timing between DPCCH/DPDCH and HS-DPCCH is kept constant.
Figure 7.15: Summary of HSDPA operation and timing
• The start of HS-DPCCH subframe which carries Ack/Nack for the received
HS-PDSCH data is approx. 7.5 Time slot after the reception of corresponding
HS-PDSCH subframe at UE receiver.
• The time offset between UL DPCCH/DPDCH and HS-DPCCH is a multiple

of 256 chip (n × 256 chips).
7.8 HSDPA UE Categories
Quite often the network performance is limited by the population of low-end HSDPA
devices on the network. Therefore, it is quite important to learn about the maximum bit
rates that can be achieved by a certain UE category. Every 3GPP release has added new
functionalities to HSDPA operation and thereby defined new device categories. According
to 3GPP Rel-9, there are 28 HSDPA UE categories, whose details are readily available in
3GPP TS 24.306. The purpose of this book is to make the learning easier. Therefore, we
would focus on the device categories according to each release.
7.9. HSDPA PEAK BITRATE CALCULATION 237
Category Modulation Max. Codes

11 & 12 Only QPSK 5
1 to 6 5
7&8 QPSK & 16QAM 10
9 & 10 15
Table 7.8: UE categories according to Rel-5 & Rel-6

Category Modulation Max. Codes MIMO Support
11 & 12 Only QPSK 5 No
1 to 6 QPSK & 16QAM 5 No
7&8 QPSK & 16QAM 10 No
9 & 10 QPSK & 16QAM 15 No
13 & 14 QPSK & 16QAM & 64QAM 15 No
15 & 16 QPSK & 16QAM 15 Yes
17 & 18 QPSK & 16QAM & 64AM 15 No
17 & 18 QPSK & 16QAM 15 Yes
Table 7.9: UE categories according to Rel-5, Rel-6 & Rel-7
7.9 HSDPA Peak Bitrate Calculation

In this section, we will investigate the maximum bit rates that can be achieved with an
HSDPA device of certain category. The word maximum here means the peak instantaneous
bit rate for 2ms TTI. In order to calculate the average throughput, we should also consider
those TTIs where the user was not scheduled.
[ ]
Rchip
Data Rate per code = Symbols/second
SF
Bit Rate per code = [Data Rate [ksps] × Bits per Symbol] kbps ,

 2 if Modulation is QPSK,
Bits per Symbol = 4 if Modulation is 16QAM,

6 if Modulation is 64QAM .
Max. Gross Bit Rate = [Bit Rate per code × Max. # of codes supported] kbps
Max. Net Bit Rate = [Gross Bit Rate] × [Channel Coding Rate] kbps
Let us take examples of device categories 12, 6, 8, 10, 14 & 16 and calculate the peak net
bit rates achieved. In this example, we will assume channel coding rate of 3/4. Please
refer to table 7.10.
UE Symbol Best Mod- # Rbit

Bit Rate Rbit (Net)
Cat. Rate ulation codes (Gross)
12 240 Ksps QPSK 480 kbps 5 2.4 Mbps 1.8 Mbps
6 240 Ksps 16QAM 960 kbps 5 4.8 Mbps 3.6 Mbps
28.8
16 240 Ksps 16QAM 960 kbps 15 1.8 Mbps
Mbps10
Table 7.10: Example of peak bit rate calculation for several devices categories
While doing the same calculation for a UE which supports MIMO operation, the final
result can be multiplied by 2. Because in the MIMO scheme, where 2 transport blocks are
multiplexed on the same TTI, the peak bit rates are doubled.
7.10. SERVING HS-DSCH CELL CHANGE 239
7.10 Serving HS-DSCH Cell Change
Figure 7.16: Inter-Node B serving HS-DSCH cell change (TS 25.308)
According to 3GPP TS 25.308, “A serving HS-DSCH cell change facili-

tates the transfer of the role of ‘serving HS-DSCH radio link’ from one radio
link belonging to the source HS-DSCH cell to a radio link belonging to the
target HS-DSCH cell”.
As discussed in chapter 5, mobile in CELL DCH mode performs soft-handover or hard-

handover in order to maintain the connectivity with UTRAN. However, for HS-PDSCH
allocation for a given UE belongs to only one of the radio links assigned to the UE, the
serving HS-DSCH radio link. The cell associated with the serving HS-DSCH radio link is
defined as the serving HS-DSCH cell. While moving, UE can perform serving HS-DSCH
cell change. Quite often, people call it HSDPA Serving Cell Change (SCC).
This mechanism is almost similar to a hard handover with a small difference that during
transition UE may perform soft handover on A-DCH channels with source and target
cells. Hence for HS-DSCH, UE does not perform Soft handover but for the associated-
DCH (A-DCH) it does. The source and the target cells can be controlled by the same Node
B or two different Node Bs. Thus, we need to discuss two different mobility scenarios:
In 3GPP 25.308, several ways to classify the Serving HS-DSCH Cell change procedures
are defined. We will discuss the classification which is based on the serving HS-DSCH
Node B. The signalling scenarios related to these procedures are discussed in chapter 9.
Intra-Node B serving HS-DSCH cell change: In this scenario, the source and the
target cells are two adjacent sectors of the same site (Node B). Therefore, the
unacknowledged data which is buffered at Node B can be transmitted to the user
using new radio link. There is no need to flush the data. Intra-Node B SCC has
less interruption in service.
Inter-Node B serving HS-DSCH cell change: In contrast to the earlier case, in this
case, the source and the target cells are controlled by two different Node Bs. There-
fore, when the user moves into the new cell, the unacknowledged buffer data at old
Node B must be flushed and the new Node B must get the same from RNC. As
expected, this causes delay and increases the service interruption time.
For UE it is irrelevant whether the serving HS-DSCH cell change procedure is of a intra-
Node B or inter-Node B nature. The cell change decisions are always made by UTRAN.
Hence SCC procedure of HSDPA is known as network-controlled serving HS-DSCH cell
change. A network controlled HS-DSCH cell change is performed as an RRC layer sig-
nalling procedure and is based on the existing handover procedures in CELL DCH state.
The detailed signalling between UE and RNC related to both Inter-Node B and Intra-
Node B Serving Cell Change is described in the in chapter 9 along with other intersting
signalling scenarios related to UMTS and HSPA.
7.11. SUMMARY: HSDPA OPERATION IN SHORT 241
7.11 Summary: HSDPA Operation in Short

The whole communication between UE and Node B can be explained using the 3 physical
channels designed for HSDPA operation. This procedure is illustrated in figure 7.17. In
short, the various steps are as following:
Figure 7.17: HSDPA operation explained using the physical channels.
Channel Direction Function SF Modulation Ch. Coding

Carries DL user QPSK &
HS-PDSCH ↓ 16 1/3 Turbo coding
data 16QAM
1/3
Carries
HS-SCCH ↓ 128 QPSK Convolutional
scheduling info
coding
ACK =
‘1111111111’
HS- Used to send UL NACK =
↑ 256 BPSK
DPCCH feedback ‘0000000000’
CQI = (20,5)
Block coding
Table 7.11: Summary of HSDPA channels

Copyright Notices
Table 7.3 on page 215 Table 7A of 3GPP TS 25.214 v 9.1.0.

Table 7.4 on page 216 Table 7G of 3GPP TS 25.214 v 9.1.0.
Figure 7.10 on page 228 Figure 2A of 3GPP TS 25.211 v 9.1.0.
Figure 7.12 on page 232 Figure 26B of 3GPP TS 25.211 v 9.1.0.
Table 7.7 on page 235 Table 16C of 3GPP TS 25.211 v 9.1.0.
⃝2009.
c TM
Text in section 7.5.1 on page 221 Section 4.2.3.3 of 3GPP TS 25.321 v 7.7.0.
Text in section 7.5.2 on page 224 Section 4.2.4.3 of 3GPP TS 25.321 v 7.7.0.
Figure 7.6 on page 222 Figure 4.2.3.3.1 of 3GPP TS 25.321 v 7.7.0.
Figure 7.8 on page 224 Figure 4.2.4.3.1 of 3GPP TS 25.321 v 7.7.0.
⃝2008.
c TM
7.11. SUMMARY: HSDPA OPERATION IN SHORT 243
Table 7.1 on page 206 Table 5.1a of 3GPP TS 25.306 v 9.1.0.

Text in section 7.6.2 on page 229 Section 4.6 of 3GPP TS 25.212 v 9.3.0.
⃝2010.
BIBLIOGRAPHY
[2] 3GPP TS 25.308 ver. 7.0.0 ;‘High Speed Downlink Packet Access (HSDPA); Overall
Description;’
[3] 3GPP TS 25.306 ver. 9.0.0 ;‘UE Radio Access capabilities’
[15] H.Holma and A. Toskala, ‘HSDPA/HSUPA for UMTS’ , 1st Edition, John Wiley
& Sons.
244
CHAPTER
HIGH SPEED UPLINK PACKET

ACCESS
Source: 3GPP TS 25.319; Enhanced uplink; Overall description
After learning the important facts about High Speed Downlink Packet Access (HSDPA)
in the previous chapter, the next logical step is to investigate the improvements in uplink.
These new set of improvements are known as “High Speed Uplink Packet Access (HSUPA)
or Enhanced Uplink1 ”.
The first release of HSDPA standard was available in 3GPP Rel-5. HSUPA was standard-
ized in 3GPP Rel-6. Once again, the design targets are very similar to HSDPA. But in
Uplink, there are some additional requirements which need to be met. These requirements
are discussed in 3GPP 25.319. Some of those points are mentioned below.
8.1 Requirements
• The uplink coverage for R99 DCH channel is generally very limited. Therefore, the
end user experience in wide area cells is not very good.
1
Enhanced Uplink (EUL) is the official name chosen by 3GPP but due to popularity of HSDPA,
the term HSUPA is also very widely used.
245
246 CHAPTER 8. HIGH SPEED UPLINK PACKET ACCESS
The Enhanced Uplink feature is targeted at providing a significant improvements in

terms of user experience (throughput and delay) and/or capacity. The coverage is
one of the aspects which affect the user experience. For an operator, it is desirable
to have good coverage to provide consistency of performance across the whole cell
area. Therefore, it is expected that HSUPA should serve a wider cell area. Hence,
coverage will be one of the main design criterion while development. In contrast to
this, in HSDPA, the focus was on DL throughput.
• HSUPA should be designed to serve urban, sub-urban and rural deployment scenar-
ios.
• HSUPA should support full mobility. Undoubtedly, the system is best optimized for
stationary users but it should perform well for fast-moving users as well.
• HSUPA should be designed with least complexity so that the user equipment’s (UE)
& network elements’ cost is not very high. In R99 specification, there were a lot
of features that are practically not used anywhere. In HSUPA development, such
features should be avoided so that the time-to-market can be reduced.
• It is required that HSUPA should provide improved QoS compared to R99 UL ded-
icated channels. The main focus should be on the services of streaming, interactive
and background traffic classes.
• There is always a trade-off between performance improvement & complexity

of upgrades. HSDPA introduced a lot of changes in hardware and protocol archi-
tecture. It is desirable that changes caused by HSUPA should be as little as possible.
According to 3GPP TS 25.319: “New techniques or group of techniques shall there-

fore provide significant incremental gain for an acceptable complexity”.
• The improvements should be designed in such a away that HSUPA can be introduced
to a network which has UEs of different radio capabilities, i.e., R6 UEs and the UEs
from R99, R4 and R5.
• A terminal supporting the Enhanced Uplink feature must support HSDPA. There-
fore, the term HSPA can be used to describe the combination of HSDPA and
HSUPA. In our further discussions, we will use HSPA as a synonym for HSUPA.
From the end-user point of view, HSUPA is an enhancement to Rel-99 UTRAN which
allows him to achieve higher Uplink peak bit rates in a wider service area compared to
classical R99 solution for Uplink data transmission. This is an important upgrade because
the UL bit rates of R99 DCH are very low when the UE is at cell-edge.
8.2. COMPARISON WITH HSDPA 247
8.2 Comparison with HSDPA

As the names indicate, HSDPA and HSUPA sound very similar. Therefore, we commonly
assume that HSUPA is nothing but ‘HSDPA for Uplink’. This is not exactly true. To
investigate this issue further, let’s discuss the commonalities and differences between the
two technologies.
8.2.1 Commonalities with HSDPA

Node B based scheduling: The transport channels used to carry the user data in R99
UMTS are RACH (↑), FACH (↓) & DCH (↕). All of these channels are scheduled
by RNC’s packet scheduler. This concept was explained in HSDPA module.
HSDPA transport channel HS-DSCH and HSUPA transport channel E-DCH are
both scheduled by Node B based packet scheduler.
Fast L1 H-ARQ: In HSUPA, the data transmitted via E-DCH transport channel re-
quired immediate acknowledgements from Node B. This concept was introduced
in HSDPA where the role of transmitter is played by Node B and UE sends the
acknowledgment.
Multicode Operation: The peak UE bit rates in HSDPA are achieved by sending data
to a user on multiple SF16 codes. Similarly, in HSUPA, UE can send uplink data
on either 1, 2 or 4 channelization codes.
Link Adaptation: Based on the UE radio conditions, data volume and many other
conditions, UE resource allocation can be modified. This concept is common in
HSDPA and HSUPA.
• Rel-5 HSDPA devices support QPSK & 16QAM modulation2 . Therefore, link
adaptation happens by adaptive modulation and coding (AMC).
• Rel-6 HSUPA devices support only BPSK modulation. Therefore, the link
adaptation happens mainly by adaptive coding (AC) only.
Shorter TTI: The Rel-99 transport channel DCH supports the TTI length of 10, 20, 40
or 80 ms. HSDPA utilizes a significantly shorter TTI of 2 ms. In HSUPA:
• 10 ms TTI is a mandatory for every network and the UE. This is to ensure
that UE will be able to use HSUPA when it finds itself in a poor coverage area.
• 2 ms TTI is optional. 2 ms will allow the user to achieve higher peak bit rates
and lower latency, but 2ms TTI can be used only if the UE is in good radio
conditions.
2
Except special category 11 & 12 UEs
8.2.2 Differences from HSDPA

Power Control: In HSDPA, all 3 slots in a subframe are transmitted at a constant
power. In other words, there is no fast inner loop PC for HSDPA. But in HSUPA,
the power control is very crucial for minimizing the near-far effect.
In HSDPA, there is a central transmitter in Node B whereas in HSUPA, the trans-
mitters are distributed across the whole cell coverage area. Therefore, management
of interference requires more signalling in HSUPA.
Soft Handover: HSDPA performs a (hard) Serving Cell Change whereas, in HSUPA the
E-DCH channel can be in soft-handover with up to 3 Cells.
Variable Spreading factor: In HSDPA, the SF = 16, which is fixed. But in HSUPA,
UE gets a resource grant from Node B and decides which SF to use. It is allowed to
use eight possible spreading factors (SF 256, 128, ..., 2). This is shown in table 8.4.
Overall Procedure: In HSDPA, the scheduler resides in Node B and data is also buffered
at Node B & RNC side. Therefore, Node B can very well decide how much bitrate
will satisfy the need of the user. On the contrary, in uplink, the scheduler needs to
know the status of the UE buffer. There has to be some periodic reporting of the
buffer status.
• In HSUPA, we have some kind of

Request → Grant → Data Transmission → Acknowledgement
mechanism. Whereas,
• In HSDPA, we have
Notification to UE → Data Transmission → Acknowledgement
type of mechanism.
8.3 HSUPA User Plane Protocols

A detailed description of PDCP, RLC and MAC-d protocols is available in chapter 6.
HSUPA related MAC protocols are MAC-e and MAC-es, which are explained later in this
chapter.
In this section, we will examine the HSUPA transmission only in an overview manner.
1. On UE Side • PDCP layer compresses the headers belonging to higher layers e.g.,
TCP/IP or RTP/UDP/IP.
• RLC layer performs segmentation on the big data block received from PDCP
layer. The size of RLC PDU is explicitly signalled to the user via RRC sig-
nalling3 . RLC also performs ciphering. If the Acknowledged Mode (AM) of
RLC is configured, then RLC layer keeps track of L2 retransmissions.
3
in RB setup or RB Reconfiguration message.
8.3. HSUPA USER PLANE PROTOCOLS 249
Figure 8.1: HSUPA User Plane Protocols
• MAC-d layer in UE generates the MAC-d flows. MAC-d layer is transparent

in HSUPA. Therefore, the MAC-d PDU is exactly the same as RLC PDU.
• MAC-es layers combines MAC-d PDUs of the same logical channel and same
size into one MAC-es PDU. MAC-es layer adds a Transmission Sequence Num-
ber which will help the RNC to re-order the correctly received MAC-es PDUs.
• MAC-e layer in UE, combines several MAC-es PDUs and form a MAC-e PDU.
• Physical layer in UE carries on L1 processing and transmits the data on
WCDMA air interface.
2. On Node B Side • Node B’s Physical layer receives the data coming from UE’s
physical layer.
• MAC-e layer in Node B checks for L1 H-ARQ and decides whether an Ack or
Nack has to be sent.
• MAC-e layer demultiplexes the MAC-e PDU and extracts the MAC-es PDUs
which are sent towards RNC.
3. On RNC Side • By looking into the ‘transmission sequence number (TSN)’, MAC-
es layer of RNC re-orders the correctly received MAC-es PDUs. It demulti-
plexes the MAC-es PDUs to extract the MAC-d pdus. In HSUPA, UE can
be in soft handover with more than one cell. Therefore, MAC-es layer also
performs Macro Diversity Combining (MDC) to achieve the link diversity.
• Finally, the correctly received MAC-d PDUs are forwarded to the MAC-d layer.
• RLC layer in RNC checks whether a L2 Ack or Nack has to be sent to the UE.
On RNC side, the RLC layer performs reassembly of several RLC blocks and
constructs a big data block to be delivered to the PDCP layer.
• PDCP layer in RNC performs header decompression and restores the original
header of higher layer application.
Summary of HSUPA Operation (according to TS 25.401):

“The E-DCH MAC (MAC-e/MAC-es) entity in the UE trans-
fers MAC-e PDUs to the peer MAC-e entity in the Node B and
MAC-es PDUs to the peer MAC-es entity in the RNC using the
services of the Physical Layer”.
8.4 HSUPA Configuration Options

At first sight, one can guess that E-DCH transport channel is mainly designed for carrying
uplink user data (Logical channel DTCH). Similarly HS-DSCH transport channel is mainly
designed to transmit downlink user data.
But if we carefully examine options available for mapping the Signalling Radio Bearers
(SRB) on transport channels, operators have two choices. This section investigates both
options. The general channel structure of UMTS was discussed in chapter 4.
Figure 8.2: HSUPA Control Plane Protocols - SRB on DCH
Option 1: SRB on DCH: In this configuration, HS-DSCH channel and E-DCH chan-
nel is used to carry the DTCH logical channel whereas the logical channel DCCH
or RRC signalling4 is still sent via UL & DL DCH channels. Obviously this option
is not the best option because it includes a lot of DCH overhead channels. The
control plane protocol stack for this option is exactly the same as Rel-99 control
plane protocol stack as shown in figure 8.2.
SRB on DCH option does not reduce the control plane latency.
4
also known as Signalling Radio Bearer SRB or L3 Signalling
8.5. E-DCH UE CATEGORIES AND BIT RATES 251
Figure 8.3: HSUPA Control Plane Protocols - SRB on HSPA
Option 2: SRB on HSPA: Alternatively, HS-DSCH and E-DCH channels can be con-
figured to send both User data DTCH and DCCH. This option is commonly known
as SRB on HSPA. The control plane protocol stack for this configuration is illus-
trated in figure 8.3.
This option significantly reduces the amount of DCH overhead channels and control
plane latency.
SRB on HSPA is a pre-requisite for some other smart features, for example, Fractional-
DPCH (F-DPCH).
8.5 E-DCH UE Categories and Bit Rates

Source: 3GPP TS 25.306 ; UE Radio Access capabilities
In HSDPA, we have learnt about a variety of UE categories. Up to Release 9, there

are 28 HS-DSCH UE categories defined for HSDPA operation. Similarly, there exist
some standard UE categories for HSUPA operation too. In order to follow the HSUPA
development in chronological order, the E-DCH UE categories are illustrated in three
different tables.
• Rel. 6: Category 1, 2, 3, 4, 5 & 6 are introduced.
• Rel. 7: Category 7 UE has been added to the list of UE categories. Main enhance-
ment is 4-PAM modulation on E-DPDCH channel (which is quite often referred to
as 16-QAM).
• Rel. 8: No new Category defined in Rel-8.

• Rel. 9: Category 8 & 9 Categories have been added which support Dual Cell-HSUPA
(or DC-HSUPA) operation.
E-DCH Max Min. Supported Max. TB Max. TB Modul.

Category no. of SF TTI Size [bits] Size [bits]
E-DCH in 10 ms in 2 ms
Codes TTI TTI
Cat. 1 1 SF4 10 ms only 7110 - BPSK
Cat. 2 2 SF4 10 ms & 2 ms 14484 2798 BPSK
Cat. 4 2 SF2 10 ms & 2 ms 20000 5772 BPSK
Cat. 6 4 SF2 10 ms & 2 ms 20000 11484 BPSK
Table 8.1: E-DCH UE Categories introduced in 3GPP Rel. 6 (25.306)

Codes TTI TTI
Cat. 7 4 SF2 10 ms & 2 ms 20000 22996 4-PAM
Table 8.2: Additional E-DCH UE Categories in 3GPP Rel. 7 (25.306)

Codes TTI TTI
Cat. 8 4 SF2 10 ms & 2 ms 20000 11484 BPSK
Cat. 9 4 SF2 10 ms & 2 ms 20000 22996 4-PAM
Table 8.3: Additional E-DCH UE Categories in 3GPP Rel. 9 (25.306)
After observing the tables 8.1, 8.2 & 8.3, we can make some remarks about the various
UEs of different categories.
1. Multi-code Support: Some UEs do not support multi-code operation on E-DPDCH

(for example Cat. 1 UE), some support upto 2 codes (for example Cat. 2, 3, 4, &
5) while some UEs support upto 4 code transmission (for example UE cat. 6, 7, 8
& 9).
8.6. STARTING OF HSUPA OPERATION 253
2. Min. SF: SF2 was introduced in 3GPP REL-6 for E-DPDCH channel. But all the
UEs cannot use SF2. This aspect of their radio access capabilitis is shown in the
column ‘Min. SF’ in the UE categories tables.
3. TTI Support: Both 2 ms and 10 ms TTI have their own advantages and disadvan-
tages. 10 ms TTI is a mandatory feature which is supported by all UEs but 2 ms
TTI operation is possible only for UE cat. 2, 4, 6, 7, 8 & 9.
4. Modulation: Cat. 1 to 6 and cat. 8 can transmit data using BPSK modulation (one
bit per symbol) only whereas the UE category 7 & 9 can also use 4PAM; modulation
(2 bits per symbol).
5. DC-HSUPA: Only Rel. 9 categories UEs, i.e. Category 8 & 9 UEs, can support
DC-HSUPA operation.
8.6 Starting of HSUPA Operation

As discussed in the chapter 5 about the Radio Resource Management, we saw that RNC’s
PS is responsible for deciding the ’transport channel type selection’. This procedure can
yield 4 possible outcomes:
1. RACH & FACH
2. DCH & DCH
3. DCH & HS-DSCH
4. E-DCH & HS-DSCH
As shown in figure 8.4, every HSUPA device starts the signalling procedure as if it were
a simple R99 UE. After performing GPRS ATTACH, the serving SGSN, UE acquires a
P-TMSI and knows about the Routing area ID of the cell. As a result of GPRS attach,
there is a MM context stored in UE and SGSN. Later, UE establishes a PDP context and
tries to acquire an IP address and negotiate the QoS.
Later on, when UE feels the need of UL resources, it sends an UL capacity request to
the RNC. RNC performs the channel type selection and decides one of the options listed
above. Up to this point in signalling, a 3G R99 UE and HSUPA UE behave almost the
same.
In case, RNC chooses to use E-DCH in UL, the use of HS-DSCH becomes mandatary.
If HS-DSCH resources are also available, RNC sends the information regarding the cell
specific HSDPA and HSUPA details to user in a L3 RRC message Radio Bearer Recon-
figuration.
Figure 8.4: Signalling to initiate an HSUPA session
8.7 HSUPA Protocol Architecture

Source: 3GPP TS 25.321; Medium Access Control (MAC) Protocol Specifi-
cation
Earlier in section 8.3, the user plane protocol architecture of HSUPA & data-flow was
described but the details about MAC-e and MAC-es were not discussed. In the same sec-
tion, figure 8.1 described the overall functionality of HSUPA using the user plane protocol
stack. In the following section, we will investigate the MAC layer of HSUPA in depth.
On UTRAN side, for each UE that uses E-DCH, one MAC-e entity per Node-B and one
MAC-es entity in the SRNC are configured. Whereas on UE side, both MAC-e & MAC-es
are configured in the user equipment.
MAC-e/es entity - UE Side

Figure 8.5 is copied from ‘Figure 4.2.3.4.1a: UE side MAC architecture / MAC-e/es details
(FDD)’ of 3GPP TS 25.321. The MAC-es/e handles the E-DCH specific functions. The
split between MAC-e and MAC-es in the UE is not detailed. In the model below, the
8.7. HSUPA PROTOCOL ARCHITECTURE 255
Figure 8.5: UE side MAC-e/es details (25.321)
MAC-e/es comprises the following entities:
1. H-ARQ: The HARQ entity is responsible for handling the MAC functions relat-
ing to the HARQ protocol. It is responsible for storing MAC-e payloads and
re-transmitting them. The detailed configuration of the hybrid ARQ protocol is
provided by RRC over the MAC-Control SAP. The HARQ entity provides the E-
TFC, the retransmission sequence number (RSN), and the power offset to be used
by L1. Redundancy version (RV) of the HARQ transmission is derived by L1 from
RSN, CFN and in case of 2 ms TTI from the sub-frame number. RRC signalling
can also configure the HARQ entity to use RV=0 for every transmission.
2. Multiplexing and TSN setting: Figure 8.6 illustrates multiplexing of multiple MAC-
d PDUs into MAC-es PDU. After this, MAC-e layer further multiplexes several
MAC-es PDUs into MAC-e PDUs, as shown by figure 8.7. PDU sizes directly affect
the user bit rate. Therefore, these decisions are done by E-TFC selection function.
UE also sets the TSN while concatenating multiple MAC-d PDUs into MAC-es
PDUs.
3. E-TFC selection: This entity is responsible for E-TFC selection according to the
scheduling information, Relative Grants and Absolute Grants, received from UTRAN
via L1 and Serving Grant value signalled through RRC, and for arbitration among
the different flows mapped on the E-DCH. The detailed configuration of the E-
TFC entity is provided by RRC over the MAC-Control SAP. The E-TFC selection
function controls the multiplexing function.
Figure 8.6: MAC-es PDU
Figure 8.7: MAC-e PDU
As shown in figure 8.1, MAC-es sits on top of MAC-e and receives PDUs directly from
MAC-d. Figure 8.6 illustrates that MAC-es SDUs (i.e. MAC-d PDUs) of the same size,
coming from a particular logical channel are multiplexed together into a single MAC-es
payload. There is one and only one MAC-es PDU per logical channel per TTI (since only
one MAC-d PDU size is allowed per logical channel per TTI). To this payload is prepended
the MAC-es header.
The number of PDUs, as well as the one DDI value identifying the logical channel,
the MAC-d flow and the MAC-es SDU size are included as part of the MAC-e
header. In case sufficient space is left in the E-DCH transport block or if Scheduling
Information needs to be transmitted, an SI will be included at the end of the MAC-e
PDU. Multiple MAC-es PDUs from multiple logical channels, but only one MAC-e PDU
can be transmitted in a TTI.
In the example shown in figure 8.7, the field DDI0 is referring to the specific DDI value
that indicates that there is an SI included in the MAC-e PDU. This header will not be
associated with a new MAC-es payload.
MAC-es entity - UTRAN Side
Figure 8.8: UTRAN side MAC-es details(25.321)
For each UE, there is one MAC-es entity in the SRNC. The MAC-es sublayer handles
E-DCH specific functionality,which is not covered in the MAC-e entity in Node B. The
MAC-es comprises the following entities:
1. Reordering Queue Distribution: The reordering queue distribution function routes

the MAC-es PDUs to the correct reordering buffer based on the SRNC configuration.
2. Reordering: This function reorders received MAC-es PDUs according to the received
TSN and Node B tagging i.e. (CFN, subframe number). MAC-es PDUs with consec-
utive TSNs are delivered to the disassembly function upon reception. Mechanisms
for reordering MAC-es PDUs are left to the implementation. The number of re-
ordering entities is controlled by the SRNC. There is one Reordering Queue per
logical channel.
3. Macro diversity selection: The function is performed in the MAC-es, in case of soft
handover with multiple Node Bs (The soft combining for all the cells of a Node B
takes place in the Node B). This means that the reordering function receives MAC-es
PDUs from each Node B in the E-DCH active set. The exact implementation is not
specified. However, the model below is based on one Reordering Queue Distribution
entity receiving all the MAC-d flow from all the Node Bs, and one MAC-es entity
per UE.
4. Disassembly: The disassembly function is responsible for disassembly of MAC-es

PDUs. When a MAC-es PDU is disassembled the MAC-es header is removed, the
MAC-d PDU’s are extracted and delivered to MAC-d.
MAC-e entity - UTRAN Side

There is one MAC-e entity in the Node B for each UE and one E-DCH scheduler function
in the Node B. The MAC-e and E-DCH scheduler handle HSUPA specific functions in the
Node B. In HSUPA, the MAC-e and E-DCH scheduler comprises the following entities:
1. E-DCH Scheduling: This function manages E-DCH cell resources between UEs.
Based on scheduling requests, Scheduling Grants are determined and transmitted.
The general principles of the E-DCH scheduling are described by 3GPP but the
actual implementation is not specified (i.e. depends on RRM strategy).
2. E-DCH Control: The E-DCH control entity is responsible for reception of scheduling
requests and transmission of Scheduling Grants.
3. De-multiplexing: This function provides de-multiplexing of MAC-e PDUs. MAC-es

PDUs are forwarded to the associated MAC-d flow.
4. HARQ: One HARQ entity is capable of supporting multiple instances (HARQ pro-
cesses) of stop and wait HARQ protocols. Each process is responsible for generating
ACKs or NACKs indicating delivery status of E-DCH transmissions. The HARQ
entity handles all tasks that are required for the HARQ protocol.
Figure 8.9: UTRAN side MAC-e details(25.321)
8.8 Channels and Physical Layer

In the previous section, we learnt about the L2 MAC sub-layer functionality for HSUPA
operation. Now we will take a closer look at L1 Physical layer and learn about the HSUPA
physical channels. All the channels related to HSUPA operation have a name which start
with ‘E-’.
One by one, we will discuss the following physical channels:
1. E-DPDCH
2. E-DPCCH
3. E-RGCH
4. E-HICH
5. E-AGCH
8.8.1 E-DPDCH
Figure 8.10: Subframe Structure of E-DPDCH and E-DPCCH Channels
The E-DPDCH is the principal channel which is used to carry the E-DCH transport
channel. There may be zero, one, 2 or 4 E-DPDCH on each radio link. The E-DPCCH
is a physical channel used to transmit control information associated with the E-DCH.
There is at most one E-DPCCH on each radio link.
Figure 8.10 shows the E-DPDCH and E-DPCCH (sub)frame structure. Each radio frame
is divided in 5 subframes, each of length 2 ms; the first subframe starts at the start of
each radio frame and the 5th subframe ends at the end of each radio frame.
Just like Rel. 99 DPDCH channel, REL-6 E-DPDCH channel can also have variable
spreading factor. E-DPDCH support 8 different SF as shown in table 8.4 by row number
1 to 8. Various slot formats actually represent a combination of ‘SF and Modulation’.
An E-DPDCH may use BPSK (all UE categories) or 4PAM modulation symbols (Category
7 and 9 only). Table 8.1, 8.2 & 8.3 show various UE categories and their physical layer
capabilities.
In the basic form of HSUPA (3GPP release 6), there are 6 UE categories defined. As an
example, we try to calculate the peak L1 bitrate of category 6.
Slot format #i Channel Bit Channel Symbol SF Bits/ E-DPDCH

Rate (kbps) Rate (ksps) subframe
0 (BPSK) 15 15 256 30
1 (BPSK) 30 30 128 60
2 (BPSK) 60 60 64 120
3 (BPSK) 120 120 32 240
4 (BPSK) 240 240 16 480
5 (BPSK) 480 480 8 960
6 (BPSK) 960 960 4 1920
7 (BPSK) 1920 1920 2 3840
8 (4PAM) 1920 960 4 3840
9 (4PAM) 3840 1920 2 7680
Table 8.4: E-DPDCH slot formats (from TS 25.211)
E-DPDCH Code # 1 : SF4 = 960 ksps

+ E-DPDCH Code # 2 : SF4 = 960 ksps
= Sum of all 4 E-DPDCH Codes = 5760 ksps
or Cat. 6 UE supports only BPSK Modulation ⇒ 5760 kbps
Hence, by sending Uplink data on 4 channelization codes ( 2 × SF2 + 2 × SF4 ), UE is able

to achieve a L1 bit rate of 5.76 Mbps. The knowledge of channel coding rate is needed to
find out the L2 user bit rate. Same calculation can be done for UE of category 7, which
supports both BPSK and 4PAM modulation. 4PAM modulation uses 2 bits to generate
one modulation symbol. For 4-PAM case, 5760 ksps = 11200 kbps or 11.2 Mbps.
8.8.2 E-DPCCH
The E-DPCCH is a physical channel carrying control information for the E-DPDCH. The
E-DPCCH is sent with a power offset relative to the DPCCH. The power offset is signalled
by RRC. E-DPCCH has a fixed spreading factor 256 which allows UE to send 15 kbps
control signalling. In a 2 ms subframe, UE can send maximum 30 bits on E-DPCCH. Out
of these 30 bits, only 10 carry useful information and the remaining 20 bits are used for
the reliability or channel coding. The details can be found in 3GPP TS 25.212.
For both 2 ms and 10 ms TTI, the information carried on the E-DPCCH consists of 10
bits in total.
E-TFCI, 7 bits: An E-DCH Transport Format Combination Indicator (E-TFCI) iden-

tifies the transport block size on E-DCH (7 bits). SRNC signals which E-DCH
Transport Block Size table should be used by the UE5 .
RSN, 2 bits: The Retransmission Sequence Number (RSN) is used to convey the uplink
HARQ transmission number. The combination of the RSN and the transmission
timing allows the receiver to determine the exact transmission number. The length
of the RSN field is 2 bits. 2 bits of RSN are interpreted as:
• ‘00’ ⇒ Original Transmission

• ‘01’ ⇒ First Re-transmission
• ‘10’ ⇒ Second Re-transmission
• ‘11’ ⇒ Third or higher retransmission
Happy Bit, 1 bit: One bit of the E-DPCCH is used to indicate whether or not the UE
is satisfied (‘happy’) with the current Serving Grant. This bit is always be present
during uplink transmission of E-DPCCH. According to section 11.8.1.5 of 25.321,
UE indicates that it is ‘unhappy’ if the following criteria are met:
1. UE is transmitting as much scheduled data as allowed by the current Serving

Grant;
2. UE has enough power available to transmit at higher data rate;
3. Total buffer status would require more than Happy Bit Delay Condition
ms to be transmitted with the current Serving Grant.
‘Happy Bit Delay Condition’ is an operator configurable parameter.
5
3GPP TS 25.321, annexure B shows all the tables for E-DCH FDD mode.
• If the UE is configured with E-TFCI table 0 and 2ms TTI, use Annex B.1
• If the UE is configured with E-TFCI table 2 and 2ms TTI, use Annex B.2a
• If the UE is configured with E-TFCI table 3 and 2ms TTI, use Annex B.2b
Slot format #i Channel Bit Channel Symbol SF Bits/ E-DPDCH

Rate (kbps) Rate (ksps) subframe
0 (BPSK ) 15 15 256 30
Table 8.5: E-DPCCH slot formats (from TS 25.211)
8.8.3 E-AGCH
The E-DCH Absolute Grant Channel (E-AGCH) is a downlink physical channel with fixed
spreading factor (SF=256). In other words, the E-AGCH has a bit rate 30 kbps. In a
subframe of 2 ms, Node B can send 60 bits. E-AGCH transmission is:
• Over one sub-frame if E-DCH TTI is set to 2ms.
• Over one frame if E-DCH TTI is set to 10ms.
The sequence of 60 bits are mapped to the corresponding E-AGCH sub-frame. If the E-
DCH TTI is equal to 10 ms, the same sequence of bits is transmitted in all the E-AGCH
sub-frames of the E-AGCH radio frame. In other words, the same 2 ms sub-frame of
E-AGCH is re-transmitted four times (sent total 5 times).
E-AGCH channel is used to carry the uplink E-DCH Absolute Grant. Figure 8.11 illus-
trates the frame and sub-frame structure of the E-AGCH.
Figure 8.11: Subframe Structure of E-AGCH
The absolute grant channel carries six bits which are concatenated with 16 bit CRC. The
user identity E-RNTI is masked on the CRC. After channel coding, E-AGCH becomes 90
bits long. A Rate Matching procedure is used to select selected 60 bits and those bits are
transmitted in E-AGCH sub-frame. The six data bits of E-AGCH channel are:
Index Absolute Grant Value

31 (168/15)2 ∗ 6
30 (150/15)2 ∗ 6
29 (168/15)2 ∗ 4
28 (150/15)2 ∗ 4
27 (134/15)2 ∗ 4
26 (119/15)2 ∗ 4
25 (150/15)2 ∗ 2
24 (95/15)2 ∗ 4
23 (168/15)2
22 (150/15)2
21 (134/15)2
20 (119/15)2
19 (106/15)2
.. ..
. .
11 (42/15)2
10 (38/15)2
9 (34/15)2
8 (30/15)2
7 (27/15)2
6 (24/15)2
5 (19/15)2
4 (15/15)2
3 (11/15)2
2 (7/15)2
1 ZERO GRANT
0 INACTIVE
Table 8.6: Mapping of Absolute Grant Value (from 3GPP TS 25.321)
Absolute Grant Value, 5 bits: This field indicates the maximum E-DCH traffic to pi-
lot ratio (E-DPDCH/DPCCH) that the UE is allowed to use in the next transmis-
sion. The length of the Absolute Grant Value field is 5 bits.
Ptx,E-DPDCH
Absolute Grant =
Ptx,DPCCH
Absolute Grant Scope, 1 bit: This field indicates the applicability of the Absolute
Grant. It can take two different values, “Per HARQ process” or “All HARQ pro-
cesses”, allowing to indicate whether the HARQ process activation/de-activation
will affect one or all processes. The Absolute Grant Scope is encoded in 1 bit.
When the E-DCH is configured with 10ms TTI, only the value “All HARQ pro-
cesses” is valid. In case, Identity Type is ‘Secondary’, only the value “All HARQ
processes” is valid.
8.8.4 E-RGCH
The E-DCH Relative Grant Channel (E-RGCH) is a downlink physical channel with fixed
spreading factor (SF=128). Hence, this channel can carry information at 60 kbps. E-
RGCH carries dedicated uplink E-DCH relative grants. The word ‘Relative’ means, in
comparison to the current grant used by UE. Figure 8.15 illustrates the structure of the
E-RGCH. A relative grant can have one of the following three values.
• UP
• DOWN
• HOLD
E-RGCH channel can be transmitted either in 3, 12 or 15 consecutive slots and in each

slot a sequence of 40 ternary values is transmitted (Up, Down or Hold).
E-RGCH transmission on 3 slots: Used on an E-RGCH transmitted to UEs for which

the cell transmitting the E-RGCH is in the E-DCH serving radio link set
and for which the E-DCH TTI is 2 ms.

the cell transmitting the E-RGCH is in the E-DCH serving radio link set
and for which the E-DCH TTI is 10 ms.

the cell transmitting the E-RGCH is not in the E-DCH serving radio link set.
For non-serving E-DCH RLS, the duration of E-RGCH transmission is irrespective
of the E-DCH TTI.
The next section has been written with the help of 3GPP TS 25.321 as reference material.
For the following discussion, it is assumed that UE’s E-DCH active set is more than one.
Hence, UE is in soft handover for E-DCH with two or more cells.
Serving Relative Grant: Transmitted in downlink on the E-RGCH from all cells in
the serving E-DCH RLS, the serving relative grant allows the Node B scheduler
to incrementally adjust the serving grant of UEs under its control. By definition,
there can only be one serving relative grant command received at any time. This
indication can take three different values, ‘UP’, ‘DOWN’ or ‘HOLD’.
Non-serving Relative Grant: Transmitted in downlink on the E-RGCH from a non-

serving E-DCH RL, the non-serving relative grant allows neighboring Node Bs to
adjust the transmitted rate of UEs that are not under their control in order to avoid
overload situations. By definition, there could be multiple non-serving relative grant
commands received by MAC at any time. This indication can take two different
values, ‘DOWN’ or ‘HOLD’.
Figure 8.12: Subframe Structure of E-RGCH & E-HICH
The sequence bi,0 , bi,1 . . . , bi,39 is calculated as
[bi,0 , bi,1 . . . , bi,39 ] = a ∗ [40 bit long Signature Sequence], where:

 +1 if Relative Grant is ‘UP’,
a= 0 if Relative Grant is ‘HOLD’,

−1 if Relative Grant is ‘DOWN’.
The orthogonal signature sequences are defined by 3GPP TS 25.21. Figure 8.14 shows
a table with all of these 40 signature sequences which are numbered from CSS,40,0 to
CSS,40,39 . Each HSUPA user is assigned one signature sequence for E-HICH and another
sequence for E-RGCH. Hence, every user requires at least two signature sequences. This
is a nice trick which consumes only one channelization code for E-RGCH and E-HICH for
up to 20 HSUPA users. The principle of creating 40 dedicated channels using only one
channelization code is illustrated in figure 8.13.
In figure 8.13, UE1 has been assigned a signature sequence # 0 for E-RGCH and # 1 for
E-HICH. Similarly the other users are also assigned 2 signature sequences per UE.
If there are more than 20 HSUPA users in a cell, then additional channelization codes
must be allocated for additional E-RGCH and E-HICH channels.
Figure 8.13: Signature Multiplexing Scheme for E-RGCH and E-HICH
Which Grant to be Respected: AGCH or RGCH?
According to 3GPP TS 25.321, UEs configured with an E-DCH transport channel shall
maintain a Serving Grant and the list of active HARQ processes based on the absolute
and relative grant commands decoded on the configured E-AGCH and E-RGCH(s). The
UE will only act on a relative grant command if all of the following are true:
• The current serving grant is not set to ZERO GRANT.

• The UE has not received a new absolute grant within 1 HARQ Round Trip Time
(40 ms for 10 ms TTI, 16 ms for 2 ms TTI).
• The UE was expecting to receive an ack/nack on the E-HICH at the same time
as the network sent the E-RGCH command (an ack/nack sent for a E-DPDCH
transmission that just contained MAC-e Scheduling Information alone does not meet
this criteria).
Now the question is:

“If Serving Relative Grant is UP, how much should the SG be increased?
Similarly, if serving Relative Grant is down, how much should the SG be
decreased?”
According to TS 25.321, the answer to this question can be found by using two param-
eters: “3-index-step threshold” and “2-index-step threshold” that are configured
by higher layers.
Figure 8.14: E-RGCH and E-HICH signature sequences (from TS 25.211)
If the UE received a Serving Relative Grant ‘UP’: UE determine the Serving Grant
as follows:
• if SG < “3-index-step threshold”: Serving Grant (SG) = [MIN(SG + 3, 37)].

• if “3-index-step threshold” <= SG < “2-index-step threshold”: Serving Grant
(SG) = [MIN(SG + 2, 37)].
• if SG <= “2-index-step threshold”: Serving Grant (SG) = [MIN(SG + 1, 37)].
If the UE received a Serving Relative Grant ‘DOWN’: UE determine the Serv-

ing Grant as follows:
• Serving Grant (SG) = [MAX(SG -1, 0)]

Index Scheduled Grant

37 (168/15)2 ∗ 6
36 (150/15)2 ∗ 6
35 (168/15)2 ∗ 4
34 (150/15)2 ∗ 4
33 (134/15)2 ∗ 4
32 (119/15)2 ∗ 4
31 (150/15)2 ∗ 2
30 (95/15)2 ∗ 4
29 (168/15)2
28 (150/15)2
27 (134/15)2
26 (119/15)2
25 (106/15)2
.. ..
. .
11 (21/15)2
10 (19/15)2
9 (17/15)2
8 (15/15)2
7 (13/15)2
6 (12/15)2
5 (11/15)2
4 (9/15)2
3 (8/15)2
2 (7/15)2
1 (6/15)2
0 (5/15)2
Table 8.7: Scheduling Grant Table (from 3GPP TS 25.321)
8.8.5 E-HICH
The E-DCH Hybrid ARQ Indicator Channel (E-HICH) is a fixed rate (SF=128) dedicated
downlink physical channel carrying the uplink E-DCH hybrid ARQ acknowledgement in-
dicator. Figure 8.15 illustrates the structure of the E-HICH. A hybrid-ARQ acknowledge-
ment indicator is transmitted using 3 or 12 consecutive slots and in each slot, a sequence
of 40 binary values is transmitted. The 3 and 12 slot duration shall be used for UEs whose
E-DCH TTI is set to 2 ms and 10 ms respectively.
3GPP TS 25.212 shows the mapping for E-HICH ACK/NACK. The same concept is briefly
Figure 8.15: Subframe Structure of E-RGCH & E-HICH
mentioned below.
In a radio link set containing the serving E-DCH radio link set, the hybrid-ARQ
acknowledgement indicator ‘a’ is set to:
• ‘+1’: If Node B wants to send a positive Acknowledgement

• ‘-1’: If Node B wants to send a negative Acknowledgement
In a radio link set not containing the serving E-DCH radio link set, the hybrid
ARQ acknowledgement indicator ‘a’ is set to:
• ‘+1’: If Node B wants to send a positive Acknowledgement

• ‘0’ or ‘DTX’: If Node B wants to send a Negative Acknowledgement
The sequence bi,0 , bi,1 . . . , bi,39 is calculated as

[bi,0 , bi,1 . . . , bi,39 ] = a ∗ [40 bit long Signature Sequence], where :

 +1 if H-ARQ Indication is “ACK”,
a= 0 if H-ARQ Indication is “NACK” & Cell is not in serving E-DCH radio link set]

−1 if H-ARQ Indication is “NACK” & Cell is in in serving E-DCH radio link set.
8.8.6 F-DPCH
Although F-DPCH was described in HSDPA chapter, but it is not allowed
to use F-DPCH until the uplink is on E-DCH. HSDPA without HSUPA
configuration cannot use F-DPCH for the users.
The F-DPCH carries control information generated at layer 1 (TPC commands). It is a

special case of downlink DPCCH. Figure 8.16 shows the frame structure of the F-DPCH.
Each frame of length 10 ms is split into 15 slots, each of length Tslot = 2560 chips,
corresponding to one power-control period.
Figure 8.16: Frame Structure of F-DPCH
The exact number of bits of the OFF periods and of the F-DPCH fields (NTPC ) is described
in table 8.8. Each slot format corresponds to a different set of OFF periods within the
F-DPCH slot.
Slot format #i SF Bits/Slot NOFF1 NTPC NOFF2

Bits/slot Bits/slot Bits/slot
0 256 20 2 2 16
1 256 20 4 2 14
2 256 20 6 2 12
3 256 20 8 2 10
4 256 20 10 2 8
5 256 20 12 2 6
6 256 20 14 2 4
7 256 20 16 2 2
8 256 20 18 2 0
9 256 20 0 2 18
Table 8.8: F-DPCH Fields

8.9. SUMMARY: SERVING AND NON-SERVING RLS 273
8.9 Summary: Serving and Non-serving RLS

When I started learning HSUPA, it was fun to learn about the L1 and L2
modifications. But I want to honestly admit that I had a very hard time in
getting comfortable with the words ‘Serving E-DCH Radio Link Set’ and ‘Non-
serving E-DCH Radio Link Set’. Therefore, in this section, I have tried to
summarize those concepts which will help the readers to clear some doubts.
For more information, please refer to TS 25.319 and TS 25.321.
When a UE has an active HSUPA session, it is mandatory to have HSDPA configured

in downlink. HS-DSCH channel undergoes Hard serving cell change, whereas E-DCH
channel undergoes normal soft handover. Therefore, we need to define a few new terms
which will help us in understanding HSUPA operation. In our discussion, we will take the
help of figure 8.17. In this figure, there are 3 cells which are named as ‘A’, ‘B’ & ’C’. The
UE shown in this figure happens to receive DL HS-DSCH from cell ‘A’ only but its uplink
E-DCH is in soft handover with all the three cells shown in this figure.
Let us try to find out the answers to following questions:
1. Which cell is E-DCH Serving Cell?

2. Which cell(s) form the E-DCH Active Set?
3. Which cell(s) belong to Serving E-DCH RLS?
4. Which cell(s) belong to Non-serving E-DCH RLS?
Serving E-DCH Cell: Serving E-DCH cell is the same cell as serving HS-DSCH cell.
HS-DSCH channel cannot be in soft handover. Because HS-DSCH has only one
cell delivering DL data, there is no confusion in deciding which cell is our E-DCH
serving cell.
In other words, E-DCH serving cell is the cell from which the UE receives Absolute
Grants. A UE has only one Serving E-DCH cell. In figure 8.17, cell ‘A’ is our seving
E-DCH cell.
E-DCH Active Set Cells: This is a set of cells with which a UE has active E-DCH
connection. In figure 8.17, cell ‘A’, ‘B’ & ’C’ are our E-DCH active set cells.
Serving RLS Cells: It was stated earlier,“for each UE that uses E-DCH, we have one
MAC-e entity per Node-B”. If cell ‘A’ is our Serving E-DCH cell, then the ‘main’
MAC-e entity will be in the Node B which controls cell ‘A’. If the same Node B
also controls cell ‘B’, then the E-RGCH and E-HICH in these two cells will carry
the same information. There will be an ‘additional’ MAC-e entity at the Node
B which controls cell ‘C’. This additional MAC-e entity does not have authority to
send E-AGCH or to send an ‘UP’ command on E-RGCH. The information sent on
E-RGCH and E-HICH from these two MAC-e entities can be different or the same.
Figure 8.17: E-DCH Cell Status: Serving RLS and Non-serving RLS
Hence, the cells that belong to that Node B which controls the Serving E-DCH
cell, form Serving E-DCH RLS. The UE has only one Serving E-DCH RLS. In our
example of figure 8.17, cell ‘A’ & ‘B’ belong to Serving E-DCH RLS. The content
of E-RGCH and E-HICH in these cells can have the following values:
On E-RGCH UP, DOWN or HOLD

On E-HICH +1 for ACK and -1 for NACK
Non-serving RL: Cell which belongs to the E-DCH active set but does not belong to
the Serving E-DCH RLS and from which the UE can receive one Relative Grant.
The UE can have zero, one or several non-serving E-DCH RL(s). In figure 8.17, cell
‘C’ is in non-serving E-DCH RLS.
On E-RGCH DOWN or HOLD

On E-HICH +1 for ACK and ’DTX’ for NACK
8.9. SUMMARY: SERVING AND NON-SERVING RLS 275
The following are the main takeaways from this section:
Once again, please have a look at figure 8.17 and observe the E-AGCH, E-
RGCH & E-HICH behaviour.
• E-AGCH comes only from Serving E-DCH Cell.

• E-RGCH comes from all the Active Set Cells, but:
– If Cell belongs to Serving E-DCH RLS, E-RGCH can have 3 values:
UP, DOWN & HOLD.
– If Cell belongs to Non-Serving E-DCH RLS, E-RGCH can have 2
values: DOWN & HOLD.
• E-HICH also comes from all the Active Set Cells. But:
– If Cell belongs to Serving E-DCH RLS, E-HICH can have 2 values:
ACK (+1) & NACK (-1).
– If Cell belongs to Non-Serving E-DCH RLS, E-RGCH can have 2
values: ACK (+1) & NACK (0).
8.10 E-TFC Selection Procedure

As we have learnt in the discussion so far, Node B only sends a grant value to UE and it
is UE’s duty to select the transport block size, transport format combination and other
L1 parameters such as spreading factor, number of codes, coding rate, etc.
This whole procedure is explained in a chronological order in the next few pages. The
starting of HSUPA operation was explained in section 8.6. In short, when RNC decides
to allocate E-DCH transport channel to the UE in uplink, an ‘initial serving grant’ is
assigned to it. This grant is generated by Node B but UE receives it from RNC using RRC
signalling. Once, HSUPA operation begins, UE and Node B can perform L1 signalling
without bothering RNC for each message transfer.
In HSUPA, UE and Node B are in constant touch and maintain a ‘REQUEST-GRANT’
mechanism. Let us begin by analyzing how UE requests uplink resources from Node B
and follow the steps after that. This description is broken down into 10 steps.
8.10.1 Step 1: UE sends Scheduling Requests to Node B

In order to start the whole HSUPA operation, UE has to send some feedback or request
towards Node B to indicate its desire to send uplink data and therefore, its wish to get
scheduled. This can be done via two methods: Happy Bit and Scheduling Info.
Figure 8.18: Scheduling Information format
1. Happy Bit, 1 bit: As explained in the section 8.8.2, Happy bit is a single bit infor-
mation sent on E-DPCCH which indicates whether the UE demands an upgrade in
the resource allocation or not.
2. Scheduling Info, 18 bits: The Scheduling Information is located at the end of the
MAC-e PDU and is used to provide the serving Node B with a better & more
detailed view of the amount of system resources needed by the UE and the amount
of resources it can actually make use of. The transmission of this information will be
initiated due to the quantization of the transport block sizes that can be supported.
Figure 8.18 is copied from 3GPP TS 25.321 which shows the information fields
included in Scheduling Information. These fields are briefly explained below:
• Highest priority Logical channel ID (HLID): The HLID field identifies unam-
biguously the highest priority logical channel with available data. If multiple
8.10. E-TFC SELECTION PROCEDURE 277
logical channels exist with the highest priority, the one corresponding to the
highest buffer occupancy will be reported. The length of the HLID is 4 bits.
In case the TEBS is indicating index 0 (0 byte), the HLID shall indicate the
value “0000”.
• Total E-DCH Buffer Status (TEBS): The TEBS field identifies the total amount
of data available across all logical channels for which reporting has been re-
quested by the RRC and indicates the amount of data in number of bytes
that is available for transmission and retransmission in the RLC layer. When
MAC is connected to an AM RLC entity, control PDUs to be transmitted and
RLC PDUs outside the RLC Tx window shall also be included in the TEBS.
RLC PDUs that have been transmitted but not negatively acknowledged by
the peer entity shall not be included in the TEBS. TEBS index is signalled to
the Node B which can be from 0 to 31. 0 indicated TEBS = 0 and 31 indicated
TEBS > 37642 Bytes.
• Highest priority Logical channel Buffer Status (HLBS): The HLBS field in-
dicates the amount of data available from the logical channel identified by
HLID, relative to the highest value of the buffer size range reported by TEBS
when the reported TEBS index is not 31, and relative to 50000 bytes when the
reported TEBS index is 31. The length of HLBS is 4 bits.
• UE Power Headroom (UPH): The UPH field indicates the ratio of the maxi-
mum UE transmission power and the corresponding DPCCH code power. The
length of UPH is 5 bits.
8.10.2 Step 2: Serving Grant Value

The UE must be able to receive Absolute Grants from the Serving E-DCH cell and Relative
Grants from the Serving E-DCH RLS. The UE shall handle the Grant from the Serving
E-DCH RLS and determine a Serving Grant.
Many times in this chapter, we have discussed grants. Let us summarize the concepts
about grant. We have seen three types of grants.
1. Absolute Grant: Absolute Grant is the value which is signalled to the user on the
E-AGCH channel. AG Value can be from 0 to 316 .
2. Relative Grant: Relative Grant can be either UP, DOWN or HOLD. This grant
is signalled to UE using E-RGCH channel. The word Relative in RGCH means
Relative to the current Serving Grant.
3. Serving Grant: The E-TFC selection function of MAC-e/es entity of UE is respon-

sible to find out the Serving Grant value from:
6
Absolute Grant Value: INACTIVE (Index 0), ZERO GRANT (Index 1), & Index 2 , 3, . . . 31.
• Relative Grants and Absolute Grants, received from UTRAN via L1.
• Serving Grant value signalled through RRC.
UE maintains a Serving grant value which can be from 0 to 37. Serving Grant7 values
were described in table 8.7.
8.10.3 Step 3: Find Power Offset

After calculating the Serving Grant (SG), UE reads the actual E-DPDCH to DPCCH
power offset from the Serving Grant table as shown in table 8.7. This is a straightforward
mechanism of reading look-up table. Therefore, it requires no further explanation.
8.10.4 Step 4: “Reference E-TFCI & Power Offset” Curve

At the time of HSUPA session setup, there is a lot of information exchanged from SRNC
to UE. In figure 8.19, this section of signalling is illustrated with the emphasis on the
information elements which are crucial for HSUPA operation. The detailed information
about each information of this RRC message is available in 3GPP TS 25.331. Among
other parameters, RNC indicates up to 8 pairs of ‘Reference E-TFCI’ and ‘Reference E-
TFCI-PO’ values. In figure 8.19, these values are highlighted by drawing an oval shape
around them. Using these set of paired-values, UE can plot a 2-dimensional curve, which
looks like the one shown in figure 8.20.
8.10.5 Step 5: Calculate E-TFCI Allowed by Grant Value

In step 3, UE calculated the power offset allowed by the serving grant. Now it has to map
the power offset on the x-axis of the curve made in step 4 and calculate the E-TFCI index
from the y-axis.
The numbers shown in figure 8.21 are just for explaining the principle. Their actual value
should not be considered for quantitative analysis. For the exact numbers, it is suggested
to refer to TS 25.211, TS 25.212 and TS 25.331.
8.10.6 Step 6: Calculate TB Size

In the RRC signalling shown in figure 8.19, SRNC informs the user about the TB Size
Table to be used while E-TFC selection procedure. All the tables are defined in the
annexure of 3GPP TS 25.321. Just for the illustration purpose, a section of Table B.3
from TS 25.321 is shown in Table 8.9. In 3GPP specifications, this table is known as Table
‘0 for 10 ms TTI case’.
7 2 2
Serving Grant Value: (5/15) (Index 0), (6/15) (Index 1), . . . , Index 37
Figure 8.19: RB Reconfiguration Message with emphasis on E-DCH info.
This step is also quite straight forward. Because once the E-TFCI index is known (from
step 5), in step 6, UE simply needs to look up the corresponding TB size in the relevant
TB size table.
8.10.7 Step 7: Select Channelization Code & L1 Parameters

This step is performed by UE based on some standard algorithms defined by 3GPP. In
Step 7, UE will determine following items.
• SF,
Figure 8.20: ”Reference E-TFCI & Power Offset” Curve
• Modulation scheme (from R7 onwards),
• and number of physical channels needed.
This step will not be explained in detail in this book. If you are interested in the details
of this procedure, please refer to ‘section 4.8.4.1 of 3GPP TS 25.212’.
8.10.8 Step 8: UL Transmission on E-DCH

Let’s assume the ‘number of physical channels needed’ = 4 from the calculation performed
in Step 7. It implies that there will be 4 E-DPDCH physical channels along with one
E-DPCCH. The scenario of uplink transmission will look like the one depicted in figure
8.22.
E-DPDCH: E-DPDCH is mainly designed for carrying user data but additionally we
can send SRB on this channel. In addition to that, periodically UE can send 18 bit
scheduling information. At the time when SI transmission is scheduled, then SI bits
will be attached to the MAC-e PDU, as shown in figure 8.7.
Figure 8.21: Calculating the E-TFCI from Power Offset
Figure 8.22: HSUPA transmission from UE
E-DPCCH: E-DPCCH is used to carry L1 control information related to HSUPA data

on E-DPDCH. One such information is the famous ‘Happy Bit’.
8.10.9 Step 9: Feedback from Node B on E-HICH

Node B checks whether the received MAC-e PDU has been received with acceptable qual-
ity. If yes, then Node B sends positive ACK to the UE using E-HICH channel and sends
E-TFCI TB Size(bits) E-TFCI TB Size(bits) E-TFCI TB Size(bits)

0 18 43 660 85 3634
1 120 44 687 86 3784
2 124 45 716 87 3941
3 130 46 745 88 4105
4 135 47 776 89 4275
5 141 48 809 90 4452
6 147 49 842 91 4636
7 153 50 877 92 4828
... ... ... ... ... ...
38 539 80 2966 123 17001
39 561 81 3089 124 17706
40 584 82 3217 125 18440
41 608 83 3350 126 19204
42 634 84 3489 127 20000
Taken from Annex B.3 of 3GPP TS 25.321
E-DCH Transport Block Size Table 0 for 10ms TTI
Table 8.9: E-DCH TB Size Selection Table (example)
the Data block in a E-DCH Frame Protocol frame. If not, then Node B sends negative
acknowledgement to the UE using E-HICH channel.
8.10.10 Step 10: Feedback from Node B on E-RGCH

The scheduler at Node B takes various factors into account and decides whether an UP,
DOWN or HOLD command should sent to the user. Some of these factors are received
Happy Bit’s value, scheduling info (SI), current UL interference in the cell etc.
8.11. SUMMARY: HSUPA OPERATION IN SHORT 283
8.11 Summary: HSUPA Operation in Short
Figure 8.23: HSUPA operation explained using the physical channels.
Channel Direction Function SF Modulation

E-DPDCH ↑ Carries UL user data 256 to 2 BPSK & 4PAM
E-DPCCH ↑ Carries L1 Signalling 256 BPSK
E-RGCH ↓ Grant (Up, Down, Hold) 128 QPSK
E-HICH ↓ ACK or NACK 128 QPSK
E-AGCH ↓ Grant (Absolute value) 256 QPSK
Table 8.10: Summary of HSUPA channels

Copyright Notices

⃝2006.
c 3GPPTM TSs and TRs are the property of ARIB, ATIS, ETSI, CCSA, TTA, and
TTC who jointly own the copyright for them. They are subject to further modifications
and are therefore provided to you as is for information purposes only. Further use is
strictly prohibited.
8.11. SUMMARY: HSUPA OPERATION IN SHORT 285
Text in section 8.7 on page 254 Section 4.2.3.4 of 3GPP TS 25.321 v 7.7.0.
Figure 8.5 on page 255 Figure 4.2.3.4.1a of 3GPP TS 25.321 v 7.7.0.
Figure 8.8 on page 258 Figure 4.2.4.4-1 of 3GPP TS 25.321 v 7.7.0.
Text about Relative Grant on Section 9.2.5.2.1 of 3GPP TS 25.321 v 7.7.0.
page 266
Text about Interpretation of RG Section 9.2.5.2.1 of 3GPP TS 25.321 v 7.7.0.
value on page 268
Text about Absolute Grant on Section 9.2.5.2.2 of 3GPP TS 25.321 v 7.7.0.
page 264
Text about Scheduling Info on Section 9.2.5.3.2 of 3GPP TS 25.321 v 7.7.0.
page 276
Text about Happy Bit setting on Section 11.8.1.5 of 25.321 v 7.7.0.
page 263
Figure 8.9 on page 260 Figure 4.2.4.5-1a of 3GPP TS 25.321 v 7.7.0.
Figure 8.6 on page 256 Figure 9.1.5.1 of 3GPP TS 25.321 v 7.7.0.
Figure 8.7 on page 256 Figure 9.1.5.2a of 3GPP TS 25.321 v 7.7.0.
Table 8.7 on page 270 Table 9.2.5.2.1.1 of 3GPP TS 25.321 v 7.7.0.
Table 8.9 on page 282 Table B.3 in Annex B of 3GPP TS 25.321 v
7.7.0
⃝2008.
c TM

Table 8.8 on page 272 Table 16C of 3GPP TS 25.211 v 9.1.0.
Table 8.4 on page 262 Table 5B of 3GPP TS 25.211 v 9.1.0.
Table 8.5 on page 264 Table 5C of 3GPP 3GPP TS 25.211 v 9.1.0.
Figure 8.13 on page 268 Figure 16A of 3GPP TS 25.211 v 9.1.0
⃝2009.
c TM
Table 8.1 on page 252 Table 5.1g of 3GPP TS 25.306 v 9.1.0.

Table 8.6 on page 265 Table 16B of 3GPP TS 25.212 v 9.3.0.
⃝2010.
c TM
BIBLIOGRAPHY
[2] 3GPP TS 25.319 ver. 7.0.0 ;‘High Speed Uplink Packet Access (HSUPA); Overall
description’
[3] 3GPP TS 25.306 ver. 9.0.0 ;‘UE Radio Access capabilities’
& Sons.
287
APPENDIX 8.1
Source:
3GPP TS 25.211: “Physical channels and mapping of transport channels onto
physical channels (FDD)”.
3GPP TS 25.212: “Multiplexing and channel coding (FDD)”.
3GPP TS 25.213: “Spreading and modulation (FDD)”.
3GPP TS 25.214: “Physical layer procedures (FDD)”.
3GPP TS 25.215: “Physical layer - Measurements (FDD)”.
In this book, we have seen the physical channels of the three technologies: UMTS, HSDPA
& HSUPA. This appendix is written for advanced readers who might be interested in
knowing the exact channelization code that is used for a particular physical channel. For
some of the channels, there are fixed code allocations; for some channels, there are standard
rules to decide the code and for some channels, RNC allocates the code when the need
arises.
8.12 UL Channelization Codes

In total, there are five types of uplink physical channels. These are shown in figure 8.24.
The DPDCH, the DPCCH, the E-DPDCH, the E-DPCCH and the HS-DPCCH are I/Q
code-multiplexed, where I and Q denote real and imaginary parts, respectively. This figure
has been copied from 3GPP TS 25.213.
The coding takes place in 2 steps: channelization and scrambling.
288
8.12. UL CHANNELIZATION CODES 289
During the channelization coding process, data symbols on I- and Q-branches are indepen-
dently spread by OVSF8 codes and during the scrambling operation, the resultant signals
on the I- and Q-branches are further multiplied by complex-valued Scrambling code. The
following section describes the codes used on each of these uplink channels.
Figure 8.24: Spreading for uplink dedicated channels (Source: 25.213)
1. Code Allocation for DPCCH: There can be only one DPCCH channel per UE
which is used for sending L1 control information from UE to Node B. According to
TS 25.213, the channelization code used for DPCCH is always cc = Cch,256,0 .
2. Code Allocation for DPDCH: According to Rel-99 specifications, it is possible to

have 1, 2, 3, 4, 5 or 6 DPDCH channels from one UE. It is also specified that if a
UE transmits more than one DPDCH, then the SF of all of these channels will be
SF=4. But from practical implementation viewpoint, this case is not so interesting.
In popular deployments around the world, we have maximum one DPDCH per UE.
DPDCH channel is a variable bit rate channel which can have seven possible spread-
ing factors; SF = 4, 8, 16, 32, 64, 128 or 256. The exact spreading code can be
found by CCH,SF, SF/4 , where SF is the spreading factor.
Channelization Code for DPDCH1 = CCH,SF, SF/4
3. Code Allocation for HS-DPCCH: Since there is an ‘HS-’, in the name of this
channel, one can easily identify that this channel is related to HSDPA. The official
name of HS-DPCCH channel is ‘uplink Dedicated Control Channel associated
8
Orthogonal Variable Spreading Factor
290 BIBLIOGRAPHY
with HS-DSCH transmission’. I have often heard people calling it as ‘High

Speed DPCCH’ or ‘HSDPA Feedback channel’. In fact, this channel is used to send
uplink feedback (CQI and Ack/Nack) for HSDPA transmission.
HS-DPCCH is always spread with SF = 256 and the exact code number is dependent
of ‘Max Number of R99 DPDCH’ channels, which can be 1 to 6.
The HS-DPCCH shall be spread with code which is decided by the following rules:


 Cch,256,33 if NMax, DPDCH = 0,

Cch,256,64 if NMax, DPDCH = 1,
Code for HS-DPCCH =

 Cch,256,1 if NMax, DPDCH = 2, 4, 6

Cch,256,32 if NMax, DPDCH = 3, 5
These rules are described in the section 4.3.1.2.2 of 3GPP TS 25.213.
This section shows all the possible cases but only the first two cases are
popularly used. NMax, DPDCH = 0 is possible if the L3 signalling (SRBs)
are mapped on HSPA.
HS-DPCCH shall be mapped to the I-branch in case NMax, DPDCH is 2, 4 or 6, and

to the Q-branch otherwise (NMax, DPDCH = 0, 1, 3 or 5).
4. Code Allocation for E-DPCCH: Now it’s turn of HSUPA related channels. Just
like R99 DPCCH, in HSUPA also, we have a E-DPCCH channel which carries L1
control information in uplink. This L1 signalling is related to the data transmission
in E-DPDCH.
E-DPCCH is a fixed rate channel which always uses SF =256. According to 3GPP
TS 25.213, the DPCCH is always spread by code cc = Cch,256,1 and always mapped
on the I-branch.
5. Code Allocation for E-DPDCH: The data channel which is used for carrying up-
link HSUPA data is called E-DPDCH. Just like Rel-99 DPDCH, E-DPDCH is also
a variable bit rate channel with two improvements:
1. Smallest SF of DPDCH is 4, whereas E-DPDCH can also use SF = 2.

2. The modulation used in Rel-99 DPDCH is always BPSK. In Rel-6, E-DPDCH
cannot use any higher order modulation. But from REL-7 onwards, E-DPDCH
is allowed to use both BPSK and 4PAM modulations.
Hence, E-DPDCH channel can have 8 possible spreading factors: SF = 2, 4, 8, 16,

32, 64, 128 or 256. In order to achieve multi-Mbps speeds, UE can combine several
codes and transmit them together in uplink. Once again, the channelization code(s)
used for E-DPDCH(s), depends on if NMax, DPDCH . Table 8.11 is taken from 3GPP
TS 25.213, where the rules for code allocation are described with full details.
8.13. DL CHANNELIZATION CODES 291
if NMax, DPDCH E-DPDCHk Channelization Code Ced,k

0 E-DPDCH1 Cch, SF, SF/4 if SF ≥ 4
Cch, 2, 1 if SF = 2
E-DPDCH2 Cch, 4, 1 if SF = 4
Cch, 2, 1 if SF = 2
E-DPDCH3 Cch, 4, 1
E-DPDCH4
1 E-DPDCH1 Cch, SF, SF/2
E-DPDCH2 Cch, 4, 2 if SF = 4
Cch, 2, 1 if SF = 2
Table 8.11: Channelisation code for E-DPDCH
8.13 DL Channelization Codes

The channelization codes used on DL physical channels are the same codes as used in the
uplink namely ‘Orthogonal Variable Spreading Factor (OVSF)’ codes that preserve the
orthogonality between downlink channels of different rates and spreading factors.
8.13.1 R99 DL Channels

1. & 2. Synchronization Channels: As an exception, P-SCH and S-SCH channels are
not spread using any channelization codes.
3. Primary-CPICH: The channelization code for the Primary-CPICH is fixed to Cch,256,0

in all 3G networks around the world. Please refer to section 5.2.1 of 3GPP TS 25.213.
4. Primary-CCPCH: The channelization code for the Primary CCPCH is fixed to

Cch,256,1. This rule is specified is also specified in section 5.2.1 of 3GPP TS 25.213.
Other R99 Common Channels: The channelization codes for all other physical chan-
nels are assigned by UTRAN.
5. PICH: SF of Paging Indicator Channel (PICH) is fixed and equal to 256. The
exact code number is broadcasted to UEs via system information (BCH).
6. AICH: SF of Acquisition Indicator Channel (AICH) is also fixed and equal to
256. Similar to PICH, the code number of AICH is also broadcasted via system
information (BCH).
7. S-CCPCH: Secondary Common Control Physical Channel (S-CCPCH) is used
to carry the FACH and PCH transport channels. The FACH and PCH can
be mapped to the same or to separate secondary-CCPCHs. Spreading fac-
tor of S-CCPCH can have 7 possible values; SF = 4, 8, 16, 32, 64, 128 or
292 BIBLIOGRAPHY
256. The spreading factor, code number and other details about S-CCPCH
configuration, are broadcasted using system information.
8. DL DPCH: Dedicated physical channel (DPCH) is the main data channel in R99
(UMTS). Its spreading factor can take one value from the 7 possible options; SF =
4, 8, 16, 32, 64, 128 or 256. RNC is responsible for performing the code allocation
on demand. RNC chooses the ‘SF & Code Number’ based on required bit rate and
the code availability. UE gets the information about code allocation by explicit L3
(RRC layer) signalling. Some famous messages in this category are ‘RRC Connection
Setup’, ‘Active Set Update’, ‘Radio Bearer Setup’, ‘Radio Bearer Reconfiguration’,
etc.
8.13.2 HSDPA-related DL Channels

1. HS-SCCH: 3GPP has fixed the spreading factor of HS-SCCH to 128. As mentioned
earlier in this book, there can be 1 or more HS-SCCH(s) per cell. Their configuration
& code number must be signalled to the user by RNC at the beginning of HSDPA
session using RRC signalling. For example, messages like ‘Radio Bearer Setup’,
‘Radio Bearer Reconfiguration’, etc. are used to inform UE about the operator-
defined cell-specific details of HSDPA & HSUPA.
2. HS-PDSCH: For HS-PDSCH, the spreading factor is always 16. Since the name
itself says ‘shared’ channel, there is no static allocation of these channels to a UE.
The Node B’s MAC-hs scheduler makes the decision about Code(s) allocation and
informs all the UEs in cell using HS-SCCH channel.
8.13.3 HSUPA Related DL Channels

1. & 2. E-HICH & E-RGCH: For E-HICH and for E-RGCH, the spreading factor is
always 128. The E-RGCH and E-HICH are sent on the same channelization code.
The exact code number must be signalled to the user by RNC at the beginning of
the HSUPA session.
3. E-AGCH: For E-AGCH, the spreading factor is 256. The exact code number must
be signalled to the user by RNC at the beginning of HSUPA session. If the cell
supports both 10ms and 2ms TTI on E-DCH transport channel, there must be two
separate E-AGCHs:
• E-AGCH for 10 ms E-DCH TTI &

• E-AGCH for 2 ms E-DCH TTI.
8.13. DL CHANNELIZATION CODES 293
Copyright Notices

Table 8.11 on page 291 Table 1E of 3GPP TS 25.213 v 8.4.0.
Text about DPCCH/DPDCH Section 4.3.1.2.1 of 3GPP TS 25.213 v 8.4.0.
channelization codes on page 289
Text about HS-DPDCH channel- Section 4.3.1.2.2 of 3GPP TS 25.213 v 8.4.0.
ization codes on page 289
Text about E-DPCCH/E- Section 4.3.1.2.3 of 3GPP TS 25.213 v 8.4.0.
DPDCH channelization codes on
page 290
Text about channelization codes Section 5.2.1 of 3GPP TS 25.213 v 8.4.0.
of R99 DL channels on page 291
of HSDPA DL channels on page
292
of HSUPA DL channels on page
292
⃝2009.
BIBLIOGRAPHY
294
CHAPTER
SIGNALLING
Source:
• 3GPP TR 25.931 ver. 8.0.0 ;‘UTRAN functions, examples on signalling
procedures’
• H.Holma and A. Toskala, ‘WCDMA for UMTS’ , 5th Edition, John Wiley
& Sons.
• Chris Johnson, ‘Radio Access Networks For UMTS; Principles And Practice’ ,
John Wiley & Sons.
This chapter is inspired from the book ‘Radio Access Networks For UMTS;
Principles And Practice’ by Chris Johnson, where various signalling scenarios
are illustrated with the help of diagrams, signalling traces and elaborative text.
In ‘Let’s Learn 3G in 10 Days’, the author has tried to explain the same
by skipping some details. The advanced readers should refer to the above
mentioned reference to get more details, which is an excellent source of 3G
fundamentals.
In order to establish any service, certain information much be exchanged between various
nodes in the network. For example, subscriber has to request for radio resources from
RNC and services from core network. To fully understand the functionality of UMTS and
HSPA, we should understand these signalling mechanisms.
295
296 CHAPTER 9. SIGNALLING
9.1 Building Blocks of 3G Signalling

Any signalling diagram of 3G is a combination of 2 or more building blocks that are
discussed below. In the following section, we will make ourselves familiar with these terms
which are very commonly used in 3G. These words have been used several times in this
book which proves their importance. We will define 5 items here:
1. RRC Connection
2. Radio Bearer
3. Radio Access Bearer
4. Radio Link
5. Non-Access Stratum (NAS) Signalling Connection
9.1.1 RRC Connection

RRC connection is a dedicated connection between RRC peer entities on UE
and UTRAN side (in RNC). It is used to carry dedicated control channel
(logical channel DCCH) in both directions (i.e., UE to RNC, as well as RNC
to UE).
There are two kinds of RRC connections. One kind is related to service access, the other
kind is not related to service, such as related to location update, cell update, network
registration etc.
As we know, Radio Resource Control (RRC) is the name of control plane protocol
between UE and RNC. Therefore, an ‘RRC Connection’ is a connection that carries control
signalling between these two entities. RRC connection is always point-to-point between
RRC entities on the UE and the RNC sides. It is always bi-directional in nature. UE has
at least zero and at most one RRC connection1 .
• When UE has zero RRC connections, it is said to be in RRC IDLE Mode.

In this state, RNC has no information about the subscriber.
• When UE has one RRC connection, it is in RRC Connected Mode. In RRC

connected mode, UE can be in either CELL DCH, CELL FACH, CELL PCH or
URA PCH states.
1
Note: Even in soft-handover or Inter-RNC Soft-handover case, there is only one RRC connec-
tion.
9.1. BUILDING BLOCKS OF 3G SIGNALLING 297
Figure 9.1: RRC Connection Establishment & Idle to Connected Mode Transition
The transition from Idle to Connected mode takes place on RRC Connection Establish-
ment. Request to setup an RRC connection is always initiated by UE. RNC’s admission
control has the authority to setup or reject the RRC connection request. The signalling
flow is illustrated in figure 9.1.
1. The UE initiates set-up of an RRC connection by sending RRC CONNECTION

REQUEST message on RACH.
2. Based on a look-up table which shows mapping between the establishment cause and
transport channel type (e.g., for voice calls: DCH/DCH and for SMS: RACH/FACH),
the SRNC decides to use either RACH/FACH or DCH/DCH for this RRC connec-
tion. Later, RNC checks for the availability of radio resources, hardware resources,
transmission resources and if all these checks are successful, RRC CONNECTION
SETUP message is sent on FACH.
3. UE sends RRC CONNECTION SETUP COMPLETE on a DCCH logical chan-
nel mapped on the DCH transport channel or RACH transport channel as
decided by RNC and indicated to UE by RRC CONNECTION SETUP message.
In this section, we are trying to define ‘RRC Connection’ as a signalling building block
only. A more detailed description of RRC Connection establishment is available in section
9.2.
9.1.2 Radio Access Bearer (RAB)

According to 3GPP TR 21.905 which contains a vocabulary for 3GPP Speci-
fications, “Radio Access Bearer (RAB) is a service provided by access stra-
tum to the non-access stratum for transfer of user data between User
Equipment (UE) and Core Network (CN)”.
In order to establish a RAB between UE and CN, we require
1. Radio Bearer (between UE and RNC), and

2. Iu Bearer (between RNC and CN)
As a first step, we can consider RAB as the same as service. There are many types of
RABs, e.g., CS Voice RAB, CS Streaming RAB, CS Video RAB, PS Interactive RAB,
PS Background RAB, etc. In case of multiple services, we can define a multi-RAB as a
combination of two or more RABs. A CS RAB is established between UE and MSC and
a PS RAB is between UE and SGSN. Radio Access Bearer is a logical connection between
UE and Core Network(MSC or SGSN). But in order to guarantee the QoS, RAB uses the
services of Radio Bearer and Iu Bearer.
Figure 9.2 illustrates the sequence of messages exchanged between UE, RNC and CN for
establishing a RAB.
1. The process of RAB establishment starts after RNC gets a RANAP: RAB ASSIGN-
MENT REQUEST message from Core Network.
2. RNC has the authority to either accept or reject this request. In both the cases,
RNC sends a RANAP: RAB ASSIGNMENT RESPONSE message to CN which
indicates either positive outcome or negative outcome of the RAB establishment
procedure.
9.1.3 Radio Bearer

Radio Bearer is a bearer service which defines the quality of service for the
user data stream between UE and RNC. If we study the Radio Bearer care-
fully, we can find the configuration of all protocol layers of radio protocols e.g.,
PDCP, RLC, MAC and Physical layers.
According to 3GPP TR 21.905, Radio Bearer is defined as, “the service provided by the
Layer 2 for transfer of user data between User Equipment and UTRAN”. Radio Bearer is
a building block and pre-requisite for RAB. Therefore, when core network requests RNC
for RAB establishment, the Radio Bearer setup procedure gets automatically triggered.
Figure 9.2: Radio Access Bearer
The same situation has been illustrated in figure 9.3. Since radio bearer is established
between UE and RNC, the RRC protocol plays an important role in the setup procedure.
After successful decision to establish Radio Bearer, RNC informs UE about the configu-
ration of Physical, MAC, RLC and PDCP layer using RRC: RADIO BEARER SETUP
message. During the connection, if RNC decides to modify the current configuration, it
sends RRC: RADIO BEARER RECONFIGURATION message to UE. As shown in figure
9.3, UE acknowledges the receipt and compatibility by sending a RRC: RADIO BEARER
SETUP COMPLETE or RRC: RADIO BEARER RECONFIGURATION COMPLETE
message.
Figure 9.3: Radio Bearer Establishment/Modification
9.1.4 Radio Link

By definition, “Radio Link is the logical name given to the association between
a single user and single Node B”. During soft-handover, UE can maintain
several radio links (one radio link for each active set cell). Radio links are
added to or deleted from the active set. Even in softer-handover, UE has
multiple radio links.
A Radio Link is simply a bunch of UL & DL physical channels between one UE and
one Node B. The decision about the codes used on the physical channels is made by RNC.
Therefore, RNC informs Node B about the codes, timing, Transport Format Set, TTI and
other essential information using NBAP: RADIO LINK SETUP REQUEST message. The
details of NBAP protocol are available in 3GPP TS 25.433.
As shown in the figure 9.4, RNC initiates the setup of radio link by sending NBAP: RADIO
LINK SETUP REQUEST message to Node B. This message instructs Node B about the
‘CRC communication Context id’, which acts like a nickname for this particular radio
link whenever Node wants to address RNC regarding this radio link. This process gets
completed when Node B replies with NBAP: RADIO LINK SETUP RESPONSE message,
which includes a ‘Node B Communication Context id’. For any future NBAP transactions,
reference will be made using these 2 context ids.
Figure 9.4: Radio Link Setup or Reconfiguration
An example of this is shown in the right sub-figure in figure 9.4. In this figure, the
procedure of ‘Synchronised Radio Link Reconfiguration’ is illustrated. There can be several
Radio Links between the UE and the Node B but with the help of Node B Communication
Context ID and CRNC Communication context id, we can uniquely identify the radio link
whose configuration must be modified. This procedure gets completed in three messages:
1. Radio Link Reconfiguration Prepare
2. Radio Link Reconfiguration Ready

3. Radio Link Reconfiguration Commit
9.1.5 Non-Access Stratum (NAS) Signalling Connection

NAS Signalling connection (UE CN) is a control plane logical connection.
NAS connection is realized using a combination of RRC Connection (UE
RNC) and Iu Connection (RNC CN).
Figure 9.5: Non-Access Stratum (NAS) Signalling Connection
Non-Access Stratum is a combined name for a group of control plane protocols that are
used in 2G & 3G. These set of protocols are access-agnostic which means that their defini-
tions do not depend on the underlying Access Stratum technology. Access stratum is used
to carry the NAS messages. Transfer of NAS messages between RNC and Core network
happens by RANAP signalling protocol. Similarly, between UE and RNC, RRC protocol
is used to transfer NAS messages. The example described in the following paragraph and
figure 9.5 elaborate this concept.
For example, CM: Service Request is a message which UE sends to MSC in order to request
for a specific circuit switched service. Therefore, CM: Service Request is a NAS message
which gets transported by RRC:Initial Direct Transfer from UE to RNC and by RANAP:
Initial UE message from RNC to CN. The RRC layer and RANAP layer do not decode
the NAS message because Node B and RNC do not have NAS entities. NAS entities are
only in UE and Core Network.
After learning about these building blocks, now we will focus on few commonly discussed
signalling scenarios and analyze how these building blocks are used.
9.2 RRC Connection Establishment

As explained in section 9.1.1, RRC connection is a dedicated signalling connection be-
tween UE and RNC. The transport channels used for these signalling messages can be
either dedicated channels (DCH(↑↓) ) or common channels (FACH (↓) /RACH(↑)). In
the following sections, we will investigate both the options.
Option 1: ‘Signalling Radio Bearers on dedicated channels’ (see section 9.2.1).
1. UE sends RRC CONNECTION REQUEST on CCCH logical channel mapped

on the RACH transport channel.
2. RNC sends RRC CONNECTION SETUP on CCCH logical channel mapped
on the FACH transport channel.
3. UE sends RRC CONNECTION SETUP COMPLETE on a DCCH logical
channel mapped on the DCH transport channel.
4. All further DCCH messages are exchanged on DCH.
Option 2: ‘Signalling Radio Bearers on common channels’ (see section 9.2.2)
1. UE sends RRC CONNECTION REQUEST on CCCH logical channel mapped

on the RACH transport channel (same as option 1).
2. RNC sends RRC CONNECTION SETUP on CCCH logical channel mapped
on the FACH transport channel (same as option 1).
3. UE sends RRC CONNECTION SETUP COMPLETE on a DCCH logical
channel mapped on the RACH transport channel.
4. All further DCCH messages are exchanged on RACH/FACH.
9.2.1 RRC Connection on Dedicated Channels - DCH

1. The UE initiates the set-up of an RRC connection by sending RRC CONNECTION
REQUEST message on RACH. The main parameters in this message are Initial UE
Identity (e.g., IMSI or TMSI+LAI), Establishment cause (e.g., Originating conver-
sation call), measurement result about DL coverage quality. The quantity used for
this reporting is broadcasted in SIB 11 of system information under the IE ‘Intra-
frequency reporting quantity for RACH reporting’.
From Rel-5 onwards, the new devices must also indicate whether they support HS-
DPA or HSPA2 . All the possible values for establishment cause are listed in 3GPP
TS 25.331.
2
Not the exact device category and radio access capabilities.
9.2. RRC CONNECTION ESTABLISHMENT 303
Figure 9.6: RRC Connection Establishment - DCH Establishment.
2. Based on a look-up table, the SRNC decides to use either RACH/FACH or DCH/DCH
for this RRC connection. Operators can tune this table by RNC parameters for each
establishment cause. At this moment, RNC allocates both U-RNTI and C-RNTI
identifiers to address the UEs within UTRAN.
In this example, the SRNC decides to use a DCH for this RRC connec-
tion, allocates U-RNTI and radio resources for the RRC connection.
Step 2a. Radio Link Setup: When a DCH is to be setup, NBAP: RADIO LINK
SETUP REQUEST message is sent to Node B. In this message, RNC informs
Node B about the Cell id, Transport Format Set (TFS), Transport Format
Combination Set (TFCS), frequency, UL Scrambling code, DL channelization
code, Power control information etc. Node B allocates resources, starts phys-
ical layer reception, and responds with NBAP: RADIO LINK SETUP RE-
SPONSE message. The main parameters in this message are: signalling link
termination, transport layer addressing information (AAL2 address, AAL2
Binding Identity) for the Iub Data Transport Bearer.
As indicated in section 9.1.4, Node B and RNC negotiate two context ids for
this particular radio link for future NBAP transactions related to this radio
link.
Step 2b. Iub Transport Bearer Setup: RNC initiates setup of Iub Data Trans-
port bearer using ALCAP protocol using ALCAP: ESTABLISHMENT RE-
QUEST (ERQ) message. This request contains the AAL2 Binding Identity to
bind the Iub Data Transport Bearer to the DCH. The request for setup of Iub
Data Transport bearer is acknowledged by Node B by sending an ALCAP:
ESTABLISHMENT CONFIRM message.
Step 2c. DCH Frame Synchronization: The Node B and SRNC establish syn-
chronization for the Iub Data Transport Bearer by means of exchange of the ap-
propriate DCH Frame Protocol frames ‘DOWNLINK SYNCHRONIZATION’
and ‘UPLINK SYNCHRONIZATION’. Then Node B starts DL transmission.
3. If all these procedures are successful, the RRC CONNECTION SETUP message
is sent on FACH from RNC to UE. Using this message, RNC informs UE about
several parameters, such as, Initial UE Identity, U-RNTI, Transport Format Set
(TFS), Transport Format Combination Set (TFCS), DL channelization code, UL
Scrambling code, Power control information, etc. RRC CONNECTION SETUP
message informs UE about the ‘Capability update Requirement’. It is expected
that UE will include the details about its capabilities in the next message. If RRC
redirection to another frequency is used, RRC CONNECTION SETUP message also
includes the target frequency where the redirection must take place.
4. Node B achieves uplink sync and notifies SRNC with NBAP: RADIO LINK RE-
STORE INDICATION message.
5. Message RRC Connection Setup Complete is sent on DCCH logical channel from UE
to SRNC. This message includes parameters like integrity protection and ciphering
algorithms supported by UE information and UE radio access capability. If the
device supports HSDPA and/or HSUPA, the device category number must also be
specified here. Additionally, if smart features like MIMO, A-GPS, DC-HSDPA,
16-QAM etc. are supported, UE must include these details in this message.
9.2.2 RRC Connection on Common Channels - FACH/RACH

Figure 9.7 shows the establishment of an RRC connection on the RACH/FACH common
transport channel. In comparison to the previous example, we can observe that there is no
signalling to setup the Iub Data Transport bearer. Therefore, it is required that transport
bearer for the RACH/FACH is established prior to this procedure.
9.2. RRC CONNECTION ESTABLISHMENT 305
Figure 9.7: RRC Connection on Common Channels - FACH/RACH
Advantages:
The use of Common Channel for carrying DCCH is very beneficial for the
operator because it brings resource efficiency in various ways. The connection
setup signaling and user dedicated resource requirements are reduced at the
BTS, the Iub, and the RNC.
At the Iub interface also, the common channels are carried in a resource-
efficient way. In the Node B, less processing capacity (channel element) is
consumed for signalling radio bearers, and the hardware load caused by sig-
nalling is decreased. In the RNC, the number of users in the Cell DCH state,
as well as the load of the connection setup signaling, is reduced.
At the radio interface, less channelization codes are required for signaling.
Typically, RRC connection setup on common channels is faster than using DCH, because
delays for setting up dedicated channels and synchronous reconfiguration can be avoided.
When RNC feels the need of setting up an DCH, HS-DSCH or E-DCH channel for UE, it
can instruct the user to perform Cell FACH to Cell DCH transition.
Disadvantages:
Since RACH and FACH are common transport channels, they can experience
congestion if a large number of UEs are using them simultaneously. Therefore,
the quality of service offered by RRC connection on common channels is less
than the same on dedicated channels.
Operators have to consider an upgrade in L1 capacity of RACH and FACH
before allowing RRC connection on common channels.
9.3 Mobile Originated Voice Call Establishment

Source:
• Chris Johnson, ‘Radio Access Networks For UMTS ; Principles And
3G has improved the end-user experience of high bit rate data services but voice is still the
most important service offered by mobile operators. In this section, we will understand
the signalling flow of a ‘Mobile Originated CS conversational voice call’ setup. If the
readers are familiar with the call flow of GSM, they should compare the GSM call flow
with UMTS CS call flow and find out the similarities and differences. In short, we can
make 2 statements in advance.
1. RRC connection and RAB are new concepts that were introduced in 3G. Therefore,
RRC Connection establishment and RAB setup phase are different in comparison
to 2G call flow.
2. The signalling between UE and Core Network is exactly the same as used in GSM.
In order to simplify the understanding, we will divide the whole procedure into phases 4
phases:
1. Phase 1: RRC Connection Establishment
2. Phase 2: Signalling between UE & CN
3. Phase 3: RAB Setup
Phase 1: RRC Connection Establishment: In order to establish any CS service, UE

must contact MSC and request for the same. But in order to reach MSC, UE needs
dedicated signalling resources (DCCH). UE uses the common signalling resources
(CCCH mapped on RACH/FACH) to obtain dedicated signalling resources. This
procedure was explained in full detail in section 9.2.
Phase 2: Signalling between UE & CN: Using the signalling resources obtained in
phase 1, UE performs negotiations with MSC.
1. The first NAS message is CM: Service Request. This NAS message is
carried by two access stratum (AS) protocols RRC and RANAP, as shown in
figure9.8. When the first NAS message arrives at RNC, it encapsulates it into
an SCCP: CONNECTION REQUEST message. SCCP signalling is used to
establish an Iu-CS signalling connection. The CS core network confirms the
9.3. MOBILE ORIGINATED VOICE CALL ESTABLISHMENT 307
Figure 9.8: Mobile Originated Voice Call Establishment; Source: ‘Radio Access
Networks For UMTS; Principles And Practice’ by Chris Johnson
setup of an Iu-CS connection by sending SCCP: CONNECTION CONFIRM

message. SCCP connection is identified by 2 numbers ‘source local reference’
and ‘destination local reference’.
2. Serving MSC sends AUTHENTICATION REQUEST message with 2 pa-
rameters: Authentication Token (AUTN) and Random Number (RAND). Us-
ing RAND and a secret key (stored in SIM card), UE calculates the AUTN,
Signed Response (SRES), Integrity key (IK) and ciphering key (CK). UE com-
pares the calculated AUTN with received AUTN. If they match, UE sends
AUTHENTICATION RESPONSE message to MSC including SRES.
3. The RANAP: SECURITY MODE COMMAND message informs RNC
about the list of integrity protection and ciphering algorithms that are per-
mitted by the core network. RNC chooses the algorithms according to its own
capability and UE’s capability. This message also includes the reference start-
ing point of ciphering. UE acknowledges by responding with SECURITY
MODE COMPLETE and RNC forwards this message to core network.
4. The next message in the sequence is a CM: SETUP message from UE to MSC
which informs MSC about the bearer capability (supported codecs), the binary
coded decimal (BCD) number of called party and call control capabilities.
Phase 3: RAB Setup: Procedure of RAB setup begins when core network requests
RNC for setting up a CS conversational class RAB with some requested QoS. At
this moment, RNC’s admission control checks for UL interference, DL transmission
power and DL channelization codes. If these radio resources are available, RNC
starts hunting for logical and physical resources. This mechanism is briefly summa-
rized as:
(3.a) Radio Link: A radio link between UE and Node B was established at the
time of RRC connection establishment. But that radio link was purely for
signalling. In order to setup the radio bearer for user plane voice traffic, radio
link must be reconfigured. The procedure has been illustrated in figure 9.4 and
explained in section 9.1.4. Using this proedure, RNC informs Node B about
the transport format set, DL channelization code, UL scrambling code, DPCH
offset etc. At this point, RNC informs Node B about the Connection Frame
Number (CFN) where the modified radio link will become active.
(3.b) Transport Bearer: Using ALCAP signalling, data transport bearer on Iub
and Iu-CS is established. RNC initiates the setup of the transport bearer
between RNC and Node B and between RNC and MSC.
(3.c) Radio Bearer: Using RRC: Radio Bearer Setup message, RNC instructs
UE about the configuration of various protocol layers and channel mapping.
Information about all the transport channel parameters e.g. Transport For-
mat Set, TTI, CRC size etc. and all physical layer parameters e.g., codes,
frequency band, slot format, power control information and CFN are carried
9.3. MOBILE ORIGINATED VOICE CALL ESTABLISHMENT 309
by this message3 . UE acknowledges the reception by sending RRC: RADIO

BEARER SETUP COMPLETE message.
Phase 4: Signalling between UE & CN: 1. After getting response from the serv-
ing MSC of the called party, MSC of the calling party sends an ALERTING
message to UE which indicates that the other party’s phone is ringing.
2. After the called party accepts the call, this information is transported to the
calling party using CONNECT message.
3. UE responds with a CONNECT ACKNOWLEDGE message to CN.
From this point onwards, a CS voice call is established between the calling and the called
party.
3
This step can be compared to TCH ASSIGNMENT in GSM call flow because up to this point,
UE is assigned resources for only DCCH and after this point, DTCH can also be sent/received by
UE.
9.4 Mobile Terminated Voice Call Establishment

Source:
When we compare the figure 9.9 showing the call flow for ‘Mobile Terminated CS con-
versational voice call’ setup with figure 9.8 showing the same for mobile originated call
flow, it is obvious that there are a lot of similarities but there are some differences too.
In this section, we will investigate the signalling for an incoming call by focussing on the
serving-MSC, SRNC and the called party4 .
Similar to the example of mobile-originated-call, we will divide the whole procedure into
phases to simplify the learning:
1. Phase 1: Paging
4. Phase 4: RAB Setup
The first difference between the MTC and MOC is already visible at this point. There is
an additional signalling phase called Paging for MTC case.
Phase 1: Paging: In idle mode, UE keeps on reporting5 its Location Area (LA) to
MSC/VLR and about its Routing Area (RA) to the SGSN of the visited-PLMN
(VPLMN). In other words, the location of an idle mode UE is known to the network
at LA level or RA level. Therefore, if there is any incoming call for him, the network
must page him by ‘shouting’ his name in the relevant area.
In the case of Mobile Terminated Call (MTC), when MSC receives a request to
setup a call, it sends a RANAP: PAGING message to all the RNCs in that Location
Area. This message contains the subscriber’s identity (e.g., IMSI or TMSI+LAI,
etc.) and the paging cause. In case of incoming voice call, it will be ‘Terminated
Conversation Call.’ RNCs forward the paging message to all the cells in their
4
often called as subscriber ‘B’ or ‘B Party’
5
1. At Switch On/OFF,
2. after moving to a new LA/RA,
3. and periodically based on timers
9.4. MOBILE TERMINATED VOICE CALL ESTABLISHMENT 311
Figure 9.9: Mobile Terminated Voice Call Establishment; Source: ‘Radio Access
respective controlling areas using RRC: PAGING TYPE 1 message (PCCH → PCH
→ S-CCPCH).
Phase 2: RRC Connection Establishment: When UE in idle mode reads its own
identity on the paging message, it tries to contact the network by using initial
access. This triggers the setup of an RRC Connection. This mechanism is the same
as in Mobile Originated Call (MOC) except the establishment cause parameter.
The cause specified in paging message is echoed by UE while requesting for an RRC
Connection.
Phase 3: Signalling between UE & CN: Using the signalling resources obtained in
phase 1, UE performs negotiations with MSC.
1. The first NAS message is CM: PAGING RESPONSE. This NAS message
is carried by two access stratum (AS) protocols: RRC and RANAP, as shown
in figure 9.9.
Similar to the MOC case, when the first NAS message arrives at RNC, a SCCP
connection is setup between CN and RNC.
2. Authentication procedure is optional but if it is used, there is no difference
compared to the MOC case.
3. SECURITY MODE COMMAND and SECURITY MODE COM-
PLETE procedures are also exactly the same as in MOC example.
4. In MTC case, the CM: SETUP message is sent from MSC to UE which
informs UE about the bearer capability (supported codecs) and the binary
coded decimal (BCD) number of the calling party. This number is used to flash
on the UE’s display so that the called subscriber can identify the calling party.
The UE acknowledges the setup message by sending a CALL CONFIRMED
message.
Phase 4: RAB Setup: RAB setup phase has no difference compared to the MOC ex-
ample. Therefore, the description of this phase will not be repeated. This phase
includes following procedures:
(4.a) Radio Link setup

(4.b) Transport Bearer setup
(4.c) Radio Bearer setup
Phase 5: Signalling between UE & CN: After the Radio Access Bearer (RAB) has
been established, the signalling to connect the two parties takes place.
1. The UE of called party sends an ALERTING message to the core network.

This message will be forwarded to the serving core network of the calling party
and finally delivered to the calling subscriber. The calling subscriber will be
intimated by playing the ring-back tone or by playing the caller tune. This
action will not stop until the called party answers the call or a timer expires.
9.4. MOBILE TERMINATED VOICE CALL ESTABLISHMENT 313
2. Once the ‘called’ subscriber (human being) answers the call, a CONNECT
message is forwarded from Called Party to → CN of called party to → CN of
calling party to → the calling party.
3. The CN of the called party responds with a CONNECT ACKNOWL-
EDGE message to the calling UE.
With this CONNECT ACKNOWLEDGE message, we can say that the call has been
established and voice traffic can be transported in both directions.
9.5 PS Data Session Setup

Source:
The packet session setup is also similar to voice call setup up to some extent. But
there are some significant differences which must be discussed now.
• In CS-domain, UE performs IMSI attach to get registered with MSC/VLR. In PS-

domain, UE must perform ‘GPRS ATTACH’ and register with SGSN. While learn-
ing about the PS session setup, we must differentiate the 2 cases:
1. UE is not yet registered with SGSN and it performs PS data session setup.
2. UE is already registered with SGSN and it performs PS data session setup.
• In CS-domain, UE can make and receive calls as soon as it is attached to MSC/VLR.

But in PS-domain, data transfer is possible only after getting an IP-address.
The signalling shown in this section is valid for UMTS PS sessions, HSDPA
PS sessions and also for HSUPA PS data sessions.
Figure 9.10: Initial NAS message from a registered and non-registered user
There are 4 phases in the session setup signalling and they are listed below:
9.5. PS DATA SESSION SETUP 315
2. Phase 2: Signalling between UE and PS Core Network: GPRS ATTACH
3. Phase 3: Signalling between UE and PS Core Network: PDP Context Activation
4. Phase 4: RAB Setup (during PDP activation phase)
Phase 1: RRC Connection Establishment: As discussed in the earlier signalling ex-

amples and in the beginning of chapter, RRC connection is established between
UE and RNC to setup a signalling connection for the transfer of signalling radio
bearers. This mechanism is the same as explained earlier except the establishment
cause parameter. These causes are defined in 3GPP TS 25.331 specification. The
terminology used by core network specifications and radio specification is slightly
different. Fortunately, in Table L.1.2 of 3GPP TS 24.008 the mapping of PS NAS
procedure to establishment cause in RRC connection request is explained. In short,
the establishment cause used in this case will be:
• ‘REGISTRATION’ if UE has not already registered with SGSN,

• Otherwise ‘ORIGINATING INTERACTIVE CALL’ or
• ORIGINATING ‘BACKGROUND CALL’ or
• ORIGINATING ‘HIGH-PRIORITY SIGNALLING’.
Similarly, when the UE is registered with SGSN (or ATTACHED), there can be
paging with paging causes ‘TERMINATING INTERACTIVE CALL’, ‘TERMI-
NATING BACKGROUND CALL’ or ‘TERMINATING HIGH-PRIORITY SIG-
NALLING’. In that case, UE uses the same establishment cause while requesting
an RRC connection.
Phase 2: UE Core Network signalling: GPRS ATTACH: In order to ATTACH

itself to the packet core network, UE sends a GMM: ATTACH REQUEST mes-
sage towards SGSN. This NAS message is carried by the RRC and RANAP protocols
in access stratum. As soon as the first NAS message arrives at RNC, it triggers the
setup of an SCCP connection between RNC and SGSN. Figure 9.10 shows two
different scenarios.
1. In the left sub-figure, the UE is not yet registered in SGSN and it performs
PS data session setup.
2. In the right sub-figure, the UE is already registered in SGSN and it performs
PS data session setup.
Phase 3: UE Core Network signalling: PDP Context Activation: After reg-

istering in SGSN, a mobility management context exists at SGSN and UE side,
but UE does not have an IP address. In order to acquire an IP address and negoti-
ate the QoS, UE requests activation of PDP context.
The NAS message ‘ACTIVATE PDP CONTEXT REQUEST’ arrives at SGSN and
it chooses the desired GGSN based on Access Point Name (APN) requested in
this message. If UE does not explicitly ask for some particular QoS, then the
QoS profile from HLR should be used. SGSN obtains this data from HLR while
performing ATTACH in the previous step. UE assigns a Network Service Access
Point Indicator (NSAPI) to this PDP context. Optionally, UE can also specify the
protocol configuration information for external network protocols.
If GGSN agrees on the QoS requested, it sends its response to SGSN. SGSN can
inform the UE about the successful PDP context activation but before that RAB
must be established.
Phase 4: RAB Setup (during PDP activation phase): Depending on the strategies
chosen by equipment vendors, packet session in UMTS and HSPA can be established
in 2 different ways.
Option 1: Direct Resource Allocation: One strategy is to directly allocate some

nominal bit rate on DCH or HSPA resources at the time of RAB setup (see
figure 9.11). This scheme reduces the connection establishment delay. In this
strategy, RNC makes the decision about using DPH, HSDPA or HSPA config-
uration during RAB establishment itself.
Option 2: First ‘Zero Bitrate’ bearer and later resource allocation: Another
strategy is establish a RAB with radio bearer of only DCH ‘0 kbps’ in UL &
DL and allocate the real resources only if RNC’s packet scheduler receives a
‘capacity request’ from UE or from MAC layer within RNC. This scheme has
an advantage that the resources are allocated only when there is actual need
to send or receive data.
It depends on the equipment vendors to support either one or both the schemes.
Some vendors support both schemes and operators can choose the one, suitable to
their own preference, by RNC level parameters.
Phase 4; Option 1: Direct Resource Allocation

In Direct Resource Allocation (DRA) strategy, the UE will be allocated some nominal bit
rate at the time of RAB setup.
1. The SGSN sends a RAB ASSIGNMENT REQUEST message to RNC. In this

request, a particular RAB is identified by a RAB-id which is exactly the same as
NSAPI used in the PDP context phase. Other important parameters in this message
are:
• Traffic class,
Figure 9.11: PS session setup with direct resource allocation; Source: ‘Radio
Access Networks For UMTS; Principles And Practice’ by Chris Johnson
• Symmetrical or asymmetrical,
• maximum6 UL & DL bit rate,
• Acceptable error ratios,
• Traffic Handling Priority, (THP) (only for Interactive traffic class, value 1, 2
or 3; 1 = highest priority).
• Allocation Retention Priority (ARP), which can range from 1 to 15 ; 1 =
highest priority).
• Pre-emption Vulnerability and capability, etc.
2. At this moment, the admission control of RNC decides whether the RAB can be
established or not. Packet scheduler decides the transport channel type selection.
HSDPA & HSUPA, HSDPA & DCH or DCH & DCH could be selected for this
particular bearer. The initial bit rates should be decided by the RNC’s parameters.
3. NBAP signalling between Node B and RNC takes place to reconfigure the radio link
at the Node B.
4. ALCAP signalling between Node B and RNC takes place to establish a user plane
Iub data transport bearer.
5. RRC: RADIO BEARER SETUP message informs the UE about the selected
radio bearer configuration for the particular RAB and the activation time. If the HS-
DSCH transport channel has been selected in DL, the HSDPA-specific user identity
H-RNTI is allocated to user. Similarly, if E-DCH transport channel has been selected
in UL, HSUPA specific E-RNTI is also allocated.
6. UE acknowledges by sending an RRC: RADIO BEARER SETUP COMPLETE

message to RNC.
7. Finally, the RAB setup phase is completed when RNC informs SGSN about the
positive outcome of the RAB establishment procedure by sending RANAP: RAB
ASSIGNMENT RESPONSE.
At this moment, a PS data connection exists all the way between UE and some external
server using GGSN as the gateway router. Now, UE can send and receive packets from
the external network to which it just got connected via a specific GGSN. The concepts
about secondary PDP contexts and multiple PDP contexts are not explained further in
this book.
6
‘Maximum’ word plays an important role in this message. UE might ask for maximum bit rate
of several Mbps but allocated only few kbps depending on cell load situation and radio conditions.
Phase 4; Option 2: First ‘Zero Bit rate’ bearer and later

resource allocation
As explained earlier, RNC of some equipment vendors act differently when the RAB
ASSIGNMENT REQUEST message arrives at RNC. In the strategy explained below,
following procedures are postponed until there is a demand for actual resource allocation
from UE or/and from RNC.
1. Postpone bit rate allocation (allocate 0 bit rate)
2. Postpone transport channel type selection (always choose DCH)
3. Postpone radio link reconfiguration at Node B (use same radio link as used for RRC
connection)
4. Postpone Iub transport bearer setup (use same bearer as used for RRC connection)
It is illustrated in figure 9.12, RNC immediately sends a RRC: RADIO BEARER SETUP
message to UE without performing any checks on the resource availability. The actual
bit rate allocated in this message is only ‘0’ kbps. Therefore, this radio bearer is only of
logical value. The transport channel selected for this configuration is always dedicated
channel (DCH).
Afterwards, UE is informed about the minimum threshold of traffic volume that must
be crossed before it can actually request for the resources. Whenever that threshold is
crossed UE informs RNC by sending RRC: MEASUREMENT REPORT. At this moment
the transport channel type selection can take place. RNC can select one of the following
options:
• HSUPA & HSDPA; If both cell & UE support HSPA
• or DCH & HSDPA; If Either cell or UE does not support HSUPA
• or DCH & DCH; If Either cell or UE does not support HSDPA
• or RACH & FACH
If there is no ‘Capacity Request’ in uplink or downlink, RNC will wait some timer expiry.
When this timer expires, UE is shifted from CELL DCH state to CELL FACH state. In
CELL FACH state, UE can send uplink data on RACH and receive DL data on FACH.
Figure 9.12: PS Call setup with ‘Zero bit rate’ and later resource allocation;
Source: ‘Radio Access Networks For UMTS; Principles And Practice’ by Chris John-
son
9.6 Soft Handover

Soft handover is a category of handover procedures where the radio links are added and
deleted in such a manner that the UE always keeps at least one radio link to the UTRAN.
Soft handover is only possible when the source cell and target cell both operate at the same
frequency. Therefore, soft handovers are always intra-frequency handovers. According to
the network topology, we can identify various scenarios. The source cell and the target
cell can:
1. belong to the same Node B (special case of Soft handover, called Softer Handover).
2. belong to two different Node Bs but controlled by the same RNC.

9.6. SOFT HANDOVER 321
3. belong to two different Node Bs and different RNCs & with Iur interface between
the two RNCs.
4. belong to two different Node Bs and different RNCs but without Iur interface be-
tween the two RNCs.
A more detailed description can be found in 3GPP TR 25.832. From the four options
listed above, in the first three cases, a Soft Handover is possible but for the option # 4,
only a Hard Handover is possible.
Figure 9.13: Schematic description of Intra-RNC soft handover: Source 3GPP TR

25.832
Figure 9.13 shows the schematic description of an Intra-RNC Inter-Node B soft handover.
The signalling flow for the same example is illustrated in figure 9.14.
The UE connected to Primary-Scrambling code ‘A’ reports to RNC that it is able to detect
a new cell with scrambling code ‘B’ with acceptable CPICH Ec/No strength. According to
TS 25.331, this situation is called Event 1A7 . The signalling scenario is briefly explained
in the following paragraph.
1. If UE is able to detect a neighboring cell with acceptable signal strength (CPICH

Ec/No), it informs RNC by sending RRC: MEASUREMENT REPORT mes-
sage. The main parameters in this message are scrambling codes and signal strength
of both active set cells and strong monitored cells.
2. Based on the current load in the target cell, RNC’s admission control decides
whether the new ‘radio link’ can be ‘added’ to the active set or not.
7
Definition of event 1A: “P-CPICH of a neighbour cell enters the reporting range.”
Figure 9.14: Intra-RNC soft handover - Radio Link Branch Addition; Source:
‘Radio Access Networks For UMTS; Principles And Practice’ by Chris Johnson
In this example, the SRNC decides to add the radio link from a neigh-
boring cell to the active set. But before that, it needs to do the necessary
arrangements with the new Node B.
2a. Radio Link Setup: When a new DCH is to be set-up, NBAP: RADIO LINK
SETUP REQUEST message is sent to Node B and it responds with the NBAP:
RADIO LINK SETUP RESPONSE message. The new Node B starts UL
reception after this point.
9.7. INTER-RNC HANDOVER WITH IUR INTERFACE 323
2b. Iub Transport Bearer Setup: RNC initiates set-up of Iub Data Transport
bearer using ALCAP protocol using ALCAP: ESTABLISHMENT REQUEST
(ERQ) message. The request for set-up of Iub Data Transport bearer is ac-
knowledged by Node B by sending an ALCAP: ESTABLISHMENT CONFIRM
message.
2c. DCH Frame Synchronization: The Node B and SRNC establish synchro-
nization for the Iub Data Transport Bearer by means of exchange of the ap-
propriate DCH Frame Protocol frames DOWNLINK SYNCHRONIZATION
and UPLINK SYNCHRONIZATION. Then Node B starts DL transmission.
3. New Node B achieves uplink synchronization and notifies SRNC with NBAP: RA-
DIO LINK RESTORE INDICATION message.
4. Finally, SRNC sends an RRC:ACTIVE SET UPDATE message to UE. Using

this message, RNC informs UE about the DL primary scrambling code, DL DPCH
channelization code and the DL DPCH frame offset. This message is sent from the
original active set as well as via the recently added radio link although the UE will
only receive it from the original active set cell.
5. UE concludes the soft handover procedure by sending RRC: Active Set Update
Complete message in UL.
9.7 Inter-RNC Handover with Iur Interface
Figure 9.15: Schematic description of Inter-RNC soft handover: Source 3GPP TR

25.832
Figure 9.15 describes the behaviour of an Inter-RNC Soft Handover. The new radio link
added to the active set belongs to a cell which is controlled by another RNC. In this
scenario, soft handover can take place only if there is an Iur interface between the 2 RNCs
which is capable of carrying user plane data frames. The signalling messages exchanged
between various UTRAN network elements and between UE and UTRAN are shown in
figure 9.16.
Figure 9.16: Inter-RNC soft handover - Radio Link Branch Addition
1. UE transmits RRC: MEASUREMENT REPORT message and informs RNC that

event 1A has triggered. SRNC decides to setup a radio link via a new cell controlled
by another RNC.
9.7. INTER-RNC HANDOVER WITH IUR INTERFACE 325
Radio Link Setup: SRNC requests DRNC for radio resources by sending RN-
SAP: RADIO LINK SETUP REQUEST message. The main parameters
in this message are Cell id, Transport Format Set per DCH, Transport Format
Combination Set, frequency, UL Scrambling code etc. DRNC forwards the
request to the target Node B using NBAP: RADIO LINK SETUP RE-
QUEST message. Then Node B starts the UL reception. Node B allocates
requested resources and informs DRNC about the result in the form of NBAP:
RADIO LINK SETUP RESPONSE message. DRNC, in turn, forwards
RNSAP: RADIO LINK SETUP RESPONSE message to SRNC.
Iub Transport Bearer Setup: Using ALCAP protocol, Iub and Iur data trans-
port bearers are established between the new Node B and DRNC; and between
SRNC and DRNC.
DCH Frame Synchronization: After achieving UL synchronization, Node B no-
tifies DRNC and DRNC informs SRNC about it by sending NBAP/RNSAP:
RADIO LINK RESTORE INDICATION message respectively. SRNC and
new Node B exchange control frames of DCH-Frame Protocol (DCH-FP) and
establish DCH frame synchronization. Then Node B starts DL transmission.
2. After successful co-ordination with Node B and DRNC, the SRNC signals RRC:
ACTIVE SET UPDATE message for Radio Link Addition to UE.
3. UE acknowledges with RRC message RRC:ACTIVE SET UPDATE COM-

PLETE.
9.8 Inter-RNC Handover without Iur Interface

Figure 9.17 shows the schematic description of an Inter-RNC hard handover where the
source cell and the target cell belong to two different RNCs and there is no Iur interface
between them. As we can see, there is a hard switching from ‘Source cell’ to ‘Target cell’.
Even in the area of overlapping between the two cells, UE is connected to only one cell.
Along with handover, the functionality of ‘Serving’ RNC is shifted from source RNC to
target RNC. This procedure is known as SRNS relocation.
Figure 9.17: Schematic description of Inter-RNC Hard handover: Source 3GPP

TR 25.832
The signalling between UE, source RNC, core network and the target RNC is shown in
figure 9.18. In order to simplify the picture, Node Bs and Iub signalling is not shown in
this figure. Let’s break down this procedure in several steps.
STEP 1: For UE, it’s the business as usual. UE detects a neighbouring cell with good
CPICH quality and informs this event to RNC in the form of RRC: MEASURE-
MENT REPORT. In this special case, RNC cannot add the new radio link to the
active set because there is no Iur between the CRNC of source cell and the CRNC
of target cell. Meanwhile, UE keeps on reporting measurement report at regular
periods.
When the target cell’s Ec/No becomes better than the E/No of the source cell by a
predefined margin, RNC decides to perform Hard Handover and SRNS relocation.
Step 2: Since, the 2 RNC’s are not directly connected via Iur, they must communicate
via core network. Source RNC informs core network by sending RANAP: RE-
LOCATION REQUIRED message. Core network forwards this message in the
9.8. INTER-RNC HANDOVER WITHOUT IUR INTERFACE 327
Figure 9.18: Inter-RNC Hard Handover and SRNS Relocation
form of RANAP: RELOCATION REQUEST to the target RNC. These steps

are quite clearly shown in figure 9.18.
Finally, the source RNC receives a RANAP: RELOCATION COMMAND
from the core network, which shows that the target RNC has prepared itself and
the target Node B for the hard handover procedure.
Step 3: Source RNC sends a RRC message PHYSICAL CHANNEL RECONFIG-

URATION to the UE.
For illustration, this step can be considered as if RNC is giving a ‘hard handover
command’ to UE.
Step 4: In response, UE changes the configuration of physical layer and automatically

starts communicating with the target cell. Target Node B achieves uplink synchro-
nization on the radio interface and informs target RNC about it. At this point, target
RNC informs the core network by sending RANAP: RELOCATION DETECT
message.
Step 5: After establishing the RRC connection with the target RNC and allocation of the
necessary radio resources, UE sends the RRC message PHYSICAL CHANNEL
RECONFIGURATION COMPLETE to the target RNC.
Step 6: As expected, the target RNC informs Core network about the successful handover
and core network, in turn, asks the source RNC to release the Iu Connection for the
UE.
9.9. CS INTER-SYSTEM HANDOVER (3G TO 2G) 329
9.9 CS Inter-System Handover (3G to 2G)

Source:
• 3GPP TR 25.931 ver. 8.0.0 ;‘UTRAN functions, examples on signalling
procedures’
This section is also inspired from the book ‘Radio Access Networks For UMTS ;
Principles And Practice’ by Chris Johnson, where various signalling scenarios
are illustrated with the help of diagrams, signalling traces and elaborative text.
In ‘Let’s Learn 3G in 10 Days’, the author has tried to explain the same
and skipping some details. The advanced readers should refer to the above
mentioned reference to get more details.
Voice is the most important and most popular circuit switched service. It is quite normal
that while using voice service, subscribers will run into geographical areas where 3G cov-
erage is not strong. But fortunately, GSM coverage can be used to avoid this 3G call drop
by carefully planning for a 3G to 2G handover for CS services. 3G to 2G CS ISHO success
rate is a very important key performance indicator of any 3G network. The signalling flow
of this procedure is broken down into two parts shown in figure 9.19 and figure 9.20.
Let us break down the procedure into several phases and discuss them step-by-step.
1. Phase 1: ISHO triggers
2. Phase 2: Compressed Mode measurements for BCCH RSSI
4. Phase 4: Compressed Mode measurements for BSIC verification
6. Phase 6: HO decision
7. Phase 7: Signalling between SRNC & BSC
8. Phase 8: Communication between UE and GERAN
9. Phase 9: Confirmation about successful HO to RNC
Phase 1: ISHO triggers: There could be several reasons (or triggers) for starting inter-
system measurements e.g., poor P-CPICH RSCP, poor P-CPICH Ec/No, high UL
tx power, high DL radio link power, poor UL quality (or high UL BLER), poor DL
Figure 9.19: Inter System HO Signalling - UTRAN Part; Source: ‘Radio Access
quality etc. Other than these critical reasons, there are some non-critical reasons
as well. For example, service-based handover and load-based handover. Opera-
tors can control the reporting due to each mechanism by RNC parameters. These
parameters are given to user either by SYSTEM INFORMATION (BCCH) or by
RRC: MEASUREMENT CONTROL MESSAGE. In chapter 5, we defined “event
1F which gets triggered whenever the P-CPICH of an active set cell falls below a
certain threshold”. Please refer to section 5.8.3 and figure 5.21.

Whenever a P-CPICH of an active set falls below the parameter defined by RRC:
MEASUREMENT CONTROL, UE sends a RRC: MEASUREMENT REPORT
message to RNC. If there are more cells in the active set, then RNC does not take
any action. When event 1F is triggered for the last active set cell, RNC decides to
prepare UE and Node B for inter-system measurements.
Phase 2: Compressed Mode measurements for BCCH RSSI: It is RNC’s duty to

prepare both Node B and UE for compressed mode measurements in the scheduled
gaps. The compressed mode will not be further explained in this section.
Between Node B & RNC: Using RADIO LINK RECONFIGURATION proce-

dure RNC prepares Node B for compressed mode measurements. This proce-
dure has 3 signalling messages as shown in figure 9.19.
1. NBAP: RADIO LINK RECONFIGURATION PREPARE message con-
tains important parameters related to compressed mode configuration
such as compressed mode method (SF/2, Higher Layer Scheduling or
puncturing), gap length (# slots), gap starting point within a radio frame,
gap pattern etc. With this message up to 3 Transmission Gap Pattern
Sequence (TGPS) can be configured, one for UMTS inter-frequency mea-
surements, one for GSM RSSI measurements and one for GSM BSIC ver-
ification. Each sequence contains its own set of CM parameters.
2. Node B acknowledges the compressed mode parameters by responding
with NBAP: RADIO LINK RECONFIGURATION READY message.
3. Finally, RNC sends NBAP: RADIO LINK RECONFIGURATION COM-
MIT and informs Node B about the Connection Frame Number (CFN),
from which the CM parameters should apply.
Between UE & RNC: The communication between UE an RNC takes place in 2
steps. First, RNC informs the CM parameters and then the parameters related
to GSM RSSI measurements.
1. RRC: PHYSICAL CHANNEL RECONFIGURATION message
is used to inform UE about the compressed mode configuration and the
related parameters. It also contains information about the activation time.
This activation time is exactly the same as RNC sent to Node B in NBAP:
RL Reconfiguration Commit message.
2. RRC: MEASUREMENT CONTROL message is used to configure
GSM RSSI measurements. In this message, RNC specifies whether BSIC
verification is required at this stage or not. In our signalling example,
BSIC verification is not performed at this stage. Each neighbour is identi-
fied using a combination of its Absolute Radio Frequency Channel Number
(ARFCN) and its Base Station Identity Code (BSIC)8 .
8
BSIC = Network Colour Code (NCC) and the Base station Colour Code (BCC).
3. UE acknowledges by sending RRC: PHYSICAL CHANNEL RECONFIG-

URATION message.
Phase 3: Measurement Reports (UE to RNC): After performing measurements on

GSM RAT, UE reports the condition to RNC in the form of RRC: Measurement
Report messages. In our example, we are using periodic measurement reports
at predefined interval. Each report contains information about BCCH RSSI and
non-verified BSIC of 6 strongest GSM neighbours.
Phase 4: Compressed Mode measurements for BSIC verification: There needs to

be some modification in the compressed mode configuration for BSIC verification
which Node B should be aware of.
Between Node B & RNC: Using NBAP: COMPRESSED MODE COM-

MAND RNC instructs Node B to switch from one Transmission Gap Pattern
Sequence (TGPS) to another one. This message has two important parame-
ters:
1. The ‘Compressed Mode Configuration Change CFN’ : This parameter de-
fines the radio frame during which the Node B stops using the active
TGPS.
2. The ‘Transmission Gap CFN’ : This parameter defines the radio frame
in which the new TGPS will become active. ‘New’ means the sequence
defined in this message itself.
Between UE & RNC Well known RRC: Measurement Control massage is used
to switch the compressed mode methods and pattern sequences. RNC may se-
lect the best RF carrier or several RF carriers. In this message, RNC instructs
UE to verify the BSIC of those remaining neighbours which are not explicitly
removed by this message.
Phase 5: Measurement Reports (UE to RNC): After performing measurements on

GSM RAT and verifying the BSIC, UE reports back to SRNC using the same mes-
sage RRC: Measurement Report. Each report contains information about BCCH
RSSI and verified BSIC of the GSM neighbours defined in measurement control
message.
Phase 6: HO decision in SRNC: If a GSM cell is reported by UE whose BSIC has

been verified and whose RSSI level is acceptable, it is considered as a suitable target
cell for inter-system handover.
Phase 7: Signalling between SRNC & BSC: This phase of signalling is illustrated
in figure 9.20. It involves signaling between UTRAN radio controller (RNC) and
GERAN radio controller (BSC). Typically, these 2 are not connected by some direct
interface. Therefore, the communication takes place with the help of core network.
(SRNC 3G-MSC 2G-MSC BSC)

Figure 9.20: UTRAN to GSM HO Signalling - UTRAN & Core Network Part
(source 3GPP TR 25.931)
1. SRNC contacts 3G-MSC by sending RANAP:RELOCATION REQUIRED

message. 3G-MSC forwards this request to 2G-MSC and 2G-MSC in turn
informs BSC.
2. BSC allocates the radio resources in 2G cell and acknowledges the request for
handover by sending BSSMAP: HANDOVER REQUEST ACKNOWLEDGE
message to 2G MSC. 2G-MSC forwards this message to 3G-MSC. 3G-MSC
sends a RANAP: RELOCATION COMMAND and informs RNC about the
2G radio resources (TCH) allocated for this user.
3. RRC: HANDOVER FROM UTRAN COMMAND message allows the user
to leave 3G resources and start accessing 2G radio resources. This message
provides the UE with sufficient information to continue its speech connection
on GSM, such as
• BSIC (BCC & NCC) and BCCH Carrier’s ARFCN
• Time slot #, hopping information, channel configuration, training se-
quence code
• Handver reference number
Phase 8: Communication between UE and GERAN: In the process of synchro-

nizing with the 2G base station, UE transmits ‘Handover Access burst’. In this
burst, UE signals the same handover reference number which was given in the RRC:
HANDOVER FROM UTRAN COMMAND. After this, BSC sends a ‘Handover De-
tect’ message to the 2G-MSC. Finally, UE transmits a Handover Complete message
to 2G-MSC, which then informs the 3G-MSC.
Phase 9: Confirmation about successful HO to SRNC: 3G-MSC sends an RANAP:

Iu Release Command to SRNC to release the radio resources, hardware resources,
Iub and Iu-cs transport resources. These resources are released only after UE has
successfully accessed the 2G resources and call is continuing on GSM.
9.10. PS INTER-SYSTEM HANDOVER (3G TO 2G) 335
9.10 PS Inter-System Handover (3G to 2G)

Source:
• 3GPP TS 23.060 ver. 6.0.0 ;‘General Packet Radio Service (GPRS);
Service description’
CS UTRAN to GERAN handover is commonly called CS ISHO or CS IRAT HO. Similarly

for Packet switched services too, UTRAN to GERAN handover is called PS ISHO or PS
IRAT HO. The signalling for this procedure is quite complicated and a simplified version
of that is illustrated in 9.21. A more detailed description can be found in 3GPP TS 23.060.
According to 3GPP, this mechanism is called“Iu mode to A/Gb mode Inter-SGSN
Change.” Although some vendors support functionality of 2G and 3G SGSN in the same
network element, in our example, it is assumed that 2G SGSN and 3G SGSN are two
different nodes. As we have done with the previous scenarios, we will divide the whole
procedure into several phases. In this discussion, we have 7 phases:
1. Phase 1: 2G Measurement & HO decision by SRNC(UE SRNC)
2. Phase 2: Routing Area Update (UE 2G-SGSN)
3. Phase 3: Core Network Signalling (2G SGSN 3G-SGSN HLR)
4. Phase 4: Updating PDP Context (2G SGSN GGSN)
5. Phase 5: Informing Home PLMN (2G SGSN HLR)
6. Phase 6: Releasing 3G resources ( HLR 3G SGSN RNC)
7. Phase 7: Informing UE about the successful ‘handover’ (2G SGSN UE)
Phase 1: 2G Measurement & HO decision by SRNC(UE SRNC): Just like cir-

cuit switched ISHO, RNC instructs UE to perform the Inter-RAT measurements on
GSM neighbouring cells. UE reports the BCCH RSSI in RRC: MEASUREMENT
REPORT message. In the example shown, periodic measurement is used. Alter-
natively, event triggered measurement could also be used. After finding a suitable
cell, RNC decides for UTRAN to GERAN cell change and informs UE using RRC:
CELL CHANGE ORDER FROM UTRAN message. The purpose of this
message is to transfer a connection between the UE and UTRAN to another radio
access technology (e.g. GSM). This message contains BSIC of the target 2G cell
and the activation time9 .
9
Activation time is optional parameter, default is “now”
Figure 9.21: PS IRAT (Source: 3GPP TS 23.060)
Phase 2: Routing Area Update (UE 2G-SGSN): UE informs 2G-SGSN about

its presence by sending a ROUTING AREA UPDATE REQUEST message.
In this message, UE includes parameters like old RAI, old P-TMSI, Update Type,
MS Network Capability etc. The BSS shall add the Cell Global Identity including
the RAC and LAC of the cell where the message was received before passing the
message to the new 2G-SGSN.
Phase 3: Core Network Signalling (2G-SGSN 3G-SGSN HLR) The 2G-SGSN

has no information about the UE’s MM context and PDP context. Therefore, it
requests for the same from 3G-SGSN. 3G-SGSN requests SRNS Context from the
SRNC. After receiving this message, the SRNC stops sending downlink PDUs to the
9.10. PS INTER-SYSTEM HANDOVER (3G TO 2G) 337
UE and starts buffering. SRNC replies with an SRNS CONTEXT RESPONSE

message. The 3G-SGSN responds with an SGSN Context Response (MM Context,
PDP Contexts) message (optionally, security procedure may be used to authenticate
UE by 2G-SGSN).
Phase 4: Updating PDP Context (2G-SGSN GGSN): The new 2G-SGSN in-
forms GGSN about the changes that have taken place using an UPDATE PDP
CONTEXT REQUEST message. This message contains parameters like new
SGSN Address, TEID, QoS Negotiated, etc.
Phase 5: Informing Home PLMN (2G SGSN HLR): The HLR in the Home-
PLMN is informed about the routing area update when it receives an UPDATE
GPRS LOCATION message from 2G-SGSN. This message contains the IMSI of
subscriber, SGSN address and SGSN number.
Phase 6: Releasing 3G resources ( HLR 3G SGSN RNC): HLR informs the

old 3G-SGSN to delete the subscriber’s data from its register because the user
has been successfully registered in 2G-SGSN. 3G-SGSN instructs SRNC to release
the UTRAN resources reserved for this subscriber by RANAP: IU RELEASE
COMMAND message. When the buffered data has been successfully forwarded,
the SRNS responds with an RANAP: IU RELEASE COMPLETE message.
Phase 7: Informing UE (2G SGSN UE): The new 2G-SGSN responds to the MS
with a ROUTING AREA UPDATE ACCEPT message.
9.11 HSDPA Mobility
Figure 9.22: Inter-Node B serving HS-DSCH cell change (Source 3GPP TS 25.308)
According to 3GPP TS 25.308, “a serving HS-DSCH cell change facili-

tates the transfer of the role of ‘serving HS-DSCH radio link’ from one radio
link belonging to the source HS-DSCH cell to a radio link belonging to the
target HS-DSCH cell”.
This concept has already been discussed in Chapter 7 but we did not analyze the signalling
associated with these procedure. Let’s do it now.
9.11.1 Serving HS-DSCH Cell Change

During an active HSDPA session, the UE can move from one cell to another. It is also
possible that due to other reasons, the Ec/No of a neighbouring cell becomes better than
that of the serving cell. According to design implementation, the serving cell change can
happen in two methods.
HS-DSCH via DCH Channel: In figure 9.23, ‘Option 1’ shows a simple mechanism
where the HSDPA channels are released for the mobility purpose. In the transition
area between ‘A’ and ‘B’, the UE performs a HS-DSCH to DCH channel switching.
The handover takes place between source cell ‘A’ and target cell ‘B’ just like a R99
DCH handover (via soft handover mechanism). After reaching the target cell ‘B’, a
HS-DSCH can be re-allocated to UE from the target cell.
9.11. HSDPA MOBILITY 339
Figure 9.23: Two Methods for HS-DSCH Serving Cell Change
Direct HS-DSCH Serving Cell Change: As depicted in ‘Option 2’ of figure 9.23, dur-
ing the transition period, UE keeps on receiving HSDPA data from source cell ‘A’
but the associated-DCH (A-DCH) channels perform soft handover with a radio link
of target cell ‘B’. The HS-DSCH channel is still scheduled by the Node B which
controls the source cell. This scheme is more efficient than the one explained as
‘Option 1’.
As readers might have guessed, the option 1 is not the most optimized solution. It has
been implemented by infrastructure vendors as an interim solution if their equipments
do not yet support option 2. Now-a-days, almost all networks support direct HS-DSCH
transition. The source and target cells may or may not belong to the same Node B which
gives rise to two separate discussions:
Intra-Node B serving HS-DSCH cell change: In this scenario, the source and the
target cells are two adjacent sectors of the same site (Node B). Therefore, the
unacknowledged data which is buffered at Node B can be transmitted to the user

using new radio link. There is no need to flush the data in MAC-hs buffer. Intra-
Node B SCC has less interruption in service. An example of Intra-Node B SCC is
illustrated in figure 9.24.
Inter-Node B serving HS-DSCH cell change: In contrast to the earlier case, in this
case, the source and the target cells are controlled by two different Node Bs. There-
fore, when the user moves into the new cell, the unacknowledged MAC-hs buffer
data at the old Node B must be flushed and the new Node B must get the same
from RNC. As expected, this causes delay and increases the service interruption
time. This mechanism is depicted in figure 9.25.
1. Intra-Node B Synchronized Serving HS-DSCH Cell Change
Figure 9.24: Intra-Node B Intra RNC Serving HS-DSCH Cell Change
Figure 9.24 illustrates an intra-Node B serving HS-DSCH cell change while keep-
ing the dedicated physical channel configuration and the active set, using the
PHYSICAL CHANNEL RECONFIGURATION procedure. The transition from source to
target HS-DSCH cell is performed in a synchronized manner, i.e. at a given activation time.
This activation time is decided by RNC and informed to Node B using ‘NBAP: RADIO
LINK RECONFIGURATION COMMIT’ and ‘RRC: PHYSICAL CHANNEL RECON-
FIGURATION’.
In this example, it is assumed that HS-DSCH transport channel and radio bearer param-
eters do not change. If transport channel or radio bearer parameters shall be changed,
the serving HS-DSCH cell change would need to be executed by a TRANSPORT CHAN-
NEL RECONFIGURATION procedure or a RADIO BEARER RECONFIGURATION
procedure, respectively.
2. Inter-Node B Synchronized Serving HS-DSCH Cell Change
Figure 9.25: Inter-Node B Intra RNC Serving HS-DSCH Cell Change
In comparison with the intra-Node B case, the major difference is that the source
and the target HS-DSCH cells are controlled by two different Node Bs, MAC-hs in source
and target Node B need to be released and setup, respectively.
The procedure can be studied in the following steps:
Step 1: SRNC establishes a new radio link in the target Node B. This process is completed
using the classical signalling of DCH soft-handover mechanism. As usual, NBAP
and RRC protocols are used by RNC to communicate with Node B and UE.
Step 2: The target Node B starts transmission and reception on associated-dedicated

channels (A-DCH).
Step 3: UE sends a measurement report to SRNC and indicates the ‘change of best cell
or Event 1d’.
Step 4: RNC prepares the source-Node B for a synchronized reconfiguration to be exe-

cuted at a given activation time (using a sequence of 3 NBAP messages).
Step 5: RNC prepares the target-Node B for a synchronized reconfiguration to be exe-

cuted at a given activation time.
Step 6: Finally, SRNC sends a PHYSICAL CHANNEL RECONFIGURATION message

to the UE which indicates the target HS-DSCH cell and the activation time.
Step 7: To conclude, the UE responds with a PHYSICAL CHANNEL RECONFIGU-

RATION COMPLETE message.
If the source cell and the target cell are under the control of 2 different RNCs then the
situation becomes even more complex and more interesting. The implementation very
much depends on the vendor’s support for these advanced procedures.
• If ‘HS-DSCH over Iur ’ is supported and ‘soft HO for A-DCH over Iur ’
is also supported, it is possible to perform a serving HS-DSCH Cell Change to the
cells controlled by DRNC. From UE perspective, there is no difference between
Intra-RNC and Inter-RNC cell change. Since there are 2 RNCs involved, planners
should take extra care while planning the parameters related to neighbouring cells.
• On the contrary, if ‘HS-DSCH over Iur ’ is not supported or not enabled,

then the A-DCH will perform SHO with the target cell of DRNC. After receiving
an RRC: Measurement Report of event 1D, normally SRNC will perform serving
cell change but due to the lack of HS-DSCH support on Iur, a reconfiguration from
HS-DSCH to DCH is performed, and in the target cell UE maintains service on R99
DCH channel.
9.11.2 HS-DSCH Channel Type Switch

In this discussion, our main focus will be on the DL transport channel switch from DCH
to HS-DSCH and vice-versa. Uplink radio bearers can be configured on DCH or E-DCH
transport channels.
DCH to HS-DSCH Switch
A radio bearer reconfiguration from DCH to HS-DSCH can be triggered by various reasons.
Some of them are listed below:
• If a cell that supports HSDPA and allows current RAB combination on HSDPA is
added to active set.
• If the compressed mode measurements triggered a switch from HS-DSCH to DCH
and the handover was not successful, DCH can again be reconfigured to HS-DSCH.
• If earlier HSDPA allocation was not successful due to temporary reasons (e.g., max
number of HSDPA users), and now those reasons are resolved.
• If earlier HSDPA allocation was not successful because Guard Timer was running.
These guard times are used to avoid too frequent channel type switch. When the
guard timer expires, RNC tries to switch DCH to HS-DSCH.
When one of the reasons listed above triggers DCH → HS-DSCH switch then RNC starts
looking for a suitable HS-DSCH target cell. After finding a suitable cell, the RNC reserves
transport resources and RNC internal hardware resources for HS-DSCH. Later radio links,
transport channel and radio bearer are reconfigured. Radio bearer is mapped to HS-DSCH.
After successful reconfiguration, the DCH resources are released and HS-DSCH-specific
measurements are configured in the UE.
HS-DSCH to DCH Switch
A radio bearer reconfiguration from HS-DSCH to DCH can be triggered by various reasons.
Some of them are listed below:
• UE enters a new cell where HSDPA is not enabled.

• If the HSDPA resources in target cell can not be allocated.
• If a new RAB is established and new RAB configuration is not supported on HS-
DSCH.
• If compressed mode measurements are triggered for Inter-frequency and Inter-system
measurements & system does not support CM measurements on HS-DSCH.
HS-DSCH → DCH switch procedure also takes place in 2 phases. First, the RNC and
transport resources are reserved for DCH, radio links, transport channel & radio bearer
are reconfigured and Radio bearer is mapped to DCH. In the second phase, resources for
HS-DSCH are released & DCH-specific measurements are configured to the UE.
9.11.3 HS-DSCH IFHO and ISHO

The triggers for Inter-frequency handover and Inter-system handover are the same as for
R99 DCH channels. HSDPA does not bring any new triggers for the IFHO or ISHO. For
a quick reminder, some of them are listed below:
• CPICH RSCP becomes weaker than an absolute threshold (Event 1F).
• CPICH Ec/No becomes weaker than an absolute threshold (Event 1F).
• UE transmission power is higher than an absolute threshold (Event 6A).
• UL quality is very poor.
• DL DPCH Radio link power is very high.
• other load based and service based triggers.
The functionality of Inter-frequency handover and Inter-system handover strongly depends

on the 2 following implementation alternatives.
If Compressed Mode for IFHO /ISHO not supported: If RNC features do not al-
low compressed mode measurements during the HS-DSCH session, HS-DSCH chan-
nel will be switched to DCH and IF-measurements/IS-measurements take place just
like in the Rel-99 case.
This method will certainly reduce the HSDPA throughput during measurement
phase. It will also cause extra delay due to unnecessary channel switching.
If Compressed Mode for IFHO/ISHO is supported: If RNC supports compressed

mode measurements during HS-DSCH configuration, it orders compressed mode on
HSDPA so that IF/IS-measurements can be performed on HSDPA without channel
type switching to DCH.
As expected, this alternative does not reduce the user throughput and it causes less
delays which speeds up the handover execution time.
9.12. HSUPA MOBILITY 345
9.12 HSUPA Mobility
9.12.1 E-DCH Soft Handover

When an E-DCH transport channel is configured for a user, its mobility is supported by
soft-handover. The measurement events related to R99 DCH soft handover signalling,
e.g., Event 1A, 1B, 1C, etc. are also valid for HSUPA. In special circumstances, it is
possible to have different E-DCH active set and DCH active set. Although the concept
of handover is same but it should be possible to keep different parameter sets for intra-
frequency measurements for DCH and E-DCH soft handover. Operators define different
parameter sets and assign one set each for various service. For example, operators can
keep different set of parameters to control soft handover procedure for real time (RT)
services, for non-real time (NRT) services, for HSDPA services, and for HSPA services.
In E-DCH active set there is one ‘Serving’ E-DCH active set and (one or more) ‘non-
serving’ E-DCH cell(s). A detailed description of these terms is available in Chapter
8.
Serving E-DCH RLS: The serving E-DCH Radio Link Set contains a serving E-DCH
cell and non-serving E-DCH cell(s) under the same Node B.
Non-serving E-DCH RLS: The non-serving Radio Link Set contains those non-serving
active set cells that belong to another Node B.
9.12.2 E-DCH Serving Cell Change

E-DCH serving cell is always the same as HS-DSCH cell change. The triggering of HS-
DSCH serving cell change and the selection of HS-DSCH serving cell described in the
previous section are also valid if the UL MAC-d flows are configured on E-DCH.
9.12.3 E-DCH Channel Type Switch

In this discussion, our main focus will be on UL transport channel switch from E-DCH to
DCH and vice-versa.
• If UL radio bearers are configured on E-DCH, DL must be HS-DSCH.
• If the UL is on DCH, then DL can be configured on either HS-DSCH or DCH

transport channels.
DCH to E-DCH Switch
The mechanism of channel type switch from DCH to E-DCH is a tool by which E-DCH
can be allocated if it was not possible in the initial channel allocation. There are several
triggers for this transition. Some of them are listed below:
• Channel type switching if the UE enters an HSPA cell.

• When DL DCH is reconfigured to HS-DSCH then RNC tries of the usage of E-DCH
is possible. If possible, then E-DCH is preferred and a transition from DCH →
E-DCH is started.
• When a DCH/HS-DSCH is configured and UE performs HS-DSCH serving cell
change, the RNC checks whether a DCH to E-DCH channel type switch is needed.
• Whenever an E-DCH → DCH channel type switch is performed, a guard timer is
set. When this timer expires, it triggers a DCH → E-DCH channel type switch.
• If at the initial allocation, DCH is selected because E-DCH-capable cell is very
weak compared to a non-E-DCH capable cell. An E-DCH active set can change to
acceptable if the cell not in E-DCH active set becomes ‘weak enough’ or is removed
from the DCH active set. Weak enough is defined relative to the serving HS-DSCH
cell.
• If initial E-DCH allocation fails, RNC can also periodically check if the usage of
E-DCH transport channel has become possible now. This is possible due to varying
cell load conditions.
There are several possibilities for UL/DL combinations for DCH → E-DCH.
1. DCH/DCH → HS-DSCH/E-DCH
2. HS-DSCH/DCH → HS-DSCH/E-DCH
E-DCH to DCH Switch
Channel type switch from E-DCH → DCH is required when E-DCH channel cannot be
maintained or its usage become inefficient. There are several triggers for this switch. Some
of them are:
• When the DL HS-DSCH is switched to DCH, it becomes impossible to maintain

E-DCH in UL. Therefore, a switch from E-DCH rightarrow DCH is required.
• When a HS-DSCH serving cell change is triggered, RNC checks whether the target
HS-DSCH serving cell supports E-DCH and whether the proposed E-DCH active
set is acceptable. If any of these 2 checks fails, the channel type switch from E-DCH
to DCH cannot be avoided.
• If E-DCH is used and DCH active set contains some cell(s) which are not in E-DCH
active set. If any DCH active set cell becomes stronger than the serving E-DCH cell
by a predefined margin, the E-DCH active set becomes unacceptable and a switch
from E-DCH to DCH is necessary.
• During HS-DSCH/E-DCH operation if UE moves to a cell where HSDPA or HSUPA

is not supported, the following channel switch are possible.
1. HS-DSCH/E-DCH → HS-DSCH/DCH
2. HS-DSCH/E-DCH → DCH/DCH
9.12.4 E-DCH IFHO and ISHO

The discussion about E-DCH inter-frequency handover and inter-system handover is very
similar to the one for HSDPA IF/IS HO (see section 9.11.3). Once again, the same
intra-frequency measurement events are used to trigger these hard handovers. The mea-
surements are performed in compressed mode which gives rise to 3 possibilities.
Compressed Mode not supported for HSDPA & HSUPA: If RNC features do not
allow compressed mode measurements during HS-DSCH/E-DCH session HS-DSCH/E-
DCH will be switched to DCH/DCH and IF-measurements/IS-measurements take
place just like in R99 case.
Compressed Mode for HSDPA is supported but not for HSUPA: A channel type
switch from HS-DSCH/E-DCH → HS-DSCH/DCH is performed and then com-
pressed mode measurements are carried out as usual.
Compressed Mode is supported for both HSDPA & HSUPA: If RNC supports
compressed mode measurements during HS-DSCH/E-DCH configuration, measure-
ments can be performed without channel type switching to DCH.
Copyright Notices

Text in section 9.10 on page 335 Section 6.13.2 of 3GPP TS 23.060 v 6.0.0.
⃝2003.
Figure 9.22 on page 338 Figure 9.1-1 of 3GPP TS 25.308 v 6.3.0.

⃝2004.
c TM
Figure 9.1 on page 297 Figure 8.1.3-1 of 3GPP TS 25.331 v 6.9.0.

Figure 9.3 on page 299 Figure 8.2.2-1 of 3GPP TS 25.331 v 6.9.0.
Figure 9.3 on page 299 Figure 8.2.2.3 of 3GPP TS 25.331 v 6.9.0.
⃝2006.
c TM
Text in section RRC Connection Section 7.3.1 of 3GPP TR 25.931 v 8.0.0.

on Dedicated Channels on page
302
Figure 9.5 on page 301 Figure 7 of 3GPP TR 25.931 v 8.0.0.
Figure 9.7 on page 305 Figure 8b of 3GPP TR 25.931 v 8.0.0.
⃝2008. 3GPP TSs and TRs are the property of ARIB, ATIS, ETSI, CCSA,
c TM
BIBLIOGRAPHY
[1] 3GPP TR 21.905 ver. 8.0.0 ;‘Vocabulary for 3GPP Specifications’
[2] 3GPP TS 23.060 ver. 6.0.0 ;‘General Packet Radio Service (GPRS); Service descrip-
tion’
description;’
[5] 3GPP TS 25.319 ver. 7.0.0 ;‘High Speed Uplink Packet Access (HSUPA); Overall
description’
description;’
& Sons.
350
CHAPTER
10
SELF TEST
In the 9 modules of this book, we learnt the essential concepts about UMTS and HSPA.
In this final module, we should put ourself to a self-test and examine our understanding.
Therefore, I request the readers to try and independently answer these questions and solve
the exercises given in this module. You are free to refer back to the previous modules but
the only condition is ‘do it yourself ’.
10.1 Module 1
Question 1.1: Arrange the following technologies in the chronological order of
their releases.
1. IMS
2. HSCSD
3. HSUPA
4. TD-SCDMA
5. GPRS
Correct Answer:
1.
351
352 CHAPTER 10. SELF TEST
2.
3.
4.
5.
Question 1.2: In one or two words, explain the highlights of each 3GPP re-
lease. Write your answers in Table 10.1.
3GPP Release Main Features or Improvements

R99
REL-4
REL-5 1.
2.
REL-6
REL-8
Table 10.1: Exercise 1.2: Highlights of few 3GPP releases
Question 1.3: Which of the following SDOs1 are 3GPP Organizational Part-
ners?
• GSMA
• ETSI
• TIA (USA)
• TTC (JAPAN)
• ATM Forum
• WiMAX Forum
• CCSA (China)
• ARIB (Japan)
• ATIS (USA)
• NGMN Alliance
Correct Answer:
1.
2.
3.
1
Standards Development Organizations
10.1. MODULE 1 353
4.
5.
6.
Question 1.4: According to REL-6, the peak bitrates of HSDPA and HSUPA
are:
• DL 2 Mbps and UL 2 Mbps

• DL 7.2 Mbps and UL 2 Mbps
• DL 14.4 Mbps and UL 2 Mbps
• DL 14.4 Mbps and UL 5.8 Mbps
• DL 21 Mbps and UL 5.8 Mbps
• DL 42 Mbps and UL 11 Mbps
Correct Answer:
Question 1.5: “All-IP” solution means that we do not need to depend on the
legacy circuit switched nodes, e.g., MSC. In history, which was the first
technology & 3GPP release allowed this scheme?
Technology: Pick one from the following options

• GPRS
• UMTS
• HSPA
• IMS
• HSPA+
3GPP release: Pick one from the following options
• R4
• R5
• R6
• R7
• R99
Correct Answer:
• Technology:
• Release:
10.2 Module 2
Question 2.1: According to the original GSM network architecture, the fol-
lowing subsystems are defined.
Identify the wrong options from the list of subsystems mentioned below.
• Mobile station
• External networks
• Circuit Switched Core Network (Switching Subsystem)
• Base Station Subsystem
• Packet Switched Core Network (Packet Core)
Correct Answer:
Question 2.2: While in roaming, which network elements are always located
in Home PLMN?
Choose 2 options from the following list
• MSC
• BSC
• GMSC
• Transcoding Unit (TRAU)
• Home Location Register (HLR)
Correct Answer:
•
•
Question 2.3: While in roaming, which network elements are always located
in Visited PLMN?
Choose 3 options from the following list
• MSC
• BSC
• GMSC
• Visitor Location Register
• Home Location Register (HLR)
10.2. MODULE 2 355
Correct Answer:
•
•
•
Question 2.4: In GPRS roaming scenario, the SGSN of Visited PLMN and
GGSN of Home PLMN are connected via an IP backbone network known
as:
Correct Answer:
Question 2.5: In 2G and 3G, the following interfaces can be considered as

“equivalent” interfaces for understanding the 3G network.
Name of 2G interface Equivalent Interface

in 3G
1. A i. Iu-PS
2. Abis ii. Iu-CS
3. Gb iii. Iub
Table 10.2: Exercise 2.5: Match the 2G & 3G interfaces
Correct Answer:
• A:
• Abis:
• Gb:
Question 2.6: An IMS subscriber of PLMN ‘A’ is roaming in the PLMN ‘B’.
While inviting another IMS subscriber for a multimedia session, the ‘SIP
INVITE’ message will be sent to which SIP server first?
• Interrogating-CSCF of PLMN ‘A’

• Interrogating-CSCF of PLMN ‘B’
• Proxy-CSCF of PLMN ‘A’
• Proxy-CSCF of PLMN ‘B’
• Serving-CSCF of PLMN ‘A’
• Serving-CSCF of PLMN ‘B’
Correct Answer:
•
10.3. MODULE 3 357
10.3 Module 3
Question 3.1: Identify the UL & DL frequency range used in UTRAN FDD
band I.
Use table 10.3 and choose the right frequency ranges.
Uplink Freq. Downlink Freq.

832 - 862 MHz 791 - 821 MHz
1710-1785 MHz 1805-1880 MHz
1920-1980 MHz 2110 -2170 MHz
1710-1755 MHz 2110-2155 MHz
1850 -1910 MHz 1930 -1990 MHz
1710-1770 MHz 2110-2170 MHz
Table 10.3: Exercise 3.1: Identify UTRAN FDD Band I
Correct Answer:
Question 3.2: The code which provides processing gain is called:
• Gold Code
• Long Code
• Pseudo-Random Noise
• Channelization code
• Scrambling Code
Correct Answer:
Question 3.3: The spreading principle allows us to get variable bit rate by
using variable spreading factors.
Choose the 2 correct statements from the following list:
1. As SF increases, the required transmission power decreases.

2. As SF increases, the required transmission power also increases.
3. As SF increases, the service bit rate decreases.
4. As SF increases, the service bit rate also increases.
Correct Answer:
•
•
Question 3.4: How many scrambling codes are available?

Choose the correct answer from the following list:
1. Millions of codes in UL & DL

2. 256 codes in UL & DL
3. 512 in UL & DL
4. Millions in UL and 512 in DL
Correct Answer:
Question 3.5: 512 DL scrambling codes are organized into 64 SC groups of 8

codes. If two WCDMA cells belong to the same group, which channel
will broadcast the identical information in the 2 cells:
Choose the correct answer from the following list
1. DL DPCH
2. P-CCPCH ( Broadcast channel)
3. P-SCH & S-SCH (Pri- & Sec-Synchronization channel)
4. P-CPICH (Primary Common Pilot channel)
Correct Answer:
Question 3.6: Two Voice users in the same WCDMA cells must use different
combination of channelization and scrambling codes.
From the list below, select the two codes that must be different?
1. Channelization Codes in UL
2. Channelization Codes in DL
3. Scrambling Codes in UL
4. Scrambling Codes in DL
Correct Answer:
•
•
10.3. MODULE 3 359
Question 3.7: The physical layer process which tries to convert a ‘burst of
errors’ into ‘random errors’ is called:
1. Segmentation
2. CRC attachment
3. Interleaving
4. Turbo decoding
Correct Answer:
•
10.4 Module 4
Question 4.1: The mapping of logical channels onto transport channels is
performed by:
1. RLC layer in Node B

2. MAC layer in Node B
3. RLC layer in RNC
4. MAC layer in RNC
5. RRC layer in RNC
Correct Answer:
Question 4.2: Non-real time (NRT) service with very small bit rate can be
transported on the following channels:
Choose the 2 options.
1. P-CCPCH (BCH)
2. PRACH (RACH)
3. DPCH (DCH)
4. PCCH (PCH)
5. S-CCPCH (FACH)
Correct Answer:
•
•
Question 4.3: Some channels are unidirectional (either in UL or in DL but not

both) and some channels are bidirectional.
Identify the transport channel which is bidirectional.
1. BCH
2. PCH
3. FACH
4. RACH
5. DCH
Correct Answer:
10.4. MODULE 4 361
Question 4.4: Just before decoding S-CCPCH and reading the paging request,
UE must read following physical channel.
Select one answer from the following list:
1. RACH
2. DPCH
3. PICH
4. FACH
5. CPICH
Correct Answer:
Question 4.5: For the same Spreading Factor (SF), the UL and DL bit rates
are different.
What is the reason for it?
1. Channel coding rate is different in UL & DL

2. Modulation Scheme is different in UL & DL
3. UL & DL use two different types of Spreading codes
4. The rate difference is due to scrambling code
Correct Answer:
Question 4.6: In Cell Search procedure, select the order in which the following
physical channels are used by UE.
1. P-CPICH
2. P-SCH
3. S-CCPCH
4. P-CCPCH
5. S-SCH
6. E-HICH
7. DPCH
Correct Answer:
1.
2.
3.
4.
10.5. MODULE 5 363
10.5 Module 5
Question 5.1: Which RRM algorithms makes sure that the interference in the
cell remains under controllable limits?
Choose 2 answers:
1. Code Allocation
2. BTS Site Manager
3. Admission Control
4. Congestion Control
5. Handover Control
6. Power Control
Correct Answer:
•
•
Question 5.2: In CDMA networks, the UL cell load is measured in reference

to the:
1. Max. UL Power of UE
2. Max. DL power of Node B
3. UL noise floor when the cell is unloaded
4. Power received at the receiver of UE
5. UE receiver’s sensitivity
Correct Answer:
Question 5.3: When does the admission control algorithm in UMTS get in-
voked?
Name any 3 scenarios.
Correct Answer:
•
•
•
Question 5.4: In RF optimization, we often hear about the code congestion

or code blocking.
Which codes are scarce resources and often cause blocking?
1. DL Scrambling Code
2. DL Channelization Code
3. UL Scrambling code
4. UL Channelization Code
Correct Answer:
Question 5.5: Which RRC Connected mode states are the power saving “stand
by” states?
Choose only one answer.
1. CELL DCH
2. CELL FACH
3. CELL PCH only
4. CELL PCH & URA PCH
Correct Answer:
Question 5.6: Which statements about Open Loop Power Control (OLPC) are
true?
Choose only two correct statements.
1. Open Loop Power Control (OLPC) works on PRACH channel.

2. Node B sends feedback so that UE can adjust its power of RACH preambles.
3. OLPC is also used on DL physical channels.
4. OLPC suggests that initial preamble transmit power should be directly pro-
portional to the path-loss.
5. OLPC takes place 1500 times in one second.
Correct Answer:
•
10.5. MODULE 5 365
Question 5.7: Which statements about Inner Loop & Outer Loop Power Con-
trol are true?
Choose 5 correct statements.
1. Inner Loop & Outer Loop PC work in parallel.

2. Inner Loop PC tries to adjust the Tx power in order to reach the desired SIR
(Target SIR).
3. Outer loop PC tries to adjust the Target SIR in order to reach the desired
BLER (Target BLER).
4. Inner loop takes place between UE and RNC.
5. Outer loop takes place between Node B and UE.
6. Inner loop takes place between Node B and UE.
7. Outer loop takes place between Node B and RNC.
Correct Answer:
•
•
•
•
•
Question 5.8: In response to a PRACH preamble, if UE received no positive

or negative acquisition indicator (AI ̸= +1 nor -1), UE will send the next
preamble with higher power. Will the signature used in next preamble
be the same as original?
Choose 1 correct statements.
1. Same signature will be used.

2. A new signature will be randomly selected.
Correct Answer:
Question 5.9: Which of the following events will trigger an Inter-frequency or

Inter-System HO from an UTRAN cell?
Choose only 1 correct option.
1. Event 1A
2. Event 1B
3. Event 1C
4. Event 1D
5. Event 1E
6. Event 1F
Correct Answer:
Question 5.10: Which event is used to inform RNC that compressed mode
measurements can be aborted because UE is again in suitable 3G cover-
age?
1. Event 1A
2. Event 1B
3. Event 1C
4. Event 1D
5. Event 1E
6. Event 1F
Correct Answer:
Question 5.11: Which compressed mode method suits the requirements of

real-time services like Voice call?
1. SF-halving (SF/2) method

2. Higher Layer Scheduling Method (HLS)
3. Puncturing
Correct Answer:
•
10.6. MODULE 6 367
10.6 Module 6
Question 6.1: Access Stratum Protocol for the signalling between UE and
RNC is known as:
Choose 1 answer:
1. NBAP
2. RANAP
3. RRC
4. ATM
5. SS7
6. GTP
Correct Answer:
Question 6.2: Access Stratum Protocol for the signalling between RNC and
Core Network is known as
Choose 1 answer:
1. NBAP
2. RANAP
3. RRC
4. ATM
5. SS7
6. GTP
Correct Answer:
Question 6.3: Scope of Radio Access Bearer (RAB) is to define the Quality of
Service between:
Choose 1 answer:
1. UE & Node B
2. UE & RNC
3. UE & Core Network
4. UE & External Server
Correct Answer:
Question 6.4: Which protocols can be described as NAS protocols:

Choose 1 answer:
1. NBAP
2. RANAP
3. RRC
4. Mobility Management
5. SS7
6. GTP
Correct Answer:
Question 6.5: Which radio protocol is used in IP-based user plane and per-
forms IP header compression?
Choose 1 answer:
1. NBAP
2. RANAP
3. RRC
4. Mobility Management
5. PDCP
6. BMC
Correct Answer:
Question 6.6: RRC is perhaps the most important protocol in UTRAN.

List at least 4 functions of RRC protocol.
Correct Answer:
1.
2.
3.
4.
10.7. MODULE 7 369
10.7 Module 7
Question 7.1: According to Release 6, the following modulations can be used
for DL HSDPA transmission.
Choose only 1 answer:
1. QPSK only
2. QPSK & BPSK
3. QPSK & 16QAM
4. QPSK, 16QAM & 64QAM
Correct Answer:
Question 7.2: RNC forwards the buffered MAC-d PDUs to Node B in a con-
trolled manner. This procedure is called:
1. Transmission Control
2. Data Stream Control
3. Overload Control
4. Flow Control
Correct Answer:
Question 7.3: According to the CQI tables ‘A’ and ‘G’, at which CQI, the
modulation is switched to a better modulation scheme?
1. 10 & 18
2. 15 & 23
3. 16 & 26
4. 16 & 21
Correct Answer:
Question 7.4: From network operations viewpoint, which re-transmissions are

more expensive?
1. MAC layer retransmission

2. RLC layer retransmission

3. RRC layer retransmission
Correct Answer:
Question 7.5: Very smart re-transmission techniques are used in HSDPA (&
HSUPA):
Name the two H-ARQ schemes defined for HSDPA.
Correct Answer:
•
•
Question 7.6: Match the name of HSDPA-specific physical channel with their
spreading factor.
Name of Physical Spreading Factor

Channel
1. HS-DPCCH i. 16
2. HS-SCCH ii. 256
3. HS-PDSCH iii. 128
Table 10.4: Exercise 7.6: Match the SF to the channel name
Correct Answer:
1. HS-DPCCH:
2. HS-SCCH:
3. HS-PDSCH:
Question 7.7: In Rel-6 onwards, why 3GPP recommends using F-DPCH in-
stead of DL A-DCH?
Choose only 1 correct answer:
1. F-DPCH uses smart power control.

2. F-DPCH uses 64QAM modulation and improves the bit rates of associated
channels.
10.7. MODULE 7 371
3. F-DPCH allows multiplexing several HSDPA users on one code and solves code
congestion.
4. F-DPCH has no benefit compared to DL A-DCH.
Correct Answer:
Question 7.8: Arrange the following HSDPA UEs according to their peak bit
rate capabilities.
1. 10
2. 12
3. 6
4. 14
5. 16
Correct Answer:
1.
2.
3.
4.
5.
10.8 Module 8
Question 8.1: A HSUPA-capable device can use the following combinations
of UL & DL transport channels for sending & receiving user data.
Fill your answers in table 10.5:
Correct Answer:
# UL Transport Channel DL Transport Channel

1.
2.
3.
4.
Table 10.5: Exercise 8.1: Transport channel for carrying DTCH logical channel in
UL & DL
Question 8.2: In an HSUPA-capable UE, the user data is processed by three

MAC layers before being delivered to the physical layer.
Choose the correct sequence. (Note! The question is based on the processing on the
UE side).
1. MAC-e → MAC-es → MAC-d

2. MAC-d → MAC-es → MAC-e
3. MAC-d → MAC-e → MAC-es
Correct Answer:
1.
Question 8.3: In Table 10.6, match the transport channel with their corre-
sponding TTI lengths.
Transport Channel TTI length
1. DCH i. 2 ms
2. E-DCH ii. 10 to 80 ms
3. HS-PDSCH iii. 2 ms & 10 ms
Table 10.6: Exercise 8.3: Match the TTI length to the channel name
Correct Answer:
10.8. MODULE 8 373
1. DCH
2. E-DCH
3. HS-PDSCH
Question 8.4: The set of those cells which are in E-DCH Active Set but not
controlled by the same Node B as the serving E-DCH serving cell are
called:
1. Secondary Cells
2. Interfering Cells
3. Non-serving Radio Link Set Cells
4. E-DCH Diversity Cells
Correct Answer:
Question 8.5: How many E-DCH users can be present in a cell where only
one channelization code is reserved for E-RGCH & E-HICH channels?
Hint! There are only 40 Signature sequences defined by 3GPP.
1. 10
2. 20
3. 40
4. 72
Correct Answer:
Question 8.6: How many E-DPDCH physical channels must be transmitted

from a UE to achieve the peak bit rate of 5.76 Mbps?
1. 2
2. 4
3. 6
4. 8
5. 16
Correct Answer:
•
Question 8.7: The Absolute Grant channel carries a Grant value which de-
scribes the power of E-DPDCH in reference to:
1. DPCCH Power
2. DPDCH Power
3. HS-DPCCH power
4. E-DPCCH Power
5. Thermal Noise Power
Correct Answer:
Question 8.8: In a cell, the E-DCH Relative Granch Channel (E-RGCH) oc-
cupies a single 2 ms sub-frame:
Choose one correct statement from the following options:
1. This cell belongs to Serving E-DCH Radio Link Set

2. This cell belongs to Non-serving E-DCH Radio Link Set
3. Cannot be answered because information provided is not enough
4. None of the above
Correct Answer:
Question 8.9: In a cell, the E-DCH Relative Granch Channel (E-RGCH) oc-
cupies four consecutive sub-frames:
1. This cell belongs to Serving E-DCH Radio Link Set

2. This cell belongs to Non-serving E-DCH Radio Link Set
3. Cannot be answered because information provided is not enough
4. None of the above
Correct Answer:
Question 8.10: In a cell, the E-DCH Relative Granch Channel (E-RGCH)

occupies a five consecutive sub-frames:
10.8. MODULE 8 375
1. This cell belongs to Serving E-DCH Radio Link Set & E-DCH TTI =
2ms.
2. This cell belongs to Non-serving E-DCH Radio Link Set & E-DCH TTI
= 10 ms.
3. This cell belongs to Non-serving E-DCH Radio Link Set & but TTI
cannot be determined from the information provided.
4. This cell belongs to Serving E-DCH Radio Link Set & but TTI cannot be
determined from the information provided.
Correct Answer:
Question 8.11: In a cell, for E-DCH H-ARQ Indication Channel (E-HICH)

Negative Acknowledgement (NACK) is coded as ‘-1’:
1. This cell belongs to Serving E-DCH Radio Link Set.

2. This cell belongs to Non-serving E-DCH Radio Link Set.
3. It cannot be determined from the information provided.
4. None of above.
Correct Answer:
•
10.9 Module 9
Question 9.1: An NAS signalling connection between UE and Core Network
is composed of 2 parts.
Choose the two items from the following list which constitute an NAS signalling
Connection.
1. RRC Connection
2. Radio Access Bearer
3. Iu Connection
4. GTP tunnel
5. Active Set
Correct Answer:
•
•
Question 9.2: RRC Connection Establishment pushes a UE from RRC IDLE

mode to RRC Connected Mode. From IDLE Mode, UE can enter the following
states of connected mode.(Choose 2 answers):
1. CELL PCH
2. CELL DCH
3. CELL FACH
4. URA PCH
Correct Answer:
•
•
Question 9.3: The procedure of getting a UE registered in SGSN is known as:

1. PS REGISTRATION
2. PS SIGNUP
3. GPRS ATTACH
4. PDP Context Setup
Correct Answer:
10.9. MODULE 9 377
Question 9.4: The procedure by which a UE establishes a connection to some

external packet data network is known as:
1. PS CONNECT
2. IP packet forwarding
3. PDP Context Activation
4. Cell Reselection
5. DIAMETER Routing
Correct Answer:
Question 9.5: Which statement is true for HSDPA and HSUPA mobility:
Choose only 2 answers:
1. HSDPA supports Soft Handover but HSUPA does not.

2. Both HSDPA & HSUPA support Soft Handover.
3. HSDPA supports Hard Handover known as Serving Cell Change.
4. HSUPA supports Soft Handover.
5. In HSUPA, when a user moves to a new cell, it performs cell reselection.
Correct Answer:
•
•
INDEX
16QAM, 21, 207, 214, 231, 232, 247 BSS, 27

3GPP Releases, 18, 20, 22 BTS, 28
R99 to REL-10, 19
3rd Generation Partnership Project (3GPP), Call State Control Function (CSCF), 55
14 Interrogating - , 56
3rd Generation Partnership Project 2 (3GPP2), Proxy - , 56
15 Serving - , 56
4 Pulse Amplitude Modulation (4PAM, 253, CAMEL, 33
261, 262 CCCH, 85, 93, 197, 302
64QAM, 21, 22, 207, 214, 230–232, 237 Cell search, 109
CELL DCH, 138
, 20, 39 Cell DCH, 139
Absolute grant, 264, 268 CELL FACH, 138
Acquisition indication channel (AICH), 76, Cell FACH, 139–143
99, 102, 146 CELL PCH, 138
Adaptive Modulation and Coding, 211, 247 Cell PCH, 139, 142, 143
Admission control, 45, 118, 119, 126, 129, Channel Quality Indicator (CQI), 137, 206,
130, 159 207, 213–216, 224, 226, 228
ALCAP, 172, 174, 304, 323 Channelization code, 72, 73, 88, 98, 117,
AMPS, 4 133, 134, 232, 234, 262, 267, 291,
Authentication Center, 31 292, 303
compressed mode, 166
Background class, 178 Conversational class, 177
Base Station Subsystem, 26 Core Network, 26
BCCH, 84, 85, 87, 99 CTCH, 85
Binary Phase Shift Keying (BPSK), 79, 247,
253, 261, 262, 264 DCCH, 85, 250, 251, 297, 302, 304, 309
378
INDEX 379
DECT, 17 High Speed Circuit Switched Data (HSCSD),

Dedicated physical channel for HSDPA, 134, 8
226, 290 High Speed Downlink Shared Channel, 232
DTCH, 85, 86, 93, 135, 250, 251, 309 High Speed-Physical Downlink Shared Chan-
Dual-Carrier HSDPA, 212 nel, 228, 229, 232, 292
Dual-Carrier HSUPA, 22, 253 HSDPA, 19–22, 54, 68, 83, 111, 118, 134,
135, 137, 204, 205, 209, 211, 213,
E-DCH Absolute Grant Channel (E-AGCH), 221, 224–226, 245–248, 251, 273, 292
264, 268, 277, 292 HSPA, 295
E-DCH Hybrid-ARQ Indication Channel (E- HSUPA, 21, 83, 113, 118, 137, 206, 207, 245,
HICH), 267, 268, 270, 274, 281, 282, 247, 248, 251, 253, 254, 292
292
E-DCH Relative Grant Channel (E-RGCH), IMEI, 27, 31
266–268, 274, 277, 292 IMSI, 27
E-DCH Transport Format Combination In- IMT-2000, 66
dicator (E-TFCI), 263 Interactive class, 178
EIR, 31 IP Multimedia Subsystem (IMS), 55
Enhanced Cell FACH, 21 IS-95, 6
Enhanced Data rates for GSM Evolution (EDGE),
Macro Diversity Combining, 157
9
MC-CDMA or CDMA2000, 17
Event
MDC, 157
1A, 158
Medium Access Control (MAC), 86
1B, 159
Mobile Station, 26
1C, 160
MSISDN, 27
1E, 163
1F, 162 Open Loop Power Control, 93
2A-2F, 164
3A-3D, 165 P-CPICH, 90
PCCH, 85, 88
First Generation (1G), 4 Physical Channels, 88
Frame synchronization, 109 Physical layer, 89
Pilot bits, 154
Gateway GPRS Support Node, 39, 41, 58 Primary Synchronization Codes (PSC), 95
General Packet Radio Service (GPRS), 9
GMSC, 29 Radio Access Bearer, 296
GSM, 5 Radio Bearer, 296
Radio Link, 296
Handover, 28, 118, 154 Radio Network Temporary Identity
Hard, 47, 155 Cell, C-RNTI, 303
Inter-frequency, 156 E-DCH, E-RNTI, 264
Inter-System, 156 HS-DSCH, H-RNTI, 231
Intra-frequency, 155 UTRAN, U-RNTI, 303
Soft, 48, 155 Radio Resource Management (RRM), 117
Softer, 155 RRC Connection, 296
380 INDEX
RRM, 118, 121–123, 126, 133, 134, 144, 155,

259
Scrambling code, 73, 75, 76, 79, 88, 96, 98,

109, 110, 117, 125, 132–134, 289,
303, 304, 325
scrambling code, 79
Scrambling Code Group, 96
Scrambling code group, 76
Second Generation (2G), 5
Secondary Synchronization Codes (SSC), 96
Serving GPRS Support Node, 37, 38, 41, 58
serving HS-DSCH cell, 239
Shared Control Channel for HSDPA, 225,
227, 230–232, 292
SIB, 99
SIM, 27
Slot synchronization, 109
Streaming class, 178
Switching Subsystem, 26
TFCI, 106
Third generation (3G), 11
Traffic Class, 177
Transport Format Combination Indicator (TFCI),
107
UE Categories
E-DCH, 251, 252
HS-DSCH, 206, 214
URA PCH, 138, 140, 141
UTRA FDD, 17
UTRA TDD, 17
UTRAN, 82
VLR, 29
WiMAX, 17
WRC-92, 66
Zeroth Generation (0G), 4

LetsLearn3Gin10Days KamalVij

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

LetsLearn3Gin10Days KamalVij

Uploaded by

Copyright:

Available Formats

Let’s Learn

EXPLOIT THE EVOLUTION

Written by Kamal Vij

Kamal Vij received a B.Engg. degree in Electronics & Com-

Kamal Vij is now a technical trainer and private consultant.

• H.Holma and A. Toskala, ‘WCDMA for UMTS’ , 5th Edition, John

I would like to thank ‘Zorba Publishers Pvt. Ltd.’ (www.zorbapublishers.com)

The information contained in ‘Let’s Learn 3G in 10 Days’ is for general information

1 History and Standardization 2

2 Network Elements and Functionalities 25

4 Logical, Transport & Physical Channels 82

5 Radio Resource Management 117

6 Protocols & Interfaces 171

7 High Speed Downlink Packet Access 204

8 High Speed Uplink Packet Access 245

9.8 Inter-RNC Handover without Iur Interface . . . . . . . . . . . . . . . 326

10 Self Test 351

HISTORY AND STANDARDIZATION

1.1 Mobile Telecom Market

www.4gamericas.com, which contains a lot of interesting details about the present

Security: Analog speech was transmitted without any encryption.

Capacity: Analog speech cannot be compressed. Therefore, 1G radio transmission

Development of GSM in Europe

the Confederation of European Posts and Telecommunications (CEPT) to design a

• higher spectrum eﬃciency due to modern speech codecs

• (encrypted) secure radio transmission

• better quality by using an error-correction scheme (channel coding)

• better data services

• more advanced roaming

Three 2G Standards of USA

2. Meanwhile, IS-95 (cdmaOne) was deployed in 1993. In many regions of the

Figure 1.2: Commercially deployed Mobile Communication Systems of the 3GPP

3. The US Federal Communications Commission (FCC) also auctioned a new

GSM and its Evolution

Generation (2.5G) systems.

High Speed Circuit Switched Data (HSCSD)

Figure 1.3: HSCSD compared with GSM

General Packet Radio Service

• In a circuit-switched system, the line is occupied even when no data is trans-

• In a packet-switched system, the resources are released so they can be used by

Enhanced Data Rates for GSM Evolution

Figure 1.4: GPRS improvements for higher bit rates

Figure 1.5: Summary of EDGE Technology

Table 1.1: Comparison of 8-PSK and GMSK modulation schemes

MCS Modulation Code Rate User Rate

IMT-2000 oﬀers the capability of providing value-added services and applica-

Third-generation (3G) systems promise faster communications services, including

Figure 1.6: ITU’s vision of IMT-2000

Synchronous: These type of proposals requires synchronized base stations.

1.3 3GPP and 3GPP2

1.3.1 3rd Generation Partnership Project (3GPP)

ARIB The Association of Radio Industries and Businesses, Japan

CCSA China Communications Standards Association, China

TTA Telecommunications Technology Association, Korea

TTC Telecommunication Technology Committee, Japan

ETSI The European Telecommunications Standards Institute

ATIS The Alliance for Telecommunications Industry Solutions, USA

TIA Telecommunications Industries Association, USA

ISACC ICT Standards Advisory Council of Canada, Canada

ACIF Communications Alliance - former Australian Communications Industry Fo-

1.3.2 3rd Generation Partnership Project 2 (3GPP2)

Source: http://www.3gpp2.com/Public html/Misc/AboutHome.cfm

The Third Generation Partnership Project 2 (3GPP2) is also a collaborative eﬀort