Professional Documents
Culture Documents
s=0
AI
s
b
s,j
(4.1)
In equation 4.1, there are two terms on right hand side, AI
s
and b
s,j
. Let us inves-
tigate more about them step-by-step.
1. AI
s
: 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. b
s
: b
s
is chosen depending on the signature used by UE on PRACH preamble
using table 4.6 which has been dened by 3GPP
9
.
The real-valued symbols, a
j
, 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
104 CHAPTER 4. LOGICAL, TRANSPORT & PHYSICAL CHANNELS
S
b
s
,
j
,
w
h
e
r
e
j
=
0
,
1
,
2
,
.
.
.
,
3
1
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
1
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
-
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
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
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
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
T
a
b
l
e
4
.
6
:
A
I
C
H
S
i
g
n
a
t
u
r
e
p
a
t
t
e
r
n
s
4.4. PHYSICAL CHANNELS 105
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 dierence.
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 signalling
10
.
According to 3GPP specications, 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 gure 4.16, the uplink DPCCH is carries control informa-
tion which is added by Layer 1. Layer 1 control information contains following
elds:
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.
106 CHAPTER 4. LOGICAL, TRANSPORT & PHYSICAL CHANNELS
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 xed 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 T
slot
= 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 modied 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.
4.4. PHYSICAL CHANNELS 107
SF
Symbol Rate (ksps)
=
[
R
chip
SF
]
=
[
3.84 Mcps
SF
]
bit rate (kbps) on DL
DPCH
bit rate (kbps) on UL
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 gure 4.17, various elds of DPCH
108 CHAPTER 4. LOGICAL, TRANSPORT & PHYSICAL CHANNELS
can be identied. 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 gure 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 gure 4.19, an example is illustrated where 3 dierent UEs are using 3G services
in a cell which is operating at UL frequency f
UL
and DL frequency f
DL
. 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 identied 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 rst 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 lter (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 lter output.
110 CHAPTER 4. LOGICAL, TRANSPORT & PHYSICAL CHANNELS
Step 2: Frame synchronization and code-group identication
During the second step of the cell search procedure, the UE uses the SCHs sec-
ondary synchronization code to nd frame synchronization and identify the code
group of the cell found in the rst 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 identication
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 identied through symbol-by-symbol correlation over the CPICH
with all codes within the code group identied in the second step. After the primary
Scrambling code has been identied, the Primary CCPCH can be detected and the
system- and cell specic 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
simplied.
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 gure 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 xed, 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.
112 CHAPTER 4. LOGICAL, TRANSPORT & PHYSICAL CHANNELS
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 gure 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
114 CHAPTER 4. LOGICAL, TRANSPORT & PHYSICAL CHANNELS
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 denition 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.
Grant =
P
tx,E-DPDCH
P
tx,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
In order to create some gures, tables and text-sections, the following reference ma-
terial has been used. Information has been interpreted and presented in a simplied
manner. The original references are provided here.
Main reference material for this book has been technical specications (TSs) and
technical reports (TRs) of 3rd Generation Partnership Project (3GPP).
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
c 2006. 3GPP
TM
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 modications and are therefore provided to you as is for information
purposes only. Further use is strictly prohibited.
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
100
Section 5.3.3.4 of 3GPP TS 25.211 v 9.1.0.
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
in section 4.5 on page 109
Quoted word-by-word from Annex C of
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.
Figure 4.11 on page 100 Figure 15 of 3GPP TS 25.211 v 9.1.0.
Figure 4.12 on page 101 Figure 17 of 3GPP TS 25.211 v 9.1.0.
Figure 4.15 on page 103 Figure 21 of 3GPP TS 25.211 v 9.1.0.
Figure 4.16 on page 105 Figure 1 of 3GPP TS 25.211 v 9.1.0.
Figure 4.17 on page 107 Figure 9 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.
Table 4.5 on page 96 Table 4 of 3GPP TS 25.213 v 8.4.0.
Table 4.6 on page 104 Table 22 of 3GPP TS 25.211 v 9.1.0.
c 2009. 3GPP
TM
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 modications and are therefore provided to you as is for information
purposes only. Further use is strictly prohibited.
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)
[7] 3GPP TS 25.301 ver. 6.0.0 ;Radio Interface Protocol Architecture
[8] H.Holma and A. Toskala, WCDMA for UMTS , 5th Edition, John Wiley
& Sons.
[9] Chris Johnson, Radio Access Networks For UMTS ; Principles And
Practice , John Wiley & Sons.
For HSDPA-secic details, the version of these specs should be 5.0.0 or
higher & for HSUPA-specic details, it shold be 6.0.0 or higher.
116
CHAPTER
5
RADIO RESOURCE MANAGEMENT
Source:
3GPP TR 25.922 ver. 7.0.0 ; Radio resource management strategies
H.Holma and A. Toskala, WCDMA for UMTS , 5th Edition, John
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 identied 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 dened at RNC, Node B or cell level. Other than these, for proper
handover and mobility, there are parameters which can separately aect the mobility
from one source cell to dierent 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 nd 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 eective 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 sucient 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 criterion
1
.
4. Priority Handling: The services can be broadly categorized into 4 trac 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 buering 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 gure 5.1.
1. Radio parameters stored in RNCs database
2. Node B measurements
(a) Common Measurements
(b) Dedicated Measurements
3. UE measurements
4. RNCs internal calculation and measurements
120 CHAPTER 5. RADIO RESOURCE MANAGEMENT
Figure 5.1: Inputs for RRM functionality
Lets 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 specic 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 RNCs
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
aected. The threshold which denes 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.
5.1. INPUTS FOR RRM FUNCTIONALITY 121
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 denes the upper limit of marginal area is decided by the
planner and dened 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 aect 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 dierence 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.
122 CHAPTER 5. RADIO RESOURCE MANAGEMENT
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 modied 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 specic parameters
2
. 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.
5.1. INPUTS FOR RRM FUNCTIONALITY 123
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 identiers 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 reports
3
.
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 dene 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 modication etc.
According to 3GPP TS 25.215, some of the crucial UE measurements are:
3
Typically every few seconds. e.g., 3s.
124 CHAPTER 5. RADIO RESOURCE MANAGEMENT
Figure 5.4: Dedicated NBAP measurement management, source: 3GPP TS 25.433
P-CPICH RSCP
P-CPICH E
c
/N
0
UTRA carrier RSSI
GSM carrier RSSI (BCCH RxLev of GSM)
Transport channel BLER
UE transmitted power
UE Rx-Tx time dierence
SFN-SFN Observed time dierence
. . .
In order to read more about the denition 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 specications
4
, 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
5.1. INPUTS FOR RRM FUNCTIONALITY 125
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 dened 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 Trac 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.
. . .
126 CHAPTER 5. RADIO RESOURCE MANAGEMENT
5.2 Load Estimation
Source:
3GPP TR 25.922 ver. 7.0.0 ; Radio resource management strategies
H.Holma and A. Toskala, WCDMA for UMTS , 5th Edition, John
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 Lets Learn 3G in 10
Days, the author has tried to summarize the nal 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 dierent 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 aected 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 oor of the Node B:
Noise Rise, NR
UL
=
P
rx,total
P
noise
(5.1)
5.2. LOAD ESTIMATION 127
Without going into the mathematical derivation, we will write the nal relation
between Noise Rise (NR) and the cell load
UL
:
NR =
1
1
UL
or
UL
= 1
1
NR
(5.2)
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 = P
Noise
+ Int
Own cell
+ Int
Other 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 P
noise
. This indicates the amount of noise which has risen.
This scheme has a limitation, because:
RTWP does not dierentiate 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 P
Noise
, as depicted in equation 5.3. If the noise level itself
uctuates, 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 L
Thr,Cell
where
L
Thr,Cell
=
1
AF
i
(5.5)
where Eb/No is the signal energy per bit divided by noise spectral density that is
required to meet a predened block error rate, W is WCDMA chip rate, R
i
is the
bit rate of user i & AF
i
is the activity factor
5
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 P
tx,total
to RNC.
RNC uses this P
tx,total
measurements and compares it with the P
BTS,Max
. This
indicates what percentage of the Node B Power Ampliers power has been utilized
in the current measurement period.
DL
=
P
tx,total
P
BTS,Max
(5.6)
The operator must dene the DL load target. DL load target is dened as a ratio
of maximum Node B power amplier value. For example, in a 20 W carrier, if we
plan to use
DL
= 75%, then the cell is in normal state up to P
tx,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 specic.
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 RNCs packet scheduler
to resolve the state of congestion.
Prioritization: Ordering the dierent 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 rst 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
130 CHAPTER 5. RADIO RESOURCE MANAGEMENT
the conversation with their partner, the rst 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 dened 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 gure 5.5
5.4. ADMISSION CONTROL 131
Figure 5.5: Admission Control in RNC at RRC Connection Establishment
In RRC Connection request, UE species 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 gure 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, trac class, max bit rate, guaranteed bit rate, SDU error ratio,
trac handling priority, allocation retention priority, etc. From these QoS
parameters, RNC nds 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 gure 5.7. The decision about handover is taken in SRNC
132 CHAPTER 5. RADIO RESOURCE MANAGEMENT
Figure 5.6: Admission Control in RNC at RAB Establishment
whereas the admission control takes place in the target cells 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 dierentiate 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 specication, more than 16 Million
UL SC have been dened. 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 dierentiate among
the various channels transmitted from the same UE. For example:
In Rel-99 Conguration: DPDCH & DPDCH
134 CHAPTER 5. RADIO RESOURCE MANAGEMENT
In Rel-5 conguration: DPDCH, DPDCH & HS-DPCCH
In Rel-6 conguration: DPDCH, DPDCH, HS-DPCCH, E-DPCCH &
E-DPDCH
In Uplink, every user uses a dierent 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 eciently. 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 dierent codes are allocated to dierent
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 gure 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 CC
16,2
code was allocated to user 1 and CC
16,10
is allocated to another user.
As a result, CC
8,1
and CC
8,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 CC
16,10
and re-assign CC
16,3
to the same UE. Because the SF remains un-
changed, the net bit rate does not get aected. Therefore, this procedure happens
only at physical layer, without disturbing the higher
6
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
oered by future mobile systems. That is why Packet Scheduler is introduced in
RNC to handle the packet trac more eciently. 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
switching
7
.
Transport Format Combination Set (TFCS) construction: At the time
7
HS-DSCH DCH channel type switching can be understood as HSDPA to R99 handover.
136 CHAPTER 5. RADIO RESOURCE MANAGEMENT
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.
5.6. PACKET SCHEDULER 137
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 RNCs 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 etc
8
.
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 buer, 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
UEs wish for an upgrade in UL resources.
5.6.1 RRC States
Source : 3GPP TS 25.331 RRC Protocol Specification
9
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 specication of UTRAN. Developments in HSDPA,
HSUPA & HSPA+ domain have further increased the details available in this this document.
138 CHAPTER 5. RADIO RESOURCE MANAGEMENT
Which physical channels that are allocated to the UE, and thus which trans-
port channels that can be used. This factor aects the eective 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 state
10
.
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
dened. 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
specic technical words.
5.6. PACKET SCHEDULER 139
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
mA
11
).
From Operators 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 dened 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 identied 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 dierence 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:
Neither an uplink nor a downlink dedicated physical channel is allo-
cated to the UE.
The UE uses DRX for monitoring a PCH via an allocated PICH.
11
UE battery consumption strongly depends on the handsets hardware, features and congura-
tion. Therefore, the number mentioned here should be used as approximate value for understanding
purpose.
140 CHAPTER 5. RADIO RESOURCE MANAGEMENT
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 [] sign has been printed in front of those points
which dierentiate between these two states. Other points are common
in both the states. The URA PCH state is characterized by:
Neither an uplink nor a downlink dedicated physical channel is allo-
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.
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.
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.
5.6. PACKET SCHEDULER 141
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
specied by UE in the RRC Connection Request message. The complete
signalling ow is shown in gure 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 buer contains data
[in Bytes] which exceeds a certain threshold. In UL, the capacity request is
ocially 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.
142 CHAPTER 5. RADIO RESOURCE MANAGEMENT
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 specied 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 specied 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
5.6. PACKET SCHEDULER 143
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 RNCs 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 gure 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.
144 CHAPTER 5. RADIO RESOURCE MANAGEMENT
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.
PRACH Physical Random Access Ch.
S-SCH Secondary Synchronization Ch.
P-CPICH Primary Common Pilot Ch.
P-CCPCH Pri. Common Control Physical Ch.
S-CCPCH Sec. Common Control Physical Ch.
PICH Paging Indication Channel Ch.
AICH Acquisition Indication Channel Ch.
DL Dedicated Channels UL Dedicated Channels
DPCH Dedicated Physical Channel
DPDCH Dedicated Phy. Data Ch.
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 xed through-
out the operation. Their power values can be changed as an optimization eort
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 trac. 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 trac 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 dened by 3GPP TS 25.331 (section 8.5.7), UE calcu-
lates the power for the rst 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 preambles 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 xed, then the equation can be simplied 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 rst preamble is
directly proportional to the path loss experienced by the UE. Hence, further away
the UE is, stronger will be the initial preamble.
146 CHAPTER 5. RADIO RESOURCE MANAGEMENT
After transmitting the initial preamble UE will wait for a certain time
12
. 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 nished because its purpose was
only to calculate the minimum initial UL power which will allow UE to communicate
with Node B.
As dened 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 [].)
The message length in time, either 10 or 20 ms.
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).
The power-ramping factor Power Ramp Step [integer > 0].
The parameter Preamble Retrans Max [integer > 0].
The Power oset P p-m = (P
message-control
P
preamble
), 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 gure 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 gure 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.
5.7. POWER CONTROL 147
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 gure 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.
148 CHAPTER 5. RADIO RESOURCE MANAGEMENT
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, SIR
Target
.
The serving cells (cells in the active set) should estimate signal-to-interference ratio SIR
Est
of the received uplink using the Pilot Bits in UL DPCCH.
On Node B side, this decision has to be taken:
if SIR
Est
> SIR
Target
then the TPC command to transmit is 0.
if SIR
Est
< SIR
Target
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 dierent TPC
Commands from dierent 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 nal TPC command that
will be eective 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) P
tx,DPCCH
(n + 1) = P
tx,DPCCH
(n)
TPC
(5.9)
5.7. POWER CONTROL 149
If the received TPC command is equal to 1, then TPC cmd for that slot is +1.
DPCCH =
TPC
TPC cmd
(or) P
tx,DPCCH
(n + 1) = P
tx,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-specic 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 5
th
time slot. This reduces the frequency of power control from 1500 to 300 times
per second.
For rst four slots in set, TPC cmd = 0.
For the 5
th
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 5
th
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-specic 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:
150 CHAPTER 5. RADIO RESOURCE MANAGEMENT
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 = 10110 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, SIR
Target
. 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 eld of
DPCCH. From this gure, one can notice the power osets as following:
P01: The power oset between TFCI elds of DPCCH and the DPDCH.
P02: The power oset between TPC elds of DPCCH and the DPDCH.
PO3: The power oset between PILOT BITS elds of DPCCH and the DPDCH.
5.7. POWER CONTROL 151
Figure 5.14: Slot format of DL DPCH Channel
As power control takes place, the relative power osets 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 eld
of the uplink DPCCH. The UE shall check the downlink power control mode (DPC
Mode
)
before generating the TPC command. The DPC MODE parameter is a UE specic
parameter controlled by the UTRAN.
If DPC
Mode
= 0: the UE sends a unique TPC command in each slot and the TPC
command generated is transmitted in the rst available TPC eld in the uplink
DPCCH;
If DPC
Mode
= 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 DPC
Mode
= 0, UTRAN shall estimate the transmitted TPC command TPC
est
to be
0 or 1, and shall update the power every slot. If DPC
Mode
= 1, UTRAN shall estimate
the transmitted TPC command TPC
est
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:
152 CHAPTER 5. RADIO RESOURCE MANAGEMENT
DPC
Mode
= 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 xed step size
If TPC bit = 0 Decrease the power by a xed step size
DPC
Mode
= 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 xed step size
If 3 consecutive TPC bits are = 000 Decrease the power a xed step size
If 3 consecutive TPC bits are = 011 Ignore the commands
If 3 consecutive TPC bits are = 101 Ignore the commands
If 3 consecutive TPC bits are = . . . Ignore the commands
5.7.3 Outer Loop Power Control
Outer Loop Power Control adjusts the SIR target (SIR
Target
), in order to achieve a desired
Target Block Error Rate (BLER
Target
). 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 (BLER
Target
). When UE receives the data, it calculates the actual value of BLER
received in the current TTI. This procedure is illustrated in gure 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 modied.
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 BLER
Target
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.
5.7. POWER CONTROL 153
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 gure 5.16. The same sequence of steps are described in the following text:
154 CHAPTER 5. RADIO RESOURCE MANAGEMENT
1. At connection setup, (RRC or RAB), RNCs admission control decides the UL BLER
Target
.
2. Admission control also decides the initial, minimum and maximum SIR
Target
.
3. RNC informs Node B about the initial SIR
Target
.
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 briey described below.
(a) UE transmits pilot bits on UL DPCCH channel.
(b) Node B estimates the Signal-to-interference-ratio (SIR
Est
) & decides the po-
larity of TPC bits.
if SIR
Est
> SIR
Target
then the TPC command to transmit is 0
if SIR
Est
< SIR
Target
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
eld 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 BLER
Est
and
compares it with BLER
Target
. 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 modied 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 dierent
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 denition, there are areas of the UE operation in
which the UE is simultaneously communicating via a number of radio links towards
dierent cells.
With reference to Soft Handover, the Active Set is dened 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 dierent radio access technology.
The source and target cell are both operating at same frequency but a SHO is
not possible
13
.
Another way of classication 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 f
1
& 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 RNCs.
13
This happens in the case of Inter-RNC Handover without Iur interface support.
156 CHAPTER 5. RADIO RESOURCE MANAGEMENT
2. Inter Frequency Handover (IFHO): In GSM, the neighbouring cells generally op-
erate on dierent frequency. Therefore, while moving from one cell to another is
simply an Inter Frequency HO, but there is a big dierence 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-dened 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 benecial 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 denitions), 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 mans language, we
can call these cells as dened 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. HANDOVER CONTROL 157
5.8.2 Soft/Softer Handover
The only dierence between soft and softer handover is:
In Soft Handover, the cells taking part in HO are served by two dierent 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 ow can have dierent 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 gure 5.16).
In Softer HO, there is no MDC because it is Node B which performs the combining
of two uplink radio links.
Another dierence 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 dierent 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 dened 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.
158 CHAPTER 5. RADIO RESOURCE MANAGEMENT
For Soft handover, there are three main events dened in the specications 3GPP TS
25.331. Within Measurement Control message, the UTRAN noties 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-
plied 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 dene event 1A as Event
1A is used to ADD a cell to the active set.
As shown in gure 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 gure. The
threshold does not have an absolute value but relative to the best active set cell.
In right sub-gure of gure 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)
5.8. HANDOVER CONTROL 159
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 species the DL SC of the neigh-
bour cell along with the CPICH Ec/No value. This signalling scenario was
illustrated in gure 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 nally 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 dene event 1B as Event
1B is used to DELETE a cell from the active set.
As shown in gure 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
160 CHAPTER 5. RADIO RESOURCE MANAGEMENT
threshold shown in the gure. The threshold does not have an absolute value but
relative to the best active set cell.
In the left sub-gure of gure 5.18, there are 2 cells in the AS and in the right
sub-gure 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 dene event 1C as Event 1C is
used to REPLACE a weak AS Cell with a Stronger one outside
the AS.
5.8. HANDOVER CONTROL 161
As shown in gure 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 gure 5.19.
In gure 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 gure 5.20. This gure 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)
162 CHAPTER 5. RADIO RESOURCE MANAGEMENT
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
Trac 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-gure of gure 5.21, the downlink signal of the active set cell
has become very weak. According to 3GPP TS 25.331, there are specic 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 gure 5.21(see left sub-gure), 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.
5.8. HANDOVER CONTROL 163
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 gure 5.21 (see right sub-gure), 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 eld in the MEASUREMENT CONTROL mes-
sage, UTRAN noties 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
164 CHAPTER 5. RADIO RESOURCE MANAGEMENT
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 dene 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 fullled:
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:
5.8. HANDOVER CONTROL 165
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 eld in the MEASUREMENT CONTROL mes-
sage, UTRAN noties 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 dene 2 terms:
1. Other System: Other system is e.g., GSM or E-UTRA
14
. 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 fullled:
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
166 CHAPTER 5. RADIO RESOURCE MANAGEMENT
another frequency while resuming the service on its serving frequency. This method is
called Compressed Mode
15
.
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 verication
5. Phase 5: Measurement Reports (UE to RNC)
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.
5.8. HANDOVER CONTROL 167
8. Phase 8: Communication between UE and GERAN
9. Phase 9: Conrmation about successful HO to RNC
Please refer to section 9.9 for the signalling ow and more explanation.
168 CHAPTER 5. RADIO RESOURCE MANAGEMENT
Copyright Notices
In order to create some gures, tables and text-sections, the following reference material
has been used. Information has been interpreted and presented in a simplied manner.
The original references are provided here.
Main reference material for this book has been technical specications (TSs) and technical
reports (TRs) of 3rd Generation Partnership Project (3GPP).
Figure 5.3 on page 122 Figure 13 of 3GPP TS 25.433 v 7.0.0.
Figure 5.4 on page 124 Figure 40 of 3GPP TS 25.433 v 7.0.0.
Figure 5.20 on page 161 Figure 5-1 of 3GPP TS 25.922 v 7.0.0.
Text about RRM Strategies in
section 5.3 on page 129
Section 12 of 3GPP TS 25.922 v 7.0.0.
Text about Common-NBAP mea-
surements on page 122
Section 8.2.9.2 of 3GPP TS 25.433 v 7.0.0.
Text about Dedicated-NBAP
measurements on page 123
Section 8.2.9.2 of 3GPP TS 25.433 v 7.0.0.
Text about UE measurements on
page 123
Section 5.1 & 5.2 of 3GPP TS 25.215 v 7.0.0.
Text about Initial PRACH
Preamble on page 145
Section 8.5.7 of 3GPP TS 25.331 v 6.9.0.
Text about Active, Monitored
and Detected cells on page 156
Section 8.4.0 of 3GPP TS 25.331 v 6.9.0.
Text about Intra-frequency mea-
surement quantities on page 157
Section 14.1.1. of 3GPP TS 25.331 v 6.9.0.
Text about IF measurement
quantities on page 164
Section 14.2.0a of 3GPP TS 25.331 v 6.9.0.
Text about Event 2A to 2F on
page 164
Section 10.3.7.19 of 3GPP TS 25.331 v 6.9.0.
Text about IS measurement
quantities on page 164
Section 14.3.0a of 3GPP TS 25.331 v 6.9.0.
Text about Event 3A to 3D on
page 165
Section 10.3.7.30 of 3GPP TS 25.331 v 6.9.0.
c 2006. 3GPP
TM
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 modications and are therefore provided to you as is for information
purposes only. Further use is strictly prohibited.
5.8. HANDOVER CONTROL 169
Text about Open Loop PC pa-
rameters on page 146
Section 6.1 3GPP TS 25.214 v 6.9.0.
Text about UL Inner Loop PC on
page 148
Section 5.1.2.2.1 3GPP TS 25.214 v 6.9.0.
Text about UL PC Algorithm 1
on page 149
Section 5.1.2.2.2 3GPP TS 25.214 v 6.9.0.
Text about UL PC Algorithm 2
on page 149
Section 5.1.2.2.3 3GPP TS 25.214 v 6.9.0.
Text about DL PC (UE be-
haviour) on page 151
Section 5.2.1.2.1 3GPP TS 25.214 v 6.9.0.
Text about DL PC (UTRAN be-
haviour) on page 151
Section 5.2.1.2.2 3GPP TS 25.214 v 6.9.0.
Figure 5.12 on page 147 Figure 31 of 3GPP TS 25.211 v 9.1.0.
c 2009. 3GPP
TM
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 modications and are therefore provided to you as is for information
purposes only. Further use is strictly prohibited.
BIBLIOGRAPHY
[1] 3GPP TS 25.211 ver. 6.0.0 ;Physical channels and mapping of transport channels
onto physical channels (FDD)
[2] 3GPP TS 25.212 ver. 7.0.0 ;Multiplexing and Channel Coding (FDD)
[3] 3GPP TS 25.213 ver. 6.0.0 ;Spreading and Modulation (FDD)
[4] 3GPP TS 25.214 ver. 6.0.0 ;Physical Layer Procedures (FDD)
[5] 3GPP TS 25.214 ver. 6.0.0 ;3GPP TS 25.215, Physical layer - Measurements (FDD)
[6] 3GPP TS 25.301 ver. 7.0.0 ;Radio Interface Protocol Architecture
[7] 3GPP TS 25.401 Ver. 7.0.0 ;UTRAN overall description
[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 specication
[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-specic details, the version of these specs should be 5.0.0 or
higher & for HSUPA-specic details, it should be 6.0.0 or higher.
170
CHAPTER
6
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 Specic Connection-Oriented Protocol
SSCF-NNI: Service Specic Coordination Function - Network-Network Interface
SSCF-UNI: Service Specic 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 modied 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 denes 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 denes 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-specic
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.
174 CHAPTER 6. PROTOCOLS & INTERFACES
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 specied 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-dened 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 trac which is depicted by dashed and solid lines respectively in
the gure 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 gure 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-dened 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 dene 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
176 CHAPTER 6. PROTOCOLS & INTERFACES
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 congurable 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 Reconguration and RAB Reconguration sound very similar
and quite often people mix them up.
6.2. QOS AND BEARER 177
We should remember that Radio Bearer (RB) Reconguration is a local sig-
nalling procedure between UE and RNC, whereas, RAB Reconguration hap-
pens with the involvement of core network. RB reconguration happens very
often and can be seen from L3 radio messages, but to analyze the signalling
of RAB reconguration 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 dene it using a list of parameters.
One of these parameters is the Trac Class. According to 3GPP TS 23.107, all the
services can be classied into 4 groups:
Conversational class
Streaming class
Interactive class
Background class
The delay sensitivity of trac is the main criteria for this classication. Conversational
class trac is aected very badly the bearer is lost for few hundred ms where as the
bearer background class will not be aected so badly even if the bearer is unavailable for
few seconds.
Other than this classication, 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 trac ows whereas the Interactive and Background
trac classes are suitable for carrying Non-Real-Time trac.
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).
178 CHAPTER 6. PROTOCOLS & INTERFACES
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 ow 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
trac - 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 les in the
background, this scheme applies. Examples are background delivery of E-mails, SMS,
download of databases and reception of measurement records. Background trac - 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 Specications , the denition 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 gure 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 dened in close co-ordination with the
technology and medium of transport. AS protocol in radio interface is RRC, which
clearly denes 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 dier-
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 dened which will be discussed in section 6.9.
180 CHAPTER 6. PROTOCOLS & INTERFACES
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 specications 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-specic 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 gure 6.5. The functions of each individual protocol
layer is explained in the coming sections. This gure 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 gure 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 rst 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 gures 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 gures 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 modied. 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
182 CHAPTER 6. PROTOCOLS & INTERFACES
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 ow PDCP RLC MAC PHY
Broadcast & Multicast Services
On the transmitter side, the protocol stack for BC services is as follows:
Common Trac 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
6.4. RADIO PROTOCOLS 183
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 Conguration 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 congured 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 congured in the Transparent mode, the
ciphering is performed by the MAC sublayer.
184 CHAPTER 6. PROTOCOLS & INTERFACES
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 conguration 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.
6.4. RADIO PROTOCOLS 185
Other than this, RLC layer also performs the following functions:
Maintenance of QoS as dened by upper layers.
Notication of unrecoverable errors.
6.4.5 MAC-layer Functions
Source: 3GPP TS 25.321; Medium Access Control (MAC) protocol specica-
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 layers
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 ows of one UE;
Priority handling between UEs by means of dynamic scheduling;
Identication of UEs on common transport channels;
Identication 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;
Trac volume measurement;
Transport Channel type switching and
Ciphering for transparent mode RLC.
HSDPA-specic MAC (MAC-hs) and HSUPA-specic MAC(MAC-e/es) will
be discussed in their respective modules.
186 CHAPTER 6. PROTOCOLS & INTERFACES
6.4.6 PDCP-layer Functions
Source: 3GPP TS 25.323; Packet Data Convergence Protocol (PDCP) speci-
cation
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 specic 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 congured 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 dicult 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 sections
1
.
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 specications.
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 gure 6.7.
As shown in gure 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 gure 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.
188 CHAPTER 6. PROTOCOLS & INTERFACES
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.
190 CHAPTER 6. PROTOCOLS & INTERFACES
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 gure 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.
192 CHAPTER 6. PROTOCOLS & INTERFACES
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 gure 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
ATM-based transport, &
IP-based transport
6.7.2 User Plane - Iub UP
This section species 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 gure 6.12.
ATM-based transport, &
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 specied 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.
194 CHAPTER 6. PROTOCOLS & INTERFACES
NBAP dedicated procedures or D-NBAP are procedures that are related to
a specic subscriber who is identied by Node B Communication Context in Node
B.
The full NBAP specications are available in 3GPP TS 25.433. From the same specica-
tion, the functions performed by NBAP are listed below:
Cell Conguration 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 Notication.
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 gure 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 gure 6.13.
6.8.2 User Plane - Iur UP
The user plane protocol stack on Iur interface is illustrated in gure 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 specications are available in section 7 of 3GPP TS 25.423. The functions
performed by RNSAP are listed below:
196 CHAPTER 6. PROTOCOLS & INTERFACES
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 Reconguration,
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.
198 CHAPTER 6. PROTOCOLS & INTERFACES
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 gure 6.15. In this gure, there are 2 access technologies, TDMA-based
BSS (2G) and CDMA-based UTRAN (3G). The NAS messages are depicted with the
bidirectional arrows which ow 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 gure 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 identied by their protocol discriminator eld as shown in table 6.2.
In LTE/EPS, the concept of AS and NAS protocols is reused and the denitions 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.
200 CHAPTER 6. PROTOCOLS & INTERFACES
Copyright Notices
In order to create some gures, tables and text-sections, the following reference material
has been used. Information has been interpreted and presented in a simplied manner.
The original references are provided here.
Main reference material for this book has been technical specications (TSs) and technical
reports (TRs) of 3rd Generation Partnership Project (3GPP).
Text in section 6.5.3 on page 189 Section 7 of 3GPP TS 25.413 v 7.0.0.
c 2005. 3GPP
TM
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 modications and are therefore provided to you as is for information
purposes only. Further use is strictly prohibited.
Figure 6.1 on page 173 Figure 10 of 3GPP TS 25.401 v 7.0.0.
Figure 6.5 on page 180 Figure 11 of 3GPP TS 25.301 v 7.0.0.
Figure 6.6 on page 182 Figure 12 of 3GPP TS 25.301 v 7.0.0.
Figure 6.7 on page 188 Figure 6.1 of 3GPP TS 25.410 v 7.0.0.
Figure 6.8 on page 188 Figure 6.1 of 3GPP TS 25.410 v 7.0.0.
Figure 6.9 on page 190 Figure 6.3 of 3GPP TS 25.410 v 7.0.0.
Figure 6.10 on page 191 Figure 6.3 of 3GPP TS 25.410 v 7.0.0.
Figure 6.11 on page 192 Figure 7 of 3GPP TS 25.430 v 7.0.0.
Figure 6.12 on page 193 Figure 7 of 3GPP TS 25.430 v 7.0.0.
Figure 6.13 on page 196 Figure 4 of 3GPP TS 25.420 v 7.0.0.
Figure 6.14 on page 196 Figure 4 of 3GPP TS 25.420 v 7.0.0.
Text about RRC Protocol func-
tions on page 182
Section 5.1 of 3GPP TS 25.331 v 6.9.0.
Text about Protocol Layers on
page 173
Section 11.1.2 of 3GPP TS 25.401 v 7.0.0.
Text about Protocol Planes on
page 173
Section 11.1.3 of 3GPP TS 25.401 v 7.0.0.
Text in section 6.7.3 on page 193 Section 7 of 3GPP TS 25.433 v 7.0.0.
Text in section 6.8.3 on page 195 Section 7 of 3GPP TS 25.423 v 7.0.0.
c 2006. 3GPP
TM
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 modications and are therefore provided to you as is for information
purposes only. Further use is strictly prohibited.
6.9. NON-ACCESS STRATUM PROTOCOLS 201
Figure 6.3 on page 176 Figure 1 of 3GPP TS 23.107 v 7.0.0.
Text in section 6.2.1 on page 177 Section 6.3 of 3GPP TS 23.107 v 7.0.0.
c 2007. 3GPP
TM
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 modications and are therefore provided to you as is for information
purposes only. Further use is strictly prohibited.
Text in section 6.4.4 on page 183 Section 6 of 3GPP TS 25.322 v 9.0.0.
Text in section 6.4.6 on page 186 Section 5 of 3GPP TS 25.323 v 9.0.0.
c 2010. 3GPP
TM
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 modications and are therefore provided to you as is for information
purposes only. Further use is strictly prohibited.
BIBLIOGRAPHY
[1] 3GPP TS 23.107 ver. 7.0.0 ;Quality of Service (QoS) concept and architecture
[2] 3GPP TS 25.301 ver. 7.0.0 ;Radio Interface Protocol Architecture
[3] 3GPP TS 25.321 ver. 7.0.0 ;MAC protocol specication
[4] 3GPP TS 25.322 ver. 7.0.0 ;RLC protocol specication
[5] 3GPP TS 25.323 ver. 7.0.0 ;PDCP protocol specication
[6] 3GPP TS 25.324 ver. 7.0.0 ;BMC protocol specication
[7] 3GPP TS 25.331 ver. 7.0.0 ;Radio Resource Control (RRC) protocol specication
[8] 3GPP TS 25.401 Ver. 7.0.0 ;UTRAN overall description
[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
[27] H.Holma and A. Toskala, WCDMA for UMTS , 5th Edition, John Wiley & Sons.
[28] Chris Johnson, Radio Access Networks For UMTS ; Principles And Prac-
tice , John Wiley & Sons.
For HSDPA-specic details, the version of these specs should be 5.0.0 or
higher & for HSUPA-specic details, is should be 6.0.0 or higher.
CHAPTER
7
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 operators 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 aects 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 operators revenue and also network accessibility KPI.
Cost of usage: 3G was expected to fulll the dream which was started by GPRS. Ev-
eryone expected that aordable 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
operators perspective so that more aordable 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 EDGE
1
. 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 oer > 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 specications & 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 dened 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.
Release
UE
Category
Mod MIMO
DC-
HSDPA
Peak
Bitrate
Release 5 1 to 12
QPSK,
16QAM
No No 14.4 Mbps
Release 6 Same as Rel-5
Release 7 13 to 18
QPSK,
16QAM,
64QAM
2X2 with
16QAM
No
28 or 21
Mbps
Release 8 19 to 24
QPSK,
16QAM,
64QAM
2X2 with
64QAM
2 Carriers 42 Mbps
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 RNCs 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
buer 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
208 CHAPTER 7. HIGH SPEED DOWNLINK PACKET ACCESS
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 nd 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 specic messages and
procedures. In other words, the call ow of packet switched connection setup of Rel-99
and Rel-5 are the same which is illustrated in gure 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
Reconguration messages. Using this message, UE comes to know about its HSDPA-
specic id H-RNTI and the HSDPA conguration 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 dierence 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 buer the user data at Node B. The transfer of data from RNC to Node B takes
place in such a way that the buer at Node B does not over ow. This procedure is called
Iub ow control and accomplished by the two messages illustrated in gure 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 rst message in gure 7.2, the Capacity Request message provides the
210 CHAPTER 7. HIGH SPEED DOWNLINK PACKET ACCESS
Node B with information regarding the RNC buer occupancy for a specic priority
queue belonging to a specic MAC-d ow.
Step 2: Node B informs RNC about the suitable amount. As shown in the sec-
ond message in gure 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 specic MAC-d ow pri-
ority queue towards the Node B at a specic 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 indenite period.
7.4. WHATS NEW IN HSDPA? 211
7.4 Whats 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 xed 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 inexibility. 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 modication 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 eect 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 dened 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 buered at MAC layer before
being delivered to the lower layers for transmission.
212 CHAPTER 7. HIGH SPEED DOWNLINK PACKET ACCESS
Modulation Coding Rate # codes
Gross Bit
Rate
Net Bit
Rate
QPSK 1/4 5 2.4 Mbps 600 kbps
QPSK 1/2 5 2.4 Mbps 1.2 Mbps
QPSK 3/4 5 2.4 Mbps 1.8 Mbps
QPSK 1/4 10 4.8 Mbps 1.2 Mbps
QPSK 1/2 10 4.8 Mbps 2.4 Mbps
QPSK 3/4 10 4.8 Mbps 3.6 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: Eect 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 xed and its value is 2 ms. In simple words, every 2ms one
2
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 users radio channels
quality. Therefore, the bit rate upgrade/downgrade is only possible by RNC. To illustrate
this, two methods are briey explained below:
High Trac Volume Measurement: User data might be buered at UE for Uplink
transmission or in RNC for DL transmission:
If the amount of data (in Bytes) buered in user-specic buer at RNCs 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.
7.4. WHATS NEW IN HSDPA? 213
If the amount of data (in Bytes) buered in user equipments buer exceeds a
certain threshold, then UE sends a measurement report to RNC and informs
about this event
3
. 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 specic 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 eective in adjusting the bitrate
allocation to the UEs requirements but this mechanism is very slow and it takes
several hundred ms before the bit rate modication 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 benecial
for both end-user and the operator. The end-user benets 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 exibility in bit rates (8, 16, 32, . . ., 384) is achieved by using
variable spreading factor from SF4 to SF256.
Whereas, in HSDPA, the SF is xed to 16. Therefore, the exibility 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
214 CHAPTER 7. HIGH SPEED DOWNLINK PACKET ACCESS
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 denition. CQI report denition is a
table containing 31 values, each of which is dened 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 osets, etc.
For every UE category, there is a CQI table dened in 3GPP TS 25.214. Since these
specications 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 elds. 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 congured and table G if 64QAM is congured. CQI table
G is shown in table 7.4.
7.4. WHATS NEW IN HSDPA? 215
CQI value
Transport Block
Size
Number of
HS-PDSCH
Modulation
Reference power
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 dierent device categories, we can make following observations:
216 CHAPTER 7. HIGH SPEED DOWNLINK PACKET ACCESS
CQI value
Transport Block
Size
Number of
HS-PDSCH
Modulation
Reference power
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
7.4. WHATS NEW IN HSDPA? 217
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 ght 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 receivers response
before sending a new block or retransmitting the erroneous one.
218 CHAPTER 7. HIGH SPEED DOWNLINK PACKET ACCESS
In its basic form, stop-and-wait mechanism is not very ecient, 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 congure 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
ow.
Figure 7.3: Ilustration of parallel processes of HSDPA H-ARQ scheme
7.4.6 MAC-hs Protocol in Node B and UE
It wont 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 ow control etc.
7.4. WHATS NEW IN HSDPA? 219
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 gure 7.4).
Figure 7.4: HS-DSCH Serving Cell Change; 3 phases
The gure 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 cells area, it will maintain the radio link only with the Node B of the target
cell.
220 CHAPTER 7. HIGH SPEED DOWNLINK PACKET ACCESS
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
buered 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 ushes (or discards) the buered 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
ows from RNC are buered at Node B. The data ow 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 eld 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 gure 7.6. These functions are listed in table 7.5. Lets
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 gure 7.7.
222 CHAPTER 7. HIGH SPEED DOWNLINK PACKET ACCESS
On Node B Side On UE side
1. Flow Control
2. Scheduling/Priority
Handling
3. HARQ
4. TFRC selection
1. HARQ
2. Reordering Queue dis-
tribution:
3. Reordering
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 gure 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
7.5. HSDPA PROTOCOL ARCHITECTURE 223
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 subgure of gure 7.7. IR has the liberty to change the redundancy
version after getting a negative acknowledgement.
2. Reordering Queue distribution: Using the QUEUE ID eld of MAC-hs header,
UEs MAC-hs protocol entity forwards the MAC-hs PDUs to the correct reordering
buer.
3. Reordering: On UE side, one reordering entity is congured 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 elds: (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.
224 CHAPTER 7. HIGH SPEED DOWNLINK PACKET ACCESS
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 gure 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
gure 7.2.
Flow control function in MAC-d provides a controlled data ow 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 ow controls
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 ow control is to limit the layer 2 signalling latency and minimize the
discarded and retransmitted data which can happen due to HS-DSCH congestion.
7.5. HSDPA PROTOCOL ARCHITECTURE 225
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 buer overow and makes the
Iub transmission more eective. Flow control is provided independently by MAC-d
ow 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 ows according to their priority class.
Based on UEs 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 gure 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 ow 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 congured. 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.
226 CHAPTER 7. HIGH SPEED DOWNLINK PACKET ACCESS
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 channel
4
. In R99, the logical channel DTCH
5
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:
=
2 if Modulation is QPSK,
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.
238 CHAPTER 7. HIGH SPEED DOWNLINK PACKET ACCESS
UE
Cat.
Symbol
Rate
Best Mod-
ulation
Bit Rate
#
codes
R
bit
(Gross)
R
bit
(Net)
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
8 240 Ksps 16QAM 960 kbps 10 9.6 Mbps 7.2 Mbps
10 240 Ksps 16QAM 960 kbps 15 14.4 Mbps 10.8 Mbps
14 240 Ksps 64QAM 1440 kbps 15 21.6 Mbps 16.2 Mbps
16 240 Ksps 16QAM 960 kbps 15
28.8
Mbps
10
1.8 Mbps
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 nal
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
dened 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 dierence 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 dierent Node Bs. Thus, we need to discuss two dierent mobility scenarios:
In 3GPP 25.308, several ways to classify the Serving HS-DSCH Cell change procedures
are dened. We will discuss the classication which is based on the serving HS-DSCH
Node B. The signalling scenarios related to these procedures are discussed in chapter 9.
240 CHAPTER 7. HIGH SPEED DOWNLINK PACKET ACCESS
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 buered at Node B can be transmitted to the user
using new radio link. There is no need to ush 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 dierent Node Bs. There-
fore, when the user moves into the new cell, the unacknowledged buer data at old
Node B must be ushed 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 gure 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
HS-PDSCH
Carries DL user
data
16
QPSK &
16QAM
1/3 Turbo coding
HS-SCCH
Carries
scheduling info
128 QPSK
1/3
Convolutional
coding
ACK =
1111111111
HS-
DPCCH
Used to send UL
feedback
256 BPSK
NACK =
0000000000
CQI = (20,5)
Block coding
Table 7.11: Summary of HSDPA channels
242 CHAPTER 7. HIGH SPEED DOWNLINK PACKET ACCESS
Copyright Notices
In order to create some gures, tables and text-sections, the following reference material
has been used. Information has been interpreted and presented in a simplied manner.
The original references are provided here.
Main reference material for this book has been technical specications (TSs) and technical
reports (TRs) of 3rd Generation Partnership Project (3GPP).
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.11 on page 229 Figure 26A 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.6 on page 233 Table 26 of 3GPP TS 25.211 v 9.1.0.
Figure 7.14 on page 234 Figure 12B 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.
Text in section 7.7 on page 235 Section 7 of 3GPP TS 25.211 v 9.1.0.
c 2009. 3GPP
TM
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 modications and are therefore provided to you as is for information
purposes only. Further use is strictly prohibited.
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.
c 2008. 3GPP
TM
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 modications and are therefore provided to you as is for information
purposes only. Further use is strictly prohibited.
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.
Table 7.8 on page 237 Table 5.1a of 3GPP TS 25.306 v 9.1.0.
Table 7.9 on page 237 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.
c 2010. 3GPP
TM
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 modications and are therefore provided to you as is for information
purposes only. Further use is strictly prohibited.
BIBLIOGRAPHY
[1] 3GPP TS 25.301 ver. 7.0.0 ;Radio Interface Protocol Architecture
[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
[4] 3GPP TS 25.211 ver. 6.0.0 ;Physical channels and mapping of transport channels
onto physical channels (FDD)
[5] 3GPP TS 25.212 ver. 6.0.0 ;Multiplexing and Channel Coding (FDD)
[6] 3GPP TS 25.213 ver. 6.0.0 ;Spreading and Modulation (FDD)
[7] 3GPP TS 25.214 ver. 6.0.0 ;Physical Layer Procedures (FDD)
[8] 3GPP TS 25.321 ver. 7.0.0 ;MAC protocol specication
[9] 3GPP TS 25.331 ver. 7.0.0 ;Radio Resource Control (RRC) protocol specication
[10] 3GPP TS 25.401 Ver. 7.0.0 ;UTRAN overall description
[11] 3GPP TS 25.413 Ver. 7.0.0 ;UTRAN Iu Interface: RANAP Signalling
[12] 3GPP TS 25.433 Ver. 7.0.0 ;UTRAN Iub Interface: NBAP Signalling
[13] 33GPP TR 25.931 ver. 8.0.0 ;UTRAN functions, examples on signalling procedures
[14] H.Holma and A. Toskala, WCDMA for UMTS , 5th Edition, John Wiley & Sons.
[15] H.Holma and A. Toskala, HSDPA/HSUPA for UMTS , 1st Edition, John Wiley
& Sons.
[16] Chris Johnson, Radio Access Networks For UMTS ; Principles And Prac-
tice , John Wiley & Sons.
244
CHAPTER
8
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 Uplink
1
.
The rst 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 ocial 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 signicant improvements in
terms of user experience (throughput and delay) and/or capacity. The coverage is
one of the aspects which aect 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 equipments (UE)
& network elements cost is not very high. In R99 specication, 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 trac classes.
There is always a trade-o 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 signicant 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 dierent 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, lets discuss the commonalities and dierences 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 RNCs 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 modied. This concept is common in
HSDPA and HSUPA.
Rel-5 HSDPA devices support QPSK & 16QAM modulation
2
. 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 signicantly 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 nds 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
248 CHAPTER 8. HIGH SPEED UPLINK PACKET ACCESS
8.2.2 Dierences 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 eect.
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 xed. 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 buered
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 buer. There has to be some periodic reporting of the
buer status.
In HSUPA, we have some kind of
Request Grant Data Transmission Acknowledgement
mechanism. Whereas,
In HSDPA, we have
Notication 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-
nalling
3
. RLC also performs ciphering. If the Acknowledged Mode (AM) of
RLC is congured, then RLC layer keeps track of L2 retransmissions.
3
in RB setup or RB Reconguration message.
8.3. HSUPA USER PLANE PROTOCOLS 249
Figure 8.1: HSUPA User Plane Protocols
MAC-d layer in UE generates the MAC-d ows. 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 Bs Physical layer receives the data coming from UEs
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.
250 CHAPTER 8. HIGH SPEED UPLINK PACKET ACCESS
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 Conguration Options
At rst 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 conguration, HS-DSCH channel and E-DCH chan-
nel is used to carry the DTCH logical channel whereas the logical channel DCCH
or RRC signalling
4
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 gure 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-
gured to send both User data DTCH and DCCH. This option is commonly known
as SRB on HSPA. The control plane protocol stack for this conguration is illus-
trated in gure 8.3.
This option signicantly 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 dened 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
dierent 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).
252 CHAPTER 8. HIGH SPEED UPLINK PACKET ACCESS
Rel. 8: No new Category dened in Rel-8.
Rel. 9: Category 8 & 9 Categories have been added which support Dual Cell-HSUPA
(or DC-HSUPA) operation.
E-DCH
Category
Max
no. of
E-DCH
Codes
Min.
SF
Supported
TTI
Max. TB
Size [bits]
in 10 ms
TTI
Max. TB
Size [bits]
in 2 ms
TTI
Modul.
Cat. 1 1 SF4 10 ms only 7110 - BPSK
Cat. 2 2 SF4 10 ms & 2 ms 14484 2798 BPSK
Cat. 3 2 SF4 10 ms only 14484 - BPSK
Cat. 4 2 SF2 10 ms & 2 ms 20000 5772 BPSK
Cat. 5 2 SF2 10 ms only 20000 - 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)
E-DCH
Category
Max
no. of
E-DCH
Codes
Min.
SF
Supported
TTI
Max. TB
Size [bits]
in 10 ms
TTI
Max. TB
Size [bits]
in 2 ms
TTI
Modul.
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)
E-DCH
Category
Max
no. of
E-DCH
Codes
Min.
SF
Supported
TTI
Max. TB
Size [bits]
in 10 ms
TTI
Max. TB
Size [bits]
in 2 ms
TTI
Modul.
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 dierent 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 RNCs
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 gure 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
specic HSDPA and HSUPA details to user in a L3 RRC message Radio Bearer Recon-
guration.
254 CHAPTER 8. HIGH SPEED UPLINK PACKET ACCESS
Figure 8.4: Signalling to initiate an HSUPA session
8.7 HSUPA Protocol Architecture
Source: 3GPP TS 25.321; Medium Access Control (MAC) Protocol Speci-
cation
Earlier in section 8.3, the user plane protocol architecture of HSUPA & data-ow was
described but the details about MAC-e and MAC-es were not discussed. In the same sec-
tion, gure 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 congured. Whereas on UE side, both MAC-e & MAC-es
are congured 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 specic 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 conguration 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 oset 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 congure 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 gure 8.7. PDU sizes directly aect
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
256 CHAPTER 8. HIGH SPEED UPLINK PACKET ACCESS
via L1 and Serving Grant value signalled through RRC, and for arbitration among
the dierent ows mapped on the E-DCH. The detailed conguration 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 gure 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
8.7. HSUPA PROTOCOL ARCHITECTURE 257
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 ow and the MAC-es SDU size are included as part of the MAC-e
header. In case sucient 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 gure 8.7, the eld DDI0 is referring to the specic 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.
258 CHAPTER 8. HIGH SPEED UPLINK PACKET ACCESS
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 specic 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 buer based on the SRNC conguration.
8.7. HSUPA PROTOCOL ARCHITECTURE 259
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
specied. However, the model below is based on one Reordering Queue Distribution
entity receiving all the MAC-d ow 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 PDUs 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 specic 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 specied (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 ow.
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.
260 CHAPTER 8. HIGH SPEED UPLINK PACKET ACCESS
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. CHANNELS AND PHYSICAL LAYER 261
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 rst 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 dierent 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 dened. As an
example, we try to calculate the peak L1 bitrate of category 6.
262 CHAPTER 8. HIGH SPEED UPLINK PACKET ACCESS
Slot format #i Channel Bit
Rate (kbps)
Channel Symbol
Rate (ksps)
SF Bits/ E-DPDCH
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
+ E-DPDCH Code # 3 : SF2 = 1920 ksps
+ E-DPDCH Code # 4 : SF2 = 1920 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 ( 2SF2+2SF4 ), UE is able
to achieve a L1 bit rate of 5.76 Mbps. The knowledge of channel coding rate is needed to
nd 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 oset relative to the DPCCH. The power oset is signalled
by RRC. E-DPCCH has a xed 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.
8.8. CHANNELS AND PHYSICAL LAYER 263
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-
ties the transport block size on E-DCH (7 bits). SRNC signals which E-DCH
Transport Block Size table should be used by the UE
5
.
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 eld 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 satised (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 buer 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 congurable parameter.
5
3GPP TS 25.321, annexure B shows all the tables for E-DCH FDD mode.
If the UE is congured with E-TFCI table 0 and 2ms TTI, use Annex B.1
If the UE is congured with E-TFCI table 1 and 2ms TTI, use Annex B.2
If the UE is congured with E-TFCI table 2 and 2ms TTI, use Annex B.2a
If the UE is congured with E-TFCI table 3 and 2ms TTI, use Annex B.2b
If the UE is congured with E-TFCI table 0 and 10ms TTI, use Annex B.3
If the UE is congured with E-TFCI table 1 and 10ms TTI, use Annex B.4
264 CHAPTER 8. HIGH SPEED UPLINK PACKET ACCESS
Slot format #i Channel Bit
Rate (kbps)
Channel Symbol
Rate (ksps)
SF Bits/ E-DPDCH
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 xed
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:
8.8. CHANNELS AND PHYSICAL LAYER 265
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 eld indicates the maximum E-DCH trac 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 eld is 5 bits.
Absolute Grant =
P
tx,E-DPDCH
P
tx,DPCCH
Absolute Grant Scope, 1 bit: This eld indicates the applicability of the Absolute
Grant. It can take two dierent values, Per HARQ process or All HARQ pro-
cesses, allowing to indicate whether the HARQ process activation/de-activation
266 CHAPTER 8. HIGH SPEED UPLINK PACKET ACCESS
will aect one or all processes. The Absolute Grant Scope is encoded in 1 bit.
When the E-DCH is congured 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 xed
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.
E-RGCH transmission on 12 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 10 ms.
E-RGCH transmission on 15 slots: Used on an E-RGCH transmitted to UEs for which
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 UEs 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 denition,
there can only be one serving relative grant command received at any time. This
indication can take three dierent values, UP, DOWN or HOLD.
8.8. CHANNELS AND PHYSICAL LAYER 267
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 denition, there could be multiple non-serving relative grant
commands received by MAC at any time. This indication can take two dierent
values, DOWN or HOLD.
Figure 8.12: Subframe Structure of E-RGCH & E-HICH
The sequence b
i,0
, b
i,1
. . . , b
i,39
is calculated as
[b
i,0
, b
i,1
. . . , b
i,39
] = a [40 bit long Signature Sequence], where:
a =
Cch,256,33 if N
Max, DPDCH
= 0,
Cch,256,64 if N
Max, DPDCH
= 1,
Cch,256,1 if N
Max, DPDCH
= 2, 4, 6
Cch,256,32 if N
Max, 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 rst two cases are
popularly used. N
Max, DPDCH
= 0 is possible if the L3 signalling (SRBs)
are mapped on HSPA.
HS-DPCCH shall be mapped to the I-branch in case N
Max, DPDCH
is 2, 4 or 6, and
to the Q-branch otherwise (N
Max, DPDCH
= 0, 1, 3 or 5).
4. Code Allocation for E-DPCCH: Now its 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 xed rate channel which always uses SF =256. According to 3GPP
TS 25.213, the DPCCH is always spread by code cc = C
ch,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 N
Max, 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 N
Max, DPDCH
E-DPDCH
k
Channelization Code C
ed,k
0 E-DPDCH
1
C
ch, SF, SF/4
if SF 4
C
ch, 2, 1
if SF = 2
E-DPDCH
2
C
ch, 4, 1
if SF = 4
C
ch, 2, 1
if SF = 2
E-DPDCH
3
C
ch, 4, 1
E-DPDCH
4
1 E-DPDCH
1
C
ch, SF, SF/2
E-DPDCH
2
C
ch, 4, 2
if SF = 4
C
ch, 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 dierent 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 xed 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 xed to
Cch,256,1. This rule is specied is also specied 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 xed 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 xed 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
conguration, 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 Reconguration,
etc.
8.13.2 HSDPA-related DL Channels
1. HS-SCCH: 3GPP has xed 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 conguration
& 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 Reconguration, etc. are used to inform UE about the operator-
dened cell-specic 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 Bs 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
In order to create some gures, tables and text-sections, the following reference material
has been used. Information has been interpreted and presented in a simplied manner.
The original references are provided here.
Main reference material for this book has been technical specications (TSs) and technical
reports (TRs) of 3rd Generation Partnership Project (3GPP).
Figure 8.24 on page 289 Figure 1 of 3GPP TS 25.213 v 8.4.0.
Table 8.11 on page 291 Table 1E of 3GPP TS 25.213 v 8.4.0.
Text about DPCCH/DPDCH
channelization codes on page 289
Section 4.3.1.2.1 of 3GPP TS 25.213 v 8.4.0.
Text about HS-DPDCH channel-
ization codes on page 289
Section 4.3.1.2.2 of 3GPP TS 25.213 v 8.4.0.
Text about E-DPCCH/E-
DPDCH channelization codes on
page 290
Section 4.3.1.2.3 of 3GPP TS 25.213 v 8.4.0.
Text about channelization codes
of R99 DL channels on page 291
Section 5.2.1 of 3GPP TS 25.213 v 8.4.0.
Text about channelization codes
of HSDPA DL channels on page
292
Section 5.2.1 of 3GPP TS 25.213 v 8.4.0.
Text about channelization codes
of HSUPA DL channels on page
292
Section 5.2.1 of 3GPP TS 25.213 v 8.4.0.
c 2009. 3GPP
TM
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 modications and are therefore provided to you as is for information
purposes only. Further use is strictly prohibited.
BIBLIOGRAPHY
[1] 3GPP TS 25.211 ver. 6.0.0 ;Physical channels and mapping of transport channels
onto physical channels (FDD)
[2] 3GPP TS 25.212 ver. 6.0.0 ;Multiplexing and Channel Coding (FDD)
[3] 3GPP TS 25.213 ver. 6.0.0 ;Spreading and Modulation (FDD)
294
CHAPTER
9
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 Lets 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 dene 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 connection
1
.
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. RNCs admission
control has the authority to setup or reject the RRC connection request. The signalling
ow is illustrated in gure 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 dene RRC Connection as a signalling building block
only. A more detailed description of RRC Connection establishment is available in section
9.2.
298 CHAPTER 9. SIGNALLING
9.1.2 Radio Access Bearer (RAB)
According to 3GPP TR 21.905 which contains a vocabulary for 3GPP Speci-
cations, 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 rst 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 dene 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 denes the quality of service for the
user data stream between UE and RNC. If we study the Radio Bearer care-
fully, we can nd the conguration of all protocol layers of radio protocols e.g.,
PDCP, RLC, MAC and Physical layers.
According to 3GPP TR 21.905, Radio Bearer is dened 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.
9.1. BUILDING BLOCKS OF 3G SIGNALLING 299
Figure 9.2: Radio Access Bearer
The same situation has been illustrated in gure 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 congu-
ration of Physical, MAC, RLC and PDCP layer using RRC: RADIO BEARER SETUP
message. During the connection, if RNC decides to modify the current conguration, it
sends RRC: RADIO BEARER RECONFIGURATION message to UE. As shown in gure
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/Modication
9.1.4 Radio Link
By denition, Radio Link is the logical name given to the association between
a single user and single Node B. During soft-handover, UE can maintain
300 CHAPTER 9. SIGNALLING
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 gure 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 Reconguration
An example of this is shown in the right sub-gure in gure 9.4. In this gure, the
procedure of Synchronised Radio Link Reconguration 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 conguration must be modied. This procedure gets completed in three messages:
1. Radio Link Reconguration Prepare
2. Radio Link Reconguration Ready
9.1. BUILDING BLOCKS OF 3G SIGNALLING 301
3. Radio Link Reconguration 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 deni-
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
gure 9.5 elaborate this concept.
For example, CM: Service Request is a message which UE sends to MSC in order to request
for a specic 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.
302 CHAPTER 9. SIGNALLING
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 HSPA
2
. 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
identiers 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-
304 CHAPTER 9. SIGNALLING
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 SETUPmessage
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 noties 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
specied 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 benecial for the
operator because it brings resource eciency 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-
ecient 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 reconguration 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 oered 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.
306 CHAPTER 9. SIGNALLING
9.3 Mobile Originated Voice Call Establishment
Source:
Chris Johnson, Radio Access Networks For UMTS ; Principles And
Practice , John Wiley & Sons.
3G has improved the end-user experience of high bit rate data services but voice is still the
most important service oered by mobile operators. In this section, we will understand
the signalling ow of a Mobile Originated CS conversational voice call setup. If the
readers are familiar with the call ow of GSM, they should compare the GSM call ow
with UMTS CS call ow and nd out the similarities and dierences. 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 dierent in comparison
to 2G call ow.
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
4. Phase 4: Signalling between UE & CN
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 rst NAS message is CM: Service Request. This NAS message is
carried by two access stratum (AS) protocols RRC and RANAP, as shown in
gure9.8. When the rst 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 conrms 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
308 CHAPTER 9. SIGNALLING
setup of an Iu-CS connection by sending SCCP: CONNECTION CONFIRM
message. SCCP connection is identied 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 UEs 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, RNCs 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 briey 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 trac, radio
link must be recongured. The procedure has been illustrated in gure 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
oset etc. At this point, RNC informs Node B about the Connection Frame
Number (CFN) where the modied 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 conguration 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 message
3
. 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 partys 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 ow because up to this point,
UE is assigned resources for only DCCH and after this point, DTCH can also be sent/received by
UE.
310 CHAPTER 9. SIGNALLING
9.4 Mobile Terminated Voice Call Establishment
Source:
Chris Johnson, Radio Access Networks For UMTS ; Principles And
Practice , John Wiley & Sons.
When we compare the gure 9.9 showing the call ow for Mobile Terminated CS con-
versational voice call setup with gure 9.8 showing the same for mobile originated call
ow, it is obvious that there are a lot of similarities but there are some dierences too.
In this section, we will investigate the signalling for an incoming call by focussing on the
serving-MSC, SRNC and the called party
4
.
Similar to the example of mobile-originated-call, we will divide the whole procedure into
phases to simplify the learning:
1. Phase 1: Paging
2. Phase 2: RRC Connection Establishment
3. Phase 3: Signalling between UE & CN
4. Phase 4: RAB Setup
5. Phase 5: Signalling between UE & CN
The rst dierence 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 reporting
5
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 subscribers 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
Networks For UMTS; Principles And Practice by Chris Johnson
312 CHAPTER 9. SIGNALLING
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 specied 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 rst NAS message is CM: PAGING RESPONSE. This NAS message
is carried by two access stratum (AS) protocols: RRC and RANAP, as shown
in gure 9.9.
Similar to the MOC case, when the rst 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 dierence
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 ash
on the UEs 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 dierence 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 nally 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 trac can be transported in both directions.
314 CHAPTER 9. SIGNALLING
9.5 PS Data Session Setup
Source:
Chris Johnson, Radio Access Networks For UMTS ; Principles And
Practice , John Wiley & Sons.
The packet session setup is also similar to voice call setup up to some extent. But
there are some signicant dierences 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 dierentiate 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
1. Phase 1: RRC Connection Establishment
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 dened in 3GPP TS 25.331 specication. The
terminology used by core network specications and radio specication is slightly
dierent. 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 rst NAS message arrives at RNC, it triggers the
setup of an SCCP connection between RNC and SGSN. Figure 9.10 shows two
dierent scenarios.
1. In the left sub-gure, the UE is not yet registered in SGSN and it performs
PS data session setup.
2. In the right sub-gure, 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.
316 CHAPTER 9. SIGNALLING
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 prole 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 conguration 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 dierent 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
gure 9.11). This scheme reduces the connection establishment delay. In this
strategy, RNC makes the decision about using DPH, HSDPA or HSPA cong-
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 RNCs 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 identied by a RAB-id which is exactly the same as
NSAPI used in the PDP context phase. Other important parameters in this message
are:
Trac class,
9.5. PS DATA SESSION SETUP 317
Figure 9.11: PS session setup with direct resource allocation; Source: Radio
Access Networks For UMTS; Principles And Practice by Chris Johnson
318 CHAPTER 9. SIGNALLING
Symmetrical or asymmetrical,
maximum
6
UL & DL bit rate,
Acceptable error ratios,
Trac Handling Priority, (THP) (only for Interactive trac 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 RNCs parameters.
3. NBAP signalling between Node B and RNC takes place to recongure 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 conguration for the particular RAB and the activation time. If the HS-
DSCH transport channel has been selected in DL, the HSDPA-specic user identity
H-RNTI is allocated to user. Similarly, if E-DCH transport channel has been selected
in UL, HSUPA specic 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 specic 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.
9.5. PS DATA SESSION SETUP 319
Phase 4; Option 2: First Zero Bit rate bearer and later
resource allocation
As explained earlier, RNC of some equipment vendors act dierently 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 reconguration 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 gure 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 conguration is always dedicated
channel (DCH).
Afterwards, UE is informed about the minimum threshold of trac 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.
320 CHAPTER 9. SIGNALLING
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 dierent Node Bs but controlled by the same RNC.
9.6. SOFT HANDOVER 321
3. belong to two dierent Node Bs and dierent RNCs & with Iur interface between
the two RNCs.
4. belong to two dierent Node Bs and dierent 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 rst 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 ow for the same example is illustrated in gure 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 1A
7
. The signalling scenario is briey 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, RNCs admission control decides
whether the new radio link can be added to the active set or not.
7
Denition of event 1A: P-CPICH of a neighbour cell enters the reporting range.
322 CHAPTER 9. SIGNALLING
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 noties 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 oset. 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
324 CHAPTER 9. SIGNALLING
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
gure 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-
ties 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.
326 CHAPTER 9. SIGNALLING
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 dierent 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
gure 9.18. In order to simplify the picture, Node Bs and Iub signalling is not shown in
this gure. Lets break down this procedure in several steps.
STEP 1: For UE, its 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 cells Ec/No becomes better than the E/No of the source cell by a
predened margin, RNC decides to perform Hard Handover and SRNS relocation.
Step 2: Since, the 2 RNCs 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 gure 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.
328 CHAPTER 9. SIGNALLING
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 conguration 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
Chris Johnson, Radio Access Networks For UMTS ; Principles And
Practice , John Wiley & Sons.
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 Lets 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 ow
of this procedure is broken down into two parts shown in gure 9.19 and gure 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
3. Phase 3: Measurement Reports (UE to RNC)
4. Phase 4: Compressed Mode measurements for BSIC verication
5. Phase 5: Measurement Reports (UE to RNC)
6. Phase 6: HO decision
7. Phase 7: Signalling between SRNC & BSC
8. Phase 8: Communication between UE and GERAN
9. Phase 9: Conrmation 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
330 CHAPTER 9. SIGNALLING
Figure 9.19: Inter System HO Signalling - UTRAN Part; Source: Radio Access
Networks For UMTS; Principles And Practice by Chris Johnson
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 dened event
1F which gets triggered whenever the P-CPICH of an active set cell falls below a
9.9. CS INTER-SYSTEM HANDOVER (3G TO 2G) 331
certain threshold. Please refer to section 5.8.3 and gure 5.21.
Whenever a P-CPICH of an active set falls below the parameter dened 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 RNCs 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 gure 9.19.
1. NBAP: RADIO LINK RECONFIGURATION PREPARE message con-
tains important parameters related to compressed mode conguration
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 congured, one for UMTS inter-frequency mea-
surements, one for GSM RSSI measurements and one for GSM BSIC ver-
ication. 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 conguration 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 Reconguration Commit message.
2. RRC: MEASUREMENT CONTROL message is used to congure
GSM RSSI measurements. In this message, RNC species whether BSIC
verication is required at this stage or not. In our signalling example,
BSIC verication is not performed at this stage. Each neighbour is identi-
ed 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).
332 CHAPTER 9. SIGNALLING
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 predened interval. Each report contains information about BCCH RSSI and
non-veried BSIC of 6 strongest GSM neighbours.
Phase 4: Compressed Mode measurements for BSIC verication: There needs to
be some modication in the compressed mode conguration for BSIC verication
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 Conguration Change CFN : This parameter de-
nes the radio frame during which the Node B stops using the active
TGPS.
2. The Transmission Gap CFN : This parameter denes the radio frame
in which the new TGPS will become active. New means the sequence
dened 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 veried BSIC of the GSM neighbours dened in measurement control
message.
Phase 6: HO decision in SRNC: If a GSM cell is reported by UE whose BSIC has
been veried 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 gure 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)
9.9. CS INTER-SYSTEM HANDOVER (3G TO 2G) 333
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 sucient information to continue its speech connection
on GSM, such as
BSIC (BCC & NCC) and BCCH Carriers ARFCN
Time slot #, hopping information, channel conguration, 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.
334 CHAPTER 9. SIGNALLING
Phase 9: Conrmation 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 simplied 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 calledIu 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
dierent 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 nding 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 time
9
.
9
Activation time is optional parameter, default is now
336 CHAPTER 9. SIGNALLING
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 UEs 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 buering. 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 subscribers 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 buered 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.
338 CHAPTER 9. SIGNALLING
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. Lets 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 gure 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 gure 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 ecient 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
340 CHAPTER 9. SIGNALLING
unacknowledged data which is buered at Node B can be transmitted to the user
using new radio link. There is no need to ush the data in MAC-hs buer. Intra-
Node B SCC has less interruption in service. An example of Intra-Node B SCC is
illustrated in gure 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 dierent Node Bs. There-
fore, when the user moves into the new cell, the unacknowledged MAC-hs buer
data at the old Node B must be ushed 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 gure 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 conguration 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.
9.11. HSDPA MOBILITY 341
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 dierence is that the source
and the target HS-DSCH cells are controlled by two dierent 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.
342 CHAPTER 9. SIGNALLING
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 reconguration 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 reconguration 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 dierent RNCs then the
situation becomes even more complex and more interesting. The implementation very
much depends on the vendors 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 dierence 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 reconguration 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 congured on DCH or E-DCH
transport channels.
DCH to HS-DSCH Switch
A radio bearer reconguration from DCH to HS-DSCH can be triggered by various reasons.
Some of them are listed below:
9.11. HSDPA MOBILITY 343
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 recongured 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 nding 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 recongured. Radio bearer is mapped to HS-DSCH.
After successful reconguration, the DCH resources are released and HS-DSCH-specic
measurements are congured in the UE.
HS-DSCH to DCH Switch
A radio bearer reconguration 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 conguration 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 recongured and Radio bearer is mapped to DCH. In the second phase, resources for
HS-DSCH are released & DCH-specic measurements are congured 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:
344 CHAPTER 9. SIGNALLING
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 conguration, 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 congured 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 dierent E-DCH active set and DCH active set. Although the concept
of handover is same but it should be possible to keep dierent parameter sets for intra-
frequency measurements for DCH and E-DCH soft handover. Operators dene dierent
parameter sets and assign one set each for various service. For example, operators can
keep dierent 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 ows are congured 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 congured on E-DCH, DL must be HS-DSCH.
If the UL is on DCH, then DL can be congured on either HS-DSCH or DCH
transport channels.
346 CHAPTER 9. SIGNALLING
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 recongured 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 congured 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 dened 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 inecient. 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.
9.12. HSUPA MOBILITY 347
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 predened 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 conguration, measure-
ments can be performed without channel type switching to DCH.
348 CHAPTER 9. SIGNALLING
Copyright Notices
In order to create some gures, tables and text-sections, the following reference material
has been used. Information has been interpreted and presented in a simplied manner.
The original references are provided here.
Main reference material for this book has been technical specications (TSs) and technical
reports (TRs) of 3rd Generation Partnership Project (3GPP).
Figure 9.21 on page 336 Figure 54 of 3GPP TS 23.060 v 6.0.0.
Text in section 9.10 on page 335 Section 6.13.2 of 3GPP TS 23.060 v 6.0.0.
c 2003. 3GPP
TM
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 modications and are therefore provided to you as is for information
purposes only. Further use is strictly prohibited.
Figure 9.22 on page 338 Figure 9.1-1 of 3GPP TS 25.308 v 6.3.0.
Figure 9.24 on page 340 Figure 9.3-1 of 3GPP TS 25.308 v 6.3.0.
Figure 9.25 on page 341 Figure 9.5-1 of 3GPP TS 25.308 v 6.3.0.
c 2004. 3GPP
TM
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 modications and are therefore provided to you as is for information
purposes only. Further use is strictly prohibited.
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.
Figure 9.4 on page 300 Figure 24 of 3GPP TS 25.433 v 7.0.0.
c 2006. 3GPP
TM
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 modications and are therefore provided to you as is for information
purposes only. Further use is strictly prohibited.
9.12. HSUPA MOBILITY 349
Text in section RRC Connection
on Dedicated Channels on page
302
Section 7.3.1 of 3GPP TR 25.931 v 8.0.0.
Figure 9.5 on page 301 Figure 7 of 3GPP TR 25.931 v 8.0.0.
Figure 9.6 on page 303 Figure 8 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.
Figure 9.20 on page 333 Figure 36 of 3GPP TR 25.931 v 8.0.0.
c 2008. 3GPP
TM
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 modications and are therefore provided to you as is for information
purposes only. Further use is strictly prohibited.
BIBLIOGRAPHY
[1] 3GPP TR 21.905 ver. 8.0.0 ;Vocabulary for 3GPP Specications
[2] 3GPP TS 23.060 ver. 6.0.0 ;General Packet Radio Service (GPRS); Service descrip-
tion
[3] 3GPP TS 25.301 ver. 7.0.0 ;Radio Interface Protocol Architecture
[4] 3GPP TS 25.308 ver. 7.0.0 ;High Speed Downlink Packet Access (HSDPA); Overall
description;
[5] 3GPP TS 25.319 ver. 7.0.0 ;High Speed Uplink Packet Access (HSUPA); Overall
description
[6] 3GPP TS 25.214 ver. 7.0.0 ;Physical Layer Procedures (FDD)
[7] 3GPP TS 25.331 ver. 7.0.0 ;Radio Resource Control (RRC) protocol specication
[8] 3GPP TS 25.401 Ver. 7.0.0 ;UTRAN overall description
[9] 3GPP TS 25.413 Ver. 7.0.0 ;UTRAN Iu Interface: RANAP Signalling
[10] 3GPP TS 25.433 Ver. 7.0.0 ;UTRAN Iub Interface: NBAP Signalling
[11] 3GPP TS 25.308 ver. 7.0.0 ;High Speed Downlink Packet Access (HSDPA); Overall
description;
[12] 33GPP 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] H.Holma and A. Toskala, HSDPA/HSUPA for UMTS , 1st Edition, John Wiley
& Sons.
[15] Chris Johnson, Radio Access Networks For UMTS ; Principles And Prac-
tice , John Wiley & Sons.
350
CHAPTER
10
SELF TEST
In the 9 modules of this book, we learnt the essential concepts about UMTS and HSPA.
In this nal 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 SDOs
1
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 rst
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:
354 CHAPTER 10. SELF TEST
10.2 Module 2
Question 2.1: According to the original GSM network architecture, the fol-
lowing subsystems are dened.
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 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:
358 CHAPTER 10. SELF TEST
Question 3.6: Two Voice users in the same WCDMA cells must use dierent
combination of channelization and scrambling codes.
From the list below, select the two codes that must be dierent?
1. Channelization Codes in UL
2. Channelization Codes in DL
3. Scrambling Codes in UL
4. Scrambling Codes in DL
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.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 dierent.
What is the reason for it?
1. Channel coding rate is dierent in UL & DL
2. Modulation Scheme is dierent in UL & DL
3. UL & DL use two dierent types of Spreading codes
4. The rate dierence 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:
362 CHAPTER 10. SELF TEST
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.3: When does the admission control algorithm in UMTS get in-
voked?
Name any 3 scenarios.
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:
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.10: Which event is used to inform RNC that compressed mode
measurements can be aborted because UE is again in suitable 3G cover-
age?
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 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 dene the Quality of
Service between:
Choose 1 answer:
1. UE & Node B
2. UE & RNC
3. UE & Core Network
4. UE & External Server
368 CHAPTER 10. SELF TEST
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 7.2: RNC forwards the buered 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.5: Very smart re-transmission techniques are used in HSDPA (&
HSUPA):
Name the two H-ARQ schemes dened for HSDPA.
Correct Answer:
Question 7.6: Match the name of HSDPA-specic physical channel with their
spreading factor.
Name of Physical
Channel
Spreading Factor
1. HS-DPCCH
2. HS-SCCH
3. HS-PDSCH
i. 16
ii. 256
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 benet 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.
372 CHAPTER 10. SELF TEST
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
2. E-DCH
3. HS-PDSCH
i. 2 ms
ii. 10 to 80 ms
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 dened by 3GPP.
1. 10
2. 20
3. 40
4. 72
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:
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 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
3GPP Releases, 18, 20, 22
R99 to REL-10, 19
3rd Generation Partnership Project (3GPP),
14
3rd Generation Partnership Project 2 (3GPP2),
15
4 Pulse Amplitude Modulation (4PAM, 253,
261, 262
64QAM, 21, 22, 207, 214, 230232, 237
, 20, 39
Absolute grant, 264, 268
Acquisition indication channel (AICH), 76,
99, 102, 146
Adaptive Modulation and Coding, 211, 247
Admission control, 45, 118, 119, 126, 129,
130, 159
ALCAP, 172, 174, 304, 323
AMPS, 4
Authentication Center, 31
Background class, 178
Base Station Subsystem, 26
BCCH, 84, 85, 87, 99
Binary Phase Shift Keying (BPSK), 79, 247,
253, 261, 262, 264
BSS, 27
BTS, 28
Call State Control Function (CSCF), 55
Interrogating - , 56
Proxy - , 56
Serving - , 56
CAMEL, 33
CCCH, 85, 93, 197, 302
Cell search, 109
CELL DCH, 138
Cell DCH, 139
CELL FACH, 138
Cell FACH, 139143
CELL PCH, 138
Cell PCH, 139, 142, 143
Channel Quality Indicator (CQI), 137, 206,
207, 213216, 224, 226, 228
Channelization code, 72, 73, 88, 98, 117,
133, 134, 232, 234, 262, 267, 291,
292, 303
compressed mode, 166
Conversational class, 177
Core Network, 26
CTCH, 85
DCCH, 85, 250, 251, 297, 302, 304, 309
378
INDEX 379
DECT, 17
Dedicated physical channel for HSDPA, 134,
226, 290
DTCH, 85, 86, 93, 135, 250, 251, 309
Dual-Carrier HSDPA, 212
Dual-Carrier HSUPA, 22, 253
E-DCH Absolute Grant Channel (E-AGCH),
264, 268, 277, 292
E-DCH Hybrid-ARQ Indication Channel (E-
HICH), 267, 268, 270, 274, 281, 282,
292
E-DCH Relative Grant Channel (E-RGCH),
266268, 274, 277, 292
E-DCH Transport Format Combination In-
dicator (E-TFCI), 263
EIR, 31
Enhanced Cell FACH, 21
Enhanced Data rates for GSM Evolution (EDGE),
9
Event
1A, 158
1B, 159
1C, 160
1E, 163
1F, 162
2A-2F, 164
3A-3D, 165
First Generation (1G), 4
Frame synchronization, 109
Gateway GPRS Support Node, 39, 41, 58
General Packet Radio Service (GPRS), 9
GMSC, 29
GSM, 5
Handover, 28, 118, 154
Hard, 47, 155
Inter-frequency, 156
Inter-System, 156
Intra-frequency, 155
Soft, 48, 155
Softer, 155
High Speed Circuit Switched Data (HSCSD),
8
High Speed Downlink Shared Channel, 232
High Speed-Physical Downlink Shared Chan-
nel, 228, 229, 232, 292
HSDPA, 1922, 54, 68, 83, 111, 118, 134,
135, 137, 204, 205, 209, 211, 213,
221, 224226, 245248, 251, 273, 292
HSPA, 295
HSUPA, 21, 83, 113, 118, 137, 206, 207, 245,
247, 248, 251, 253, 254, 292
IMEI, 27, 31
IMSI, 27
IMT-2000, 66
Interactive class, 178
IP Multimedia Subsystem (IMS), 55
IS-95, 6
Macro Diversity Combining, 157
MC-CDMA or CDMA2000, 17
MDC, 157
Medium Access Control (MAC), 86
Mobile Station, 26
MSISDN, 27
Open Loop Power Control, 93
P-CPICH, 90
PCCH, 85, 88
Physical Channels, 88
Physical layer, 89
Pilot bits, 154
Primary Synchronization Codes (PSC), 95
Radio Access Bearer, 296
Radio Bearer, 296
Radio Link, 296
Radio Network Temporary Identity
Cell, C-RNTI, 303
E-DCH, E-RNTI, 264
HS-DSCH, H-RNTI, 231
UTRAN, U-RNTI, 303
Radio Resource Management (RRM), 117
RRC Connection, 296
380 INDEX
RRM, 118, 121123, 126, 133, 134, 144, 155,
259
Scrambling code, 73, 75, 76, 79, 88, 96, 98,
109, 110, 117, 125, 132134, 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, 230232, 292
SIB, 99
SIM, 27
Slot synchronization, 109
Streaming class, 178
Switching Subsystem, 26
TFCI, 106
Third generation (3G), 11
Trac 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
Zero
th
Generation (0G), 4