PS Call Management

PS call management
Document number:
Document issue:
Document status:
Date:
UMT/SYS/DD/0034
07.03 / EN
Standard
16/APR/2008
External document
Copyright 2007 Alcatel-Lucent, All Rights Reserved

Printed in France
UNCONTROLLED COPY: The master of this document is stored on an electronic database and is write
protected; it may be altered only by authorized persons. While copies may be printed, it is not recommended.
Viewing of the master electronically ensures access to the current issue. Any hardcopies taken must be regarded
as uncontrolled copies.
ALCATEL-LUCENT CONFIDENTIAL: The information contained in this document is the property of AlcatelLucent. Except as expressly authorized in writing by Alcatel-Lucent, the holder shall keep all information
contained herein confidential, shall disclose the information only to its employees with a need to know, and shall
protect the information from disclosure and dissemination to third parties. Except as expressly authorized in
writing by Alcatel-Lucent, the holder is granted no rights to use the information contained herein. If you have
received this document in error, please notify the sender and destroy it immediately.
PS call management
PUBLICATION HISTORY
16/APR/2008
Update 07.03 / EN, Standard
Update for standard Status
26/FEB/2008
Update 07.02 / EN, Preliminary
Update after review
18/JAN/2008
Feature PM34227 added for release UA06.0
Updated handling of SRB over E-DCH for UA06.0
12/DEC/2007
Update for standard Status
05/DEC/2007
Update on UA06 features
05/Oct/2007
Update after review
27/Jul/2007
Introduction of UA06 features
12/Jul/2006
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 3/84
PS call management
27/Jun/2006
Misc corrections
21/Jun/2006
Misc corrections/improvements
Removal of PS RAB modification
RB adaptation
13/Apr/2006
Update 05.01 / EN, Draft
Misc editorial corrections/improvements
Removal of support for Cell-DCH 8/8 in AO step 1 (308097)
Feature content from Enhanced iRM for high quality Streaming (29400):
Disabling AO for a PS Interactive RAB if the Signaling Indicator is set

to yes.
New streaming related multi-service combinations/transitions.
PS RAB Modification
Feature content from Cell/URA PCH (26673/26675)
Interactions with AO, and the triggering criteria for moving to the PCH
states due to AO.
5/Apr/2006
Creation 05.00 / EN, Draft
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 4/84
PS call management
CONTENTS
CONTENTS..............................................................................................................................................5
1.
2.
3.
INTRODUCTION............................................................................................................................8
1.1.
OBJECT ....................................................................................................................................8
1.2.
SCOPE OF THIS DOCUMENT .......................................................................................................8
1.3.
AUDIENCE FOR THIS DOCUMENT ................................................................................................8
1.4.
DEFINITIONS AND SPECIFICATION PRINCIPLES ............................................................................9
RELATED DOCUMENTS ..............................................................................................................9

2.1.
APPLICABLE DOCUMENTS ..........................................................................................................9
2.2.
REFERENCE DOCUMENTS ........................................................................................................10
HSDPA/E-DCH ............................................................................................................................10
3.1.
BACKGROUND ........................................................................................................................10
3.2.
SRB ON E-DCH.....................................................................................................................11
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
4.
E-DCH CONFIGURATION............................................................................................11
SRB MATCHING...........................................................................................................11
Mobility ..........................................................................................................................12
Parameters....................................................................................................................12
Counters........................................................................................................................14
RB ADAPTATION BASED ON TRAFFIC ...................................................................................14

4.1.
APPLICABILITY ........................................................................................................................15
4.2.
PRINCIPLE ..............................................................................................................................15
4.2.1
Overview .......................................................................................................................15
4.2.2
RB adaptation................................................................................................................17
4.2.3
Traffic monitoring ..........................................................................................................22
4.3.
PARAMETERS .........................................................................................................................24
5.
4.4.
COUNTERS .............................................................................................................................26
4.5.
INTERWORKING WITH OTHER FEATURES ...................................................................................28
ALWAYS-ON ...............................................................................................................................29
5.1.
TRANSITIONS OVERVIEW ..........................................................................................................31
5.2.
AO STEP 1 IN CELL-FACH .....................................................................................................35
5.2.1
Principle.........................................................................................................................35
5.2.2
mobility impact...............................................................................................................36
5.2.3
Decision to change rate ................................................................................................36
5.2.4
transition process ..........................................................................................................38
5.2.5
Parameters....................................................................................................................40
5.3.
CELL/URA PCH RELATED STATE TRANSITIONS ..........................................................................41
5.3.1
parameters ....................................................................................................................46
5.3.2
counters.........................................................................................................................46
5.4.
"PMM-IDLE" STATE TRANSITION ..............................................................................................47
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 5/84
PS call management
5.4.1
Principle.........................................................................................................................47
5.4.2
Decision for PMM-Idle transition ...................................................................................48
5.4.3
Transition to PMM-IDLE mode......................................................................................49
5.4.4
Uplink data traffic resuming...........................................................................................51
5.4.5
Downlink data traffic resuming ......................................................................................51
5.4.6
Parameters....................................................................................................................52
5.5.
CASE OF SIMULTANEOUS CS & PS SERVICES...........................................................................53
5.5.1
Principle.........................................................................................................................53
5.5.2
RRC State transitions in multiservice............................................................................55
5.5.3
Parameters....................................................................................................................57
5.6.
AO COUNTERS ........................................................................................................................57
6.
MULTIPLE PS I/B RAB SUPPORT.............................................................................................58

6.1.
INTRODUCTION .......................................................................................................................58
6.2.
CALL STATE TRANSITIONS .......................................................................................................59
6.2.1
Overview .......................................................................................................................59
6.2.2
Activation/de-activation of PDP context ........................................................................60
6.3.
MAC SCHEDULING ..................................................................................................................62
6.4.
INTERWORKING WITH ALWAYS-ON ...........................................................................................63
6.4.1
Principle.........................................................................................................................63
6.4.2
PMM-Idle transition .......................................................................................................63
6.4.3
Resuming user traffic ....................................................................................................64
6.4.4
Always-On and 1 RAB/2 RAB transitions .....................................................................65
6.5.
INDIVIDUAL RAB RELEASE .......................................................................................................66
6.5.1
Overview .......................................................................................................................66
6.5.2
Individual RAB Release ................................................................................................66
6.5.3
Reactivation Following Individual RAB Release ...........................................................69
6.5.4
SGSN Considerations for Individual RAB Release.......................................................71
6.6.
INTERWORKING W ITH RB ADAPTATION ....................................................................................71
7.
8.
6.7.
COUNTERS .............................................................................................................................72
6.8.
SPECIFIC PARAMETERS ...........................................................................................................72
HANDLING OF STREAMING RAB.............................................................................................74

7.1.
OVERVIEW ..............................................................................................................................74
7.2.
MULTIPLE STREAMING RATES ...................................................................................................75
7.3.
MULTI-SERVICE STREAMING SUPPORT ......................................................................................75
7.4.
ENHANCED HANDLING OF STREAMING RAB ................................................................................77
7.5.
FEATURE INTERWORKING ........................................................................................................77
STATE TRANSITIONING ENHANCEMENT [USA MARKET] ...................................................78

8.1.
RB ADAPTATION ENHANCEMENTS ............................................................................................78
8.1.1
parameters ....................................................................................................................78
8.2.
INITIAL RATE CAPPING .............................................................................................................79
8.2.1
parameters ....................................................................................................................80
8.3.
FACH TO DCH TRANSITION AND EC/IO .......................................................................................81
8.3.1
parameters ....................................................................................................................81
8.4.
RETRANSMISSION RB RECONFIG FOR FACH TO DCH OR PCH .......................................................81
8.4.1
parameters ....................................................................................................................82
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 6/84
PS call management
9.
10.
11.
RNC INITIATED RAB MODIFICATION.......................................................................................82

9.1.
PRINCIPLE ..............................................................................................................................82
9.2.
PARAMETERS .........................................................................................................................82
9.3.
COUNTERS .............................................................................................................................83
FIELD INTRODUCTION ..............................................................................................................83

10.1.
HARDWARE CONSTRAINTS .......................................................................................................83
10.2.
SPARE PART CONSTRAINTS .....................................................................................................83
10.3.
INTER RNS VERSION INTERWORKING ......................................................................................83
10.4.
CORE NETWORK INTERWORKING..............................................................................................84
10.5.
UE INTERWORKING .................................................................................................................84
ABBREVIATIONS AND DEFINITIONS.......................................................................................84

11.1.
ABBREVIATIONS ......................................................................................................................84
11.2.
DEFINITIONS ...........................................................................................................................84
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 7/84
PS call management
1.
INTRODUCTION
1.1.
OBJECT
This document describes how PS calls are handled by Alcatel-Lucent UTRAN.
The 6 main features presented in this document are the following:
HSDPA/E-DCH including SRB on E-DCH
RB adaptation based on traffic
Always-On & CELL_PCH-URA_PCH
Multiple PS RAB
Streaming PS RAB handling
Additional supporting PS call Setup details and data flows are specified in [R1]a.[R2].
1.2.
SCOPE OF THIS DOCUMENT

This document applies to UA06.0 Alcatel-Lucent UTRAN.
The new UA06.0 features covered by this document:
Always On
o
33565 Always-On developments
SRB handling
o
33581 SRB on E-DCH during call
The HSDPA/E-DCH UA06.0 features are covered by documents [R1]a.[R3] and

[R1]a.[R8].
The new UA06.0 features covered by this document:
Multiple PS RAB Support

o
State Transitioning enhancement

o
34227 State Transitioning Enhancement
RNC RAB modification

o
1.3.
34170 3 PDP Contexts support in UTRAN
34226 RNC Initiated RAB Modification
AUDIENCE FOR THIS DOCUMENT

External document
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 8/84
PS call management
1.4.
DEFINITIONS AND SPECIFICATION PRINCIPLES

The present document addresses several markets with potentially different behaviours
in those markets. The definition of Global Market and USA Market are:
Global Market: customers other than those part of the following market.
USA Market: customers with UTRAN where Alcatel-Lucent 939X Node B (former
Lucent Flexent Node B) is deployed.
For the purpose of the present document, the following notations apply:
[Global Market]
This tagging of a word indicates that the word preceding the tag
"[Global Market]" applies only to the Global Market. This tagging
of a heading indicates that the heading preceding the tag
"[Global Market]" and the section following the heading applies
only
to
the
Global Market.
This tagging shall, in particular, be used under the parameter
name of parameters specific to the Global Market.
[USA Market]
This tagging of a word indicates that the word preceding the tag
"[USA Market]" applies only to the USA Market. This tagging of
a heading indicates that the heading preceding the tag "[USA
Market]" and the section following the heading applies only to
the
USA
Market.
This tagging shall, in particular, be used under the parameter
name of parameters specific to the USA Market.
[Global Market - ]
This tagging indicates that the enclosed text following the

"[Global Market -" applies only to the Global Market. Multiple
sequential paragraphs applying only to Global Market are
enclosed separately to enable insertion of USA Market specific
(or common) paragraphs between the Global Market specific
paragraphs.
[USA Market - ]
This tagging indicates that the enclosed text following the "[USA
Market -" applies only to the USA Market. Multiple sequential
paragraphs applying only to USA Market are enclosed
separately to enable insertion of Global Market specific (or
common) paragraphs between the USA Market specific
paragraphs.
Text that is not identified via one of the here above tags is common to all markets.
2.
RELATED DOCUMENTS
2.1.
APPLICABLE DOCUMENTS
[A1]
3GPP TS 34.108
Common test environments for User Equipment
[A2]
3GPP TS 25.413
UTRAN Iu interface RANAP signalling
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 9/84
PS call management
2.2.
[A3]
3GPP TS 25.331
Specification
Radio
[A4]
UTRAN Overall Description
3GPP TS 25.401
Resource
Control
(RRC)
Protocol
[A5]
3GPP 24.008
Network Protocols
Mobile radio interface layer 3 specification; Core
[A6]
3GPP 26.234
Protocols and codecs
End-to-end
transparent
streaming
service;
REFERENCE DOCUMENTS
[R1]
UMT/SYS/DD/0054
UMTS Radio Mobility
[R2]
UMT/SYS/DD/0031
UTRAN Traffic Management
[R3]
UMT/SYS/DD/013319 HSDPA System specification
[R4]
UMT/SYS/DD/0128
intelligent RAB mapping (iRM)
[R5]
UMT/SYS/DD/8326
Radio Bearer Configuration Parameters
[R6]
RFC 2581
TCP Congestion Control
[R7]
UMT/SYS/DD/018826 Call Admission Control
[R8]
UMT/SYS/DD/18827
[R9]
411-8111-822P1 06.02 AN Observation Counters -Volume 1 (RNC

Callp)
[R10]
411-8111-822P2 06.02 AN Observation Counters -Volume 2 (BTS)
[R11]
411-8111-822P3 06.02 AN Observation Counters -Volume 3 (RNC

base)
3.
HSDPA/E-DCH
3.1.
BACKGROUND
E-DCH System Specification
HSDPA provides high DL bit rates for packet applications with the benefit of statistical
multiplexing over a radio interface shared channel (HS-DSCH).
All HSDPA-capable UE (if primary cell is configured with HSDPA) are served with an
HSDPA RB (whenever possible) if they request a mono or multi-service PS I/B RAB.
The UL part of the PS I/B RAB may also be mapped onto either DCH (multi-PS RAB)
or E-DCH (for the case of mono-service RAB and some multi-service CS + PS RAB
combinations).
A detailed description of the HSDPA related capabilities supported by UA06 is
provided in [R3]. Similarly, E-DCH is described in [R8].
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 10/84
PS call management
3.2.
SRB ON E-DCH
3GPP specification allows the usage of 2 SF2 + 2 SF4 in uplink E-DCH only if there is
no UL DPDCH. Therefore SRB shall also be mapped onto an E-DPDCH layer 1. This
configuration is applicable only for single I/B PS RAB (i.e. no CS RAB)
3.2.1 E-DCH CONFIGURATION

The retained configuration is the 3GPP TS 34.108 R6 (Dec 06) configuration, chapter
6.10.2.4.6.2.1.1.1.2. Hereafter is an extract of this configuration:
Higher layer
RLC
MAC
Layer 1
RAB/Signaling RB
SRB #1
SRB #2
SRB #3
Logical channel type
DCCH
DCCH
DCCH
RLC mode
UM
AM
AM
Payload sizes, bit
136
128
128
Max data rate, bps
Depends on UE category and TTI
AMD PDU header, bit
8
16
16
MAC-es multiplexing
4 logical channel multiplexing
MAC-d PDU size, bit
144
MAC-e/es header fixed 18
part, bit
TrCH type
E-DCH
TTI
2 ms
Coding type
TC
CRC, bit
24
The E-DCH will be configured using non-scheduled traffic.
SRB #4
DCCH
AM
128
16
The SRB configuration will be configured on a dedicated Mac-D flow.
3.2.2 SRB MATCHING

At UA06.0 the RNC may be configured to set the SRB over E-DCH. The criteria is
partially hard coded and partially based upon OAM configuration :
SRB over E-DCH may only be selected when all of the RABs are mapped to E-DCH i.e. when a CS call is established, the RNC will reconfigure the SRB back to DCH.
In addition, the following operator preferences may be selected :
Condition
Description of condition
OAM Parameter
Condition 1
Apply SRB over E-DCH only when the UE is a E-DCH

Cat-6 UE
reserved0 Bit 0
Condition 2
Apply SRB over E-DCH only when the UE is mapped to

2 SF2 + 2 SF4 minSF
reserved0 Bit 1
Condition 2
Apply SRB over E-DCH only when the UE is configured

on 2ms TTI
reserved0 Bit 2
i.e. the Cell(s) support 2 ms E-DCH TTI
i.e. the 2 ms E-DCH TTI feature is activated at

RNC level
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 11/84
PS call management
Note : 2ms TTI is only supported on iBTS and xCEM at
UA06.0.
Typically the operator will either configure all conditions to be [Global-Market disabled] or all [USA-Market - enabled].
The conditions for SRB over E-DCH are tested at each RAB establishment, RAB
release or rate adaptation (Always-on, RB rate adaptation ) and the SRB
configuration is aligned according to those criteria.
3.2.3 MOBILITY
As the whole network may not be deployed with NodeB supporting the minimum SF
2 SF2 + 2 SF4, the radio configuration shall be adapted according to the DCH active
set and the E-DCH active set.
The SRB on E-DCH has not induced new criterion for the E-DCH mobility. The SRB
configuration is elected after determination of:
DCH active set
E-DCH active set
E-DCH configuration (2 ms TTI or 10 ms TTI)
In UA06, E-DCH is not supported through Iur. Therefore, SRB on E-DCH through Iur
is not applicable.
3.2.4 PARAMETERS
Name
Object/Class
Description
isSrbOnEdchAllowedWhe
nTrbOnEdch
RadioAccessSer
vice
srbQos.srbSpi
RadioAccessSer
vice
Enable the possibility to map SRB on E-DCH in the

UL for Cat 6 UE, while the call is handling RAB(s)
over E-DCH
SPI used for SRB on E-DCH during a call
The following parameters are fully described on purpose since they may alter the
handling of the SRB on E-DCH is they are not correctly set.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 12/84
PS call management
source
Managed Object
parameter name
category
class
Associated Event
domain
definition
Modification
radioAccessService
Reserved0 bit 0
Reserve
Optional
Range
unit
Initial values
Recommended value
Upgrade rule
Control rule
source
Managed Object
parameter name
category
class
Associated Event
domain
definition
3-a2
Mobility decision taken for the call
RNC
Is SRB on E-DCH for all E-DCH categories?
Bit 0 = 0: E-DCH Cat 6 UE only
[USA-Market - Bit 0 = 1: All E-DCh Categories]
No
Bit: 0 or 1
Kind of Boolean
[Global Market 0] [USA Market 1]
No
Modification
radioAccessService
Reserved0 bit 1
Reserve
Optional
Range
unit
Initial values
Recommended value
Upgrade rule
Control rule
source
Managed Object
parameter name
category
class
Associated Event
domain
definition
3-a2
RNC
Is SRB on E-DCH for all NodeB minSF?
Bit 1 = 0: 2 SF2 + 2 SF4 minSF only
[USA-Market - Bit 1 = 1: All NodeB minSF]
No
Bit: 0 or 1
Kind of Boolean
No
Modification
radioAccessService
Reserved0 bit 2
Reserve
Optional
Range
unit
Initial values
Recommended value
Upgrade rule
Control rule
3-a2
RNC
Is SRB on E-DCH for all E-DCH TTI?
Bit 2 = 0: 2 ms TTI only and 2 ms supported on NodeB
[USA-Market - Bit 2 = 1: Shall be configured on all E-DCH
TTI]
No
Bit: 0 or 1
Kind of Boolean
No
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 13/84
PS call management
3.2.5 COUNTERS
The counter indicates the number of calls
that were configured with SRB on E-DCH
on the cell.
VS.SRBonEdchEnteringCell
The screening criteria aims to

differentiate a successful configuration
due to a mobility action (screening 0) or
a reconfiguration of the call (screening
1)
Descr.: This screening shall be used
Screening 0
when the SRB on E-DCH is entering a
new primary cell. Therefore, it means
that the call was already with SRB on EDCH on the former primary cell.
3GPP: Mobility
First release: UA06
Descr.: This screening shall be used
Screening 1
when the SRB on E-DCH is configured
on the primary cell whereas there is no
primary cell change.
3GPP: CallReconfiguration
First release: UA06
The screening criterion aims to differentiate a successful configuration due to a
mobility action (screening 0) or a reconfiguration of the call (screening 1)
Screening Criteria
The counter indicates the number of calls

that can be candidate for SRB on E-DCH
VS.SRBonEdchEnteringCellAttempt
The screening criteria aims to

differentiate an attempted configuration
(screening 0) and potential configuration
but restricted by an unsuitable
capabilities at cell level (screening 1)
Descr.: Attempted reconfiguration
Screening 0
3GPP: AttemptedReconfiguration
First release: UA06
Descr.: Unsuitable NodeB Capabilities
Screening 1
3GPP: UnsuitableNodeBCapabilities
First release: UA06
The screening criteria aims to differentiate an attempted configuration (screening 0)
and potential configuration but restricted by an unsuitable capabilities at cell level
(screening 1)
Screening Criteria
4.
RB ADAPTATION BASED ON TRAFFIC

This feature provides DCH rate adaptation based on the observed volume of user
traffic for non-real time packet services.
Throughout this section the following definitions will be used:
Requested Maximum Bit Rate: it is the max bit rate requested via the RANAP RAB
assignment request message.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 14/84
PS call management
Reference RB bit rate: The selected bit-rate after initial filtering of the set of
supported RB and the requested value.
Allocated RB bit rate: The currently allocated RB bit rate. It is lower or equal to the
Reference RB bit rate. This is also known as the Granted RB bit-rate.
Targeted RB bit rate: The bit rate that will be allocated if the CAC is successful
4.1.
APPLICABILITY
Service Class
Domain
Behavior
Conversational
CS
Streaming
PS/CS
Not Applicable.
As streaming and conversational traffic classes
require guaranteed bit rates, the RB adaptation
feature is not applicable.
Interactive
PS
Background
PS
Applicable (also applicable when PS I/B RAB is

combined with CS speech or CS data).
For both classes, since the bit-rate is not
guaranteed (neither bit rate nor delay) the RB
adaptation feature is applicable.
This feature does not apply in the following cases:
PS I/B RAB mapped on shared transport
channel (DCH rate adaptation only feature)
[Global Market - Multiple PS I/B RAB
configuration(s)]
Table 1: Service Class Applicability
4.2.
PRINCIPLE
4.2.1 OVERVIEW
Once a service is established, it may happen that the allocated RB bit-rate is not well
shaped (too high or too low) compared to the actual traffic carried over the RAB. This
typically occurs in case of a bursty user traffic and/or when the CN always requests
the subscribed maximum bit rate (e.g. 384 kbit/s), irrespective of the service
requirement.
The Always-On feature is well sized to cope with cases where the application
generates very low traffic or for cases the application may become inactive. Always-on
can be seen as a coarse grain rate adaptation feature, whereas the aim of the RB
adaptation feature is to dynamically adapt the RB bit rate as close as possible to the
real traffic for those services requiring more than the Always-On downsized
configuration but less than the allocated RB.
The RB rate adaptation feature applies to both downlink and uplink. The DL & UL rate
adaptations are performed independently. The RNC monitors the DL & UL traffics and
periodically determines if the current RB needs to be reconfigured to accurately match
the actual traffic. This mechanism works in parallel of the existing Always-On feature
as illustrated in the picture below.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 15/84
PS call management
RB
adaptation
processes
(UL & DL)
384
256
DCH rate adaptation
128
64
8
32
Always-On process
AO step 1 & 2
Cell-FACH/Cell_PCH,
URA-PCH
AO
AO step3
RRC-Idle, PMM-connected
idle
Figure 1: RB adaptation / Always-On inter-working

The RB rate adaptation feature is fully located in the serving RNC and do not interact
with any other UTRAN node. It is based on the two following main functions:
The traffic monitoring function estimates the average throughput of the

service. This function is based on a DL and UL traffic estimators at RLC level.
The RB resizing function determines if the allocated RB bit rate needs to be

adapted (i.e. if an RB reconfiguration is needed).
Although performed independently, DL and UL bit rate adaptation processes are

almost similar, the only differences being that:
The allocation policy of the initial bit rate differs between DL and UL.
o
The initial bit rate is determined according to RAB Matching (which

returns a Reference RB bit rate) and UL/DL iRM (may replace the
Reference RB bit rate by a lower bit rate, based on the criteria
described in [R4].
In DL, the initial bit-rate is capped by a max DL bit-rate rate

(maxDlEstablishmentRbRate), which may be allocated at service
establishment time (RANAP RAB Assignment request), after
relocation (RANAP Relocation request) or after an always-on upsize.
This parameter is significant for Interactive/background traffic.
In UL, the initial bit rate is, in addition, determined according to a preconfigured low bit rate (maxUlEstablishmentRbRate). It is expected
that in many cases the UL traffic should be sporadic, i.e. made of few
packets followed by a large idle period. Allocating a low bit rate
reduces the blocking risk (CAC), while the traffic monitoring function
ensures that if the user actually needs more it can be upsized to a
higher rate.
The DL traffic monitoring function also estimates the RLC-SDU buffer

occupancy in addition to the average throughput.
For the DL multi-stage upsize may apply if the operator allows it and if the
conditions are met in addition to the step-by-step upsize
For the UL only step-by-step upsize applies.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 16/84
PS call management
The DL has priority over the UL and there is no possible simultaneous UL/DL
resize
In case of an RB upsize and downsize, the allocated bit rate cannot exceed the bit
rate provided by iRM table.
In UL and in DL, the downsize targets directly the most adapted RB.
4.2.2 RB ADAPTATION
TRAFFIC MONITORING
Traffic monitoring is a key element in the RB adaptation process efficiency.
For applications generating quite constant bit rate traffic, such as streaming, FTP or
email downloading, a simple monitoring process (e.g. mean bit rate over a non-sliding
time window) would probably be enough.
However, for WAP/Web browsing profile or bursty applications, such a kind of simple
monitoring process may be quite frustrating for the end-user, depending on the
observation time window.
If a too large observation window is used, the RB may possibly be resized to a

low value (e.g. 32/32) thus providing a Quality of Experience (QoE) not better
than GPRS.
On the other hand, a too short window involves much more frequent RB
reconfigurations.
The algorithms are detailed in section 4.2.3.
DL RB ADAPTATION
The figure below illustrates the process of DL RB adaptation, with the Reference and
initial RB bit rate set to 384 kbps (Requested Maximum Bit Rate = 384 kbps /
unloaded cell).
The upsize can be based on two methods:
A step by step upsize: to trigger an RB#n upsize, the calculated average

throughput must be comprised in a range defined by an upper bound
st
Tup(RB#n) and the maximum bit rate of the RB#n. (1 upsize in the figure
hereafter)
A multi stage upsize: to trigger a multistage upsize, the following criteria must
be fulfilled:
o
the average throughput correlated with a confidence level (as the

step-by-step upsize) AND
the RLC-SDU buffer occupancy. (2 upsize in the figure where this

last condition is not fulfilled and therefore the upsize not triggered)
nd
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 17/84
PS call management
Bit rate (kbps)
384
Low RLC-SDU Buffer

Occupancy, thus no Upsize*
Allocated RB bit rate

256
Th-up(256)
Th-down(384)
128
Th-up(128)
Th-down(256)
Real bit rate
time
Legend
Observation duration
RB upsize trigger
RB reconfiguration latency
RB downsize trigger
Th-up (128) and Th-up (256) are configurable thresholds (DlRbRateAdaptationUpsizeThreshold)

Th-down (256) and Th-down (384) are configurable thresholds (DlRbRateAdaptationDownsizeThreshold)
Figure 2: DL RB adaptation
(*)
Multistage
extra
condition:
the
Buffer
occupancy
threshold
(RaSduQueueThreshold) expressed in percentage is used first by the user-plane to
determine whether an upsize is necessary. A set of buffer occupancy thresholds
expressed in number of bytes (RaSduQueueThresholdBytes) is used to help the
control-plane determining the best suited target RB in case of an upsize.
UL RB ADAPTATION
The figure below illustrates the process of UL RB adaptation, with the Reference RB
bit rate set to 384 kbps (Requested Maximum Bit Rate = 384 kbps / unloaded cell) and
initial RB bit rates set to 64 kbps).
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 18/84
PS call management
Bit rate (kbps)
384
Allocated RB rate
128
Th-up(128)
Th-down(384)
64
Th-up(64)
Th-down(128)
Real bit rate
time
Legend
Observation duration
RB upsize trigger
RB reconfiguration latency
RB downsize trigger
Th-up (64) and Th-up (128) are configurable thresholds (UlRbRateAdaptationUpsizeThreshold)

Th-down (128) and Th-down (384) are configurable thresholds (UlRbRateAdaptationDownsizeThreshold)
Figure 3: UL RB adaptation
RB ADAPTATION DOWNSIZING
The RB adaptation process can downsize a RB from reference RB rate down to the
smallest RB (i.e. 32 kbps).
The figure below illustrates the RB downsizing possibilities when the currently
allocated DL & UL RB bit rates are 384 kbps.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 19/84
PS call management
DL RB adaptation
384
UL RB adaptation
256
128
64
384
32
8
128
64
32
8
Figure 4: Example of RB adaptation downsizing possibilities for DL and UL

When the RB bit rate needs to be downsized, the RNC selects the bit rate according
to observed average throughput and the range of bit rates defined by the pairs (Thdown(N-1), Th-down(N)), where N {8, 32, 64, 128, 256, 384} for the DL, N {8, 32,
64, 128, 384} for the UL.
Th-down
(N)
thresholds
(Ul/DlRbRateAdaptationDownsizeThreshold).
are
OAM
configurable
For example, if a user is currently allocated UL: 64 kbit/s / DL: 384 kbit/s but the
estimated DL average throughput is between Th-down(N) and Th-down(N-1), then the
RB is reconfigured to UL: 64 kbit/s / DL:(N-1) kbit/s where N {8, 32, 64, 128, 256,
384}. The same principle applies to the UL.
Convention: N-1 refers to the rate just before the rate N in the list of ascending rates
RB ADAPTATION UPSIZING
Most of the Interactive / Background services are TCP based. This section highlights
some principles on TCP flow-control mechanism, as described in RFC 2581 TCP
Congestion Control [R5] and the impact on RAB adaptation upsizing process. TCP
flow control is basically composed of 2 phases:
A Slow Start phase, in which the sending entity tries to increase the traffic
exponentially
When a certain value for the congestion window is reached, the sending entity
enters into the Congestion Avoidance phase during which the congestion
window grows linearly
The Congestion Window is used to compute the anticipation window at the sender
side. The anticipation window represents the maximum amount of data that can be
sent in the network and waiting for an acknowledgment.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 20/84
PS call management
Congestion
window
Slow start
threshold
Time
Slow start
Timeout or
failure
Congestion
avoidance
Figure 5 TCP flow control

At some point, during the congestion avoidance phase, TCP will experience a timeout,
as the bandwidth always has a limit (server limitation, RB size limit, IP network
congestion ). Because TCP always tries to increase the congestion window, it is
difficult to guess at the UTRAN side, which would be the most appropriate target RB
size in the upsize process.
For that reason, the following proposes two options for the upsize:
Either the current RB is re-configured to the RB immediately above (step-bystep upsize scheme)
Either the current RB is re-configured to the highest possible RB, given iRM
CAC constraints (Multi-stage upsize scheme)
UL RB adaptation upsizing
The allocated UL bit rate cannot exceed the min between the bit rate provided by iRM
table and the Reference RB bit rate. When the RB bit rate needs to be upsized (i.e.
the observed average bit rate is greater than an absolute threshold Th-up (N), the
RNC selects the bit rate that is immediately higher than the current RB, since the
traffic monitoring function can only indicate that the current bit rate is not sufficient (i.e.
estimated throughput higher than an absolute threshold), but cannot provide
information on what would be the most suitable higher rate.
For example, if a user is currently allocated UL: 64 kbit/s / DL: 128 kbit/s but the
estimated average throughput in UL is above an absolute threshold, i.e. Th-up-64,
then the RB is reconfigured to UL: 128 kbit/s / DL: 128 kbit/s.
Th-up (N) thresholds are OA&M configurable (UlRbRateAdaptationUpsizeThreshold).
DL RB adaptation upsizing
The allocated DL bit rate cannot exceed the min between the bit rate provided by iRM
table and the Reference RB bit rate. Either a step-by-step upsize scheme (the same
principle as the UL) or a multi-step upsize scheme may apply.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 21/84
PS call management
The trigger of the multi-stage upsize is based on the observed average throughput
along with its confidence level (as for step-by-step upsize case) and the DL RLC-SDU
buffer occupancy. When the observed average bit rate is greater than an absolute
threshold Th-up (N), the RNC performs some additional checks on the RLC buffer
occupancy:
If the buffer occupancy is low (this typically occurs during short peak of user
traffic),
than
no
RB
upsize
is
performed.
The
parameter
RaSduQueueThreshold is used to help determine whether an upsize should
be triggered.
Otherwise an upsize is performed. Multi-stage upsize applies provided that it

is
allowed
by
the
Operator
(Cf.
parameter
dlRbRateAdaptationUpsizeAlgorithm) and if the conditions are met (The set of
parameters RaSduQueueThresholdBytes are used to help determine the best
suited target RB).
Th-up (N) thresholds are OA&M configurable (DlRbRateAdaptationUpsizeThreshold).

DL RB adaptation
384
UL RB adaptation
256
128
384
64
32
8
128
64
32
Multi-stage adaptation
Step-by-step adaptation
Figure 6: Example of RB adaptation upsizing possibilities from RB-32 for DL and UL
4.2.3 TRAFFIC MONITORING

ALGORITHMS
Average throughput calculation
The algorithm periodically calculates the average throughput over a sliding time
window and the associated confidence level. The same algorithm applies to DL and
UL but the DL and UL traffic monitoring functions are performed independently.
The calculation of the average throughput does only take into account the volume of
RLC payload being transmitted, i.e. it does not include the RLC traffic generated by
retransmissions, control and padding.
At each TTI, the number Nb of bits transmitted/received (transmitted once in DL or
successfully received once in UL) is calculated.
The parameter T (RaUnitPeriodTime) defines the interval of time during which the
number Nb is calculated.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 22/84
PS call management
The user throughput R during the period T is defined by: R = Nb / T.
The parameter K (RaNumberOfSample) denotes to the number of samples R[i] used to
calculate the average throughput.
The sliding window of size K stores the throughput R[i], i=0..K-1 derived the last K
periods of time T.
Start of Traffic Monitoring
T
time
R[0]=0
R[1]=0
R[2]=0
R[0]=R1
R[1]=0
R[2]=0
R[0]=R1
R[1]=R2
R[2]=0
R[0]=R1
R[1]=R2
R[2]=R3
R[0]=R4
R[1]=R2
R[2]=R3
Figure 7: Sliding window of size K=3

The estimation R of the average throughput derived over the last K periods of time T
is calculated as follows:
1 K 1
R = R[i ]
K i =0
)(
When the number K of samples is large, R R / / K follows a Normal

distribution, where denotes the standard deviation of the throughput R. In order to
reduce the observation duration and also because is unknown, a Students t2
distribution with (K-1) degrees of freedom is used. The variance is also replaced
2
with its estimator S as follows:
1
K 1
i =0
K 1
The estimation
,K
(R[i] R )
R is considered as reliable if the following condition is fulfilled:
R K
Where
is the confidence level that is targeted (e.g. 95%)
is OA&M controllable (RaMaxConfidenceInt) and represents the maximum

width of confidence interval of the estimated value R .
,K
is a coefficient depending on and K parameters.
RB resizing evaluation
An RB resizing may only be triggered if the estimation R of the average throughput is
considered as reliable. If the estimation is reliable, the value is compared to the
relevant thresholds (up & down).
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 23/84
PS call management
4.3.
PARAMETERS
Name
Object/Class
Description
rbRateAdaptationPingPon
gTimer
RadioAccessSer
vice
maxDlEstablishmentRbRa
te
CacConfClass
maxUlEstablishmentRbRa
te
CacConfClass
dlRbRateAdaptationUpsiz
eAlgorithm
RadioAccessSer
vice
isDlRbRateAdaptationAllo
wed
isUlRbRateAdaptationAllo
wed
wedForThisDlUserService
wedForThisUlUserService
wedForThisDlRbSetConf
wedForThisUlRbSetConf
isThisRbRateAdaptationD
lRbSetTargetAllowed
isThisRbRateAdaptationU
lRbSetTargetAllowed
RadioAccessSer
vice
RadioAccessSer
vice
DlUserService
This Manufacturer parameter indicates the value of

the so called ping pong timer. This timer is used to
restrict the number of RB reconfigurations due to RB
adaptation.
This timer is started at termination of each RB
reconfiguration even if it is not due to RB adaptation.
No RB reconfiguration is triggered for RB rate
adaptation reason until this timer elapses. The traffic
monitoring is stopped too (both UL & DL), then, a
new evaluation period is necessary after the timer
elapses before a trigger can be set. As a
consequence, if the RB rate adaptation is configured
for both DL & UL, an ongoing DLRB resizing process
will delay any request for UL RB resize, which could
occur during this time delay (or conversely).
The range is from 0 up to 900 s
This customer parameter specifies the max DL bitrate, which may be allocated at service establishment
time (RANAP RAB Assignment request) or after
relocation (RANAP Relocation request). This
parameter is significant for Interactive/background
traffic class.
This Customer parameter specifies the max UL bit
rate, which may be allocated at service establishment
time (RANAP RAB Assignment request) ,after a
relocation (RANAP Relocation request) or after an
Always-on upsize
This Customer parameter allows selection of the type
of upsize algorithm for DL RB rate adaptation.
The possible values are multiStageUpsize or
stepByStepUpsize
These Customer parameters are used to activate /
de-activate the DL/UL RB adaptation on a RNC
basis.
The possible values are True or False
These Manufacturer parameters indicate if the
current DL/UL User Service is eligible to DL / UL RB
rate adaptation.
These Customer parameters indicate if the current
DL/UL RB is eligible to DL/UL RB rate adaptation.
DlRbRateAdaptationDown
sizeThreshold
DlRbSetConf
UlUserService
DlRbSetConf
UlRbSetConf
DlRbSetConf
UlRbSetConf
These Customer parameters indicate if the DL/UL

RB rate adaptation can target this RB for either an
upsize or downsize.
It allows the operator to restrict the list of RB rates on
which RB adaptation applies.
These Customer parameters (one parameter per RB)
define the thresholds (expressed as a rate value)
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 24/84
PS call management
Name
Object/Class
Description
UlRbRateAdaptationDown
sizeThreshold
UlRbSetConf
under which, a DL/UL RB downsize should be

triggered.
If this parameter (for the considered RB) is not
provided, the downsizing is not allowed from this RB
configuration.
The range is from 0 up to 2048 kbps
DlRbRateAdaptationUpsiz
eThreshold
UlRbRateAdaptationUpsiz
eThreshold
DlRbSetConf
UlRbSetConf
The thresholds should follow the following rules

threshold (N) < (N-1) Kbps
threshold (N-1) < threshold (N)
where N-1 refers to the rate just before the rate N in
the list of ascending rates
These Customer parameters (one parameter per RB)
define the thresholds (expressed as a rate value)
over which, a DL/UL RB rate upsize should be
triggered.
If the parameter (for the considered RB) is not
provided, the upsizing is not allowed from this RB
configuration.
The range is from 0 up to 2048kbps
The thresholds should follow the following rules:
dlRbRaTrafficMonitoring.
raSduQueueThreshold
DlRbSetConf
raSduQueueThresholdByt
es
DlRbSetConf
RaUnitPeriodTime
ulRbRaTrafficMonitoring.
RaUnitPeriodTime
DlRbSetConf
RaNbOfSample
DlRbSetConf
UlRbSetConf
threshold (N) < (N) Kbps
threshold (N-1) < threshold (N)
This Customer parameter represents a threshold

(expressed in percentage of the DL RLC-SDU buffer
occupancy) over which, a upsize of the DL RB should
be triggered.
This parameter is used to help determine the need
for any upsize triggering.
If the parameter (for the considered RB) is not
provided, the upsizing cannot be performed from this
RB configuration.
The range is from 0 up to 100 %
This Customer parameter represents a threshold
(expressed in bytes) over which, a multi-stage upsize
of the DL RB should be triggered (provided that multistage is allowed by the operator. Cf. parameter
dlRbRateAdaptationUpsizeAlgorithm).
This parameter is to select the most suitable target
RB rate, which will be used as input of the iRM table.
If the parameter (for the potential target RB) is not
provided, the multi-stage upsizing cannot be
performed toward this RB configuration.
The range is from 0 up to 2097152
These Customer parameters represent the unit of
time period over which a throughput sample is
calculated for the traffic monitoring.
The range is from 0 up to 10000 with granularity of
1 ms.
These Customer parameters define the number K of
samples to be considered for calculation of the
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 25/84
PS call management
Name
Object/Class
Description
RaNbOfSample
UlRbSetConf
RaModifiedStudentCoef
RaModifiedStudentCoef
DlRbSetConf
average throughput.
They define the size of sliding windows used for the
traffic monitoring.
These Customer parameters define the coefficient of
RaMaxConfidenceInt
RaMaxConfidenceInt
DlRbSetConf
RaMaxConfidenceIntLow
BitRate
RaMaxConfidenceIntLow
BitRate
RAthresholdLowBitRate
RAthresholdLowBitRate
4.4.
UlRbSetConf
UlRbSetConf
DlRbSetConf
UlRbSetConf
DlRbSetConf
UlRbSetConf
Student
,K
divided by the square root of

9
RaNbOfSample (K) and multiplied by 10 .

32
These Customer parameters define the maximum
interval of confidence (coefficient ) multiplied by
1000.
The range is from 0 up to 1000.
These parameters apply for case the current RB rate
is above N kbps.
Where N is
dlRbRaTrafficMonitoring.RAthresholdLowBitRate for
the DL and
ulRbRaTrafficMonitoring.RAthresholdLowBitRate for
the UL
These Customer parameters define the maximum
interval of confidence (coefficient ) multiplied by
1000.
The range is from 0 up to 1000.
These parameters apply for case the estimated RB
rate is below or equal to N kbps
Where N is
dlRbRaTrafficMonitoring.RAthresholdLowBitRate for
the DL and
ulRbRaTrafficMonitoring.RAthresholdLowBitRate for
the UL
This Customer parameter define the threshold
(expressed as a rate value) under which the
parameter RAMaxConfidenceIntLowBitRate can be
used
The range is from 0 up to 2048 kbps
COUNTERS
Detailed counter info is provided in [R9], [R10] and [R11].
Number of activation/modification of the
traffic monitoring (RB becomes eligible to
DL RB rate adaptation)
#1668 - VS.UEDlRBRateAdapActiv
#1669 - VS.UEDlRBRateAdapDeactiv
Number of deactivations of the traffic
monitoring (RB loses eligibility to DL RB rate
adaptation)
Number of DL RB rate downsize requested
by the traffic monitoring
#1672 - VS.UEDlRBRateAdapDownReq
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 26/84
PS call management
Number of DL RB rate upsize requested by
the traffic monitoring
#1673 - VS.UEDlRBRateAdapUpReq
Number of successful DL RB rate downsize #1674 VS.UEDlRBRateAdapDownSucc

(RB reconfiguration)
#1675 - VS.UEDlRBRateAdapUpSucc
Number of successful DL RB rate upsize

The granularity of these counters is RNC

These counters are screened on the following DL bit-rate:
Screen #1 --> DL PS RB 32kbps
Screen #0 --> other bit-rate
#1670 - VS.UEUlRBRateAdapActiv
Number of activation/modification of the

traffic monitoring (RB becomes eligible to
UL RB rate adaptation)
#1671 - VS.UEUlRBRateAdapDeactiv
Number of deactivations of the traffic
monitoring (RB loses eligibility to UL RB rate
adaptation)
Number of UL RB rate downsize requested
by the traffic monitoring
#1676 - VS.UEUlRBRateAdapDownReq
Number of UL RB rate upsize requested by

the traffic monitoring
#1677 - VS.UEUlRBRateAdapUpReq
Number of successful UL RB rate downsize #1678 VS.UEUlRBRateAdapDownSucc

Number of successful UL RB rate upsize
#1679 - VS.UEUlRBRateAdapUpSucc
The granularity of these counters is RNC

These counters are screened on the following UL bit-rate:
Screen #0 --> other bit-rate
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 27/84
PS call management
Number of RB rate downsize requested by
the traffic monitoring per CELL
#0652 - VS.UERBRateAdapDownReqCell
Number of RB rate upsize requested by the #0653 - VS.UERBRateAdapUpReqCell

traffic monitoring per CELL
Number of successful RB rate downsize
(RB reconfiguration) per CELL
#0654 VS.UERBRateAdapDownSuccCell
Number of successful RB rate upsize (RB

reconfiguration) per CELL
#0655 - VS.UERBRateAdapUpSuccCell
Number of RB rate downsize requested by

the traffic monitoring per RNC
#0656 VS.UERBRateAdapDownReqNeighbCell
Number of RB rate upsize requested by the #0657 VS.UERBRateAdapUpReqNeighbCell

traffic monitoring per RNC
Number of successful RB rate downsize
(RB reconfiguration) per RNC
#0658
VS.UERBRateAdapDownSuccNeighbCell
Number of successful RB rate upsize (RB

reconfiguration) per RNC
#0659 VS.UERBRateAdapUpSuccNeighbCell
The granularity of these counters is either CELL (case primary cell in the SRNS) or
RNC (case primary cell in the DRNS).
These counters are screened per RB direction (UL / DL) for the counters with RNC
granularity.
4.5.
INTERWORKING WITH OTHER FEATURES

MOBILITY
The soft handover process is not impacted by the downsizing/upsizing process, e.g.:
the same active set management algorithm applies whatever is the size of the
user channel
the same parameters values for the mobility algorithm are used in all the
cases
In case a RL needs to be added:
The CAC applies on each cell resources of the active set.
If additional resources cannot be allocated in one of the cells of the active set
then current bit rate remains.
A subsequent retry will be attempted if the traffic monitoring function of RB

adapt is still active, provided the upsize condition is still met.
Additional details are provided in [R4].
ALWAYS-ON
The RB rate adaptation and the Always-On features are independent: the triggers are
not correlated. Simultaneous triggers should be avoided using a suitable configuration
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 28/84
PS call management
of Always-On T1 timer. AO T1 timer shall must be large enough to avoid simultaneous
triggers of downsize (one for AO and another one for RB rate adaptation).
IRM SCHEDULING
Interaction between DL RB adaptation and iRM scheduling (which only apply to the
DL) is:
When the user has been downgraded due to iRM scheduling, the Radio
Bearer is no longer a candidate for DL RB adaptation.
These interactions are summarized below:

Transition candidate following the call transition
iRM scheduling iRM
DL RB adaptation
DL RB adaptation
upgrading
scheduling
upsize
downsize
downgrading
Call transition
Upgrade through
iRM scheduling
No
Yes
Yes
Yes
upgrading
Downgrade through
iRM scheduling
No
No
No
Yes
downgrading
Upsize through DL
RB adaptation
Yes
Yes
No
Yes
upsize
Downsize through
DL RB adaptation
No
Yes
Yes
Yes
downsize
Table 2: interaction between iRM Scheduling and RB rate adaptation
TxCP is used as upgrade and downgrade criteria for iRM Scheduling, as described in
[R4].
For other constraints & interactions refer to section 4.2.1.
5.
ALWAYS-ON
Once the call has been established, the UTRAN provides several solutions to optimize
the usage of radio resources:
Always On (described in this section)
iRM Scheduling (described in [R4])
RB Adaptation (described in section 4)
AO only applies to Interactive/Background RB. It also applies to both DCH and

HSDPA/HSUPA type of calls. AO does not apply if the Signaling Indication parameter
of the RAB Assignment Request associated with the Interactive RAB has been set to
signaling. In this case the RB will not be downsized by AO.
Many data applications transported by the UMTS PS domain are bursty in nature and
do not require continuous contact with the end user. In fact, applications such as web
browsing and email can remain dormant for long periods of time. One of the
characteristics of such applications is the need for the end user to be able to access
information quickly when it is required.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 29/84
PS call management
A trade-off is required between utilizing network resources efficiently and network
responsiveness. The Always-on (AO) capability allows users to remain connected to
the network, while utilizing little or no radio resources. As streaming and
conversational traffic classes require guaranteed bit rates, AO is only applicable to
interactive and background classes. AO controls a subscriber session by introducing
three states:
Normal Mode: In this state the session is operating with the original RB that
was allocated at call admission or adapted by RB Adaptation. For a session to
be maintained in this state, the user traffic must not fall, and remain, below a
pre-defined threshold for a specified period of time. A session is returned to
this state, from idle mode or downsized mode, if user traffic is resumed or
exceeds a pre-defined threshold respectively.
Downsized Mode: In this state the session is operating with a downgraded

(from a bandwidth perspective) RB than the one originally allocated by the
RAB Matching Algorithm. A session is downgraded to the downsized mode
from the normal mode if user traffic remains below a pre-defined threshold for
a given period. This downsized state contains the following two sub-steps:
o
AO Step 1, for the case where CELL_FACH is used.
AO Step 2, for the case where CELL_PCH or URA_PCH is used.
Note: in case of multi-service CS + PS, downsized states are still DCH but
with lowered PS rate. This case is described in 5.5.
Idle Mode: In this state the session has released all its radio resources, but
the PDP context is still maintained by the core network. A session is
downgraded to idle mode if there has been no user traffic for a given (by
provisioning) period of time. This state is also known as AO Step 3.
The simplified state transitions are shown in Figure 8.

Downsizing
(Tdownsize expiry)
Idle State Transition

(Tinactivity expiry)
Downsized
Mode*
(contains substeps 1 and 2)
Normal
Mode
Idle
Mode
(a.k.a. Step 3)
Upsizing
(traffic resumption)
:
RB Restablishment
(traffic resumption)
Only applies to Interactive/Background traffic class
Figure 8: AO state transitions

The call may also be moved to the PMM_IDLE state in one of three ways:
Directly, from the Normal Mode (e.g. when step 1/2 are disabled)
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 30/84
PS call management
5.1.
Indirectly, after transitioning through the AO Downsized Step 1 state (e.g.

when step 2 CELL_PCH/URA_PCH is disabled).
Indirectly, after transitioning through the AO Downsized Step 1, followed by

the AO Step 2 state (e.g. nominal scheme).
TRANSITIONS OVERVIEW
As explained in the previous section, the user may either be initially allocated a DCH
in the CELL_DCH state or HS-DSCH in the DL and E-DCH in the UL. In the case of
DCH, after the call is established, based on user traffic observation, the user may be
moved to one of the following AO downsized states:
CELL_FACH (AO Step 1)
URA_PCH (AO step 2)
CELL_PCH (AO Step 2)
A simplified transition summary, highlighting the applicable timers, is provided in

Figure 9
T2
CELL_PCH
T3
T1 (low traffic)
CELL_DCH
load criteria
CELL_FACH
Mobility signalling
load criteria
AO Step 1
RRC / PMM IDLE

Cell Update
signaling load criteria
URA_PCH
T3
T2
AO Step 2
AO Step 3
Normal Mode
Figure 9: Transition summary (simplified)

DCH/FACH to PCH
The usage of URA_PCH/CELL_PCH states is optional for AO. T2 may also be used to
move directly from CELL_FACH to Idle (thereby bypassing Cell/URA_PCH states).
It is possible to by-pass the CELL_FACH state, for one of the following reasons:
It is not configured.
In the case of a PS I/B + PS I/B RB [USA Market - and PS I/B + PS I/B + PS

I/B RB], since this combination is not eligible to use CELL_FACH. This
transition is based on the timer tRabInactivityDchPchMpdpChannelType.
In the case where the user is downgraded to PCH states, T2 related timers are used
in order to move the UE from CELL_FACH downgraded state to CELL_PCH or
URA_PCH. The criterion is the same as that used for the transition to idle mode (i.e.
zero traffic activity during the measured interval).
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 31/84
PS call management
The selection between CELL_PCH Vs URA_PCH is based on OAM provisioning.
Either both states can be enabled, in which case CELL_PCH is initially selected or
only URA_PCH is enabled, in which case the transition is to URA_PCH.
PCH to Idle
The transition from CELL_PCH or URA_PCH to idle (T3) is shown as direct in Figure
9, even though in reality the UE moves via CELL_FACH in order to release the RRC
connection.
Cell_PCH to URA_PCH
The transition between CELL_PCH and URA_PCH occurs when the user is in the
CELL_PCH state, and is based on the Cell Update signaling load. The traffic inactivity
shall not be considered as a criterion as no traffic is possible in PCH states. Hence,
this transition is not directly related to AO.
PCH states to Idle
In the case of the transition from the PCH states to Idle, T3 related timers are used in
to trigger the transition. This transition is required because the UE will still consume an
RRC context in the RNC. It should be noted that in these states the logical and
transport channels are frozen (configuration is kept, like RLC state variables) and
DTCH + DCCH cannot be used for transmission: the Radio Bearer is still existing but
cannot be used; hence traffic inactivity cannot be measured at RLC/MAC level. The
T3 timer shall be stopped on reception of data from the Core Network in DL or on the
reception of a CELL UPDATE (uplink data transmission) in UL.
Upgrading from PCH states :
There are three scenarios where a transition is required from a PCH state to
CELL_DCH or CELL_FACH:
Traffic resumes on the TRB
New service establishment (CS or PS)
Pure signaling messaging
When traffic resumes for a mobile in URA/CELL_PCH, the mobile shall be moved
back to CELL_FACH (general case) or (in the case of PS + PS, or the case of a RAB
Assignment Request for multi-service) to CELL_DCH, in which case the DTCH (TRB)
and DCCH (SRB) will be re-established. The current Always-On monitoring process
will be used to further upsize to CELL_DCH if required.
It should be noted that in the case of NAS messaging, the mobile will also be moved
to CELL_FACH, since the UTRAN is unaware of whether the UL traffic is resuming for
the TRB or for the SRB (e.g. establishment of another service, beginning by SRB
traffic with IDT before RAB assignment).
The different scenarios will be handled as follow:
UL traffic resuming (TRB or SRB): mobile is moved to CELL_FACH (SRB + TRB)
using a RB Reconfiguration, with the exception of PS + PS multiplexed on DCH
(moved to CELL_DCH directly)
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 32/84
PS call management
DL traffic resuming (TRB or SRB): mobile is moved to CELL_FACH (SRB + TRB)
using a RB Reconfiguration, with the exception of PS + PS multiplexed on DCH
(moved to CELL_DCH directly)
PS RAB Assignment request: mobile is moved to CELL_DCH and then RB Setup or
Delete
If the RNC is unable to transition the UE back to CELL_DCH / CELL_FACH state due
to CAC failure, it shall release the RRC connection.
A transition summary is provided in Table 3:
Initial state
Final state
Relevant timer
Condition
Comment
CELL_FACH
(PS I/B
timerT1 or
Low UL & DL
traffic
Existing AO
step 1
No UL & DL
traffic
AO step 1
disabled
Downsize
CELL_DCH
(PS I/B TRB +
SRB)
TRB + SRB)
timerT1ForHsdpa or
timerT1ForHsdpaAndEdch
(T1 timer)
CELL_DCH
Idle
timerT2 or
(PS I/B TRB +

SRB)
timerT2ForHsdpa or
CELL_PCH
disabled
(T3 timer)
CELL_DCH
CELL_PCH
(PS I/B TRB +

SRB)
URA_PCH
disabled
FACHToCellPchTimer
(T2 timer)
No UL & DL
traffic
AO step 1 on
FACH disabled
(TimerT1 is
assumed null)
CELL_PCH
enabled
CELL_DCH
URA_PCH
(PS I/B TRB +

SRB)
FACHToUraPchTimer
(T2 timer)
No UL & DL
traffic
AO step 1 on
FACH
disabled
(TimerT1 is
assumed null)
CELL_PCH
disabled
URA_PCH
enabled
CELL_FACH
(PS I/B TRB +
SRB)
Idle
TimerT2
No UL & DL
traffic
(T3 timer)
Existing "AO
step 2"
PMM-Idle
transition
CELL_PCH
disabled
URA_PCH
disabled
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 33/84
PS call management
Initial state
Final state
Relevant timer
Condition
Comment
CELL_FACH
CELL_PCH
FACHToCellPchTimer
No UL & DL
traffic
CELL_PCH
enabled
No UL & DL
traffic
CELL_PCH
disabled
(PS I/B TRB +

SRB)
CELL_FACH
(T2 timer)
URA_PCH
(PS I/B TRB +

SRB)
CELL_PCH
FACHToUraPchTimer
(T2 timer)
URA_PCH
enabled
Idle
CellPchToIdleTimer
(T3 timer)
No UL & DL
signaling
(implicit)
URA_PCH
Idle
UraPchToIdleTimer
(T3 timer)
No UL & DL
signaling
(implicit)
CELL_DCH
Idle
timerT2ForMultiIbRab
(mux. PS I/B
TRBs + SRB)
(T3 timer)
No UL & DL
traffic on
both RAB (on
underlying
TrCH)
Existing AO
step 2 (no AO
step 1 applied)
CELL_PCH
disabled
URA_PCH
disabled
CELL_DCH
CELL_PCH
tRabInactivityDchPchMpdp
(mux. PS I/B
TRBs + SRB)
CELL_DCH
URA_PCH
tRabInactivityDchPchMpdp
(mux. PS I/B
TRBs + SRB)
No UL & DL
traffic on both
RAB (on
underlying
TrCH)
no AO step 1
applied
No UL & DL
traffic on both
RAB (on
underlying
TrCH)
no AO step 1
applied
CELL_PCH
enabled
CELL_PCH
disabled
URA_PCH
enabled
Upsize
CELL_PCH
CELL_FACH
N/A
UL or DL
traffic or
(RRC, NAS)
signaling
N/A
UL or DL
traffic or
(RRC, NAS)
signaling
N/A
UL or DL
traffic
(TRB + SRB)
URA_PCH
CELL_FACH
(TRB + SRB)
CELL_FACH
CELL_DCH
(TRB + SRB)
(TRB +SRB)
RAB Assign
Request
initiated either
on UE or on
network
request
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 34/84
PS call management
Initial state
Final state
Relevant timer
Condition
Comment
URA_PCH
N/A
Cell update
frequency
URA_PCH
enabled
Other cases
CELL_PCH
Table 3: Transition summary
5.2.
AO STEP 1 IN CELL-FACH
5.2.1 PRINCIPLE
This mechanism is known as Always-On Step 1.
The physical resource allocated to the mobile is adapted based on the amount of user
traffic:
the resource is downsized when user activity is low for a certain period of time
the resource is upsized when buffer occupancies in UL or DL are exceeding a

configurable size.
In the example of Figure 10, the SF16 coded allocated originally is downsized to a
RACH/FACH channel. This will be sufficient to support the signaling exchanges
(NAS/RRC signaling, including periodic measurement messages) and even some low
rate user traffic, if there is any.
On the uplink, although there is no code shortage and no power/interference issue
(thanks to DTX), downsizing is also applied, in order to decrease the amount of
resources used in the BTS.
3 DCCH: 3.4Kb/s
DCH
SF32
DTCH: 64Kb/s
3 DCCH: 13/25Kb/s:
RACH/FACH
DTCH: 32/32Kb/s
Figure 10: Example of downsizing in the downlink channel

The capability of the downsized resource is always the same (i.e. the capacity of the
RACH/FACH channel, which shares the physical transport with other transport
channels) and therefore does not depend on the size of the resource that was
allocated previously.
In the upsizing process, it may happen that the resource that was allocated before
downsizing is no longer available (from the perspective of iRM), and that a lower
capacity resource is allocated (by iRM) instead, as shown in the example in Figure 11
below. Since the resource allocation performed in the upsizing process follows the
same rules as the initial resource allocation (during RAB Assignment Request
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 35/84
PS call management
processing), the input parameters are the RAB parameters requested initially, the
network
load
condition
and
the
maximum
UL
and
DL
bit-rates
(maxUlEstablishmentRbRate and maxDlEstablishmentRbRate) that are configured by
the rate-adaptation feature. Further iRM details are provided in [R4].
SF16
SF32
RACH/FACH
downsizing
RACH/FACH
Upsizing (via iRM)
Figure 11: Upsizing in the UL/DL channel example
5.2.2 MOBILITY IMPACT

The AO decision to change from CELL_DCH to CELL_FACH allows the UE to now
control its own mobility, and it may therefore decide (for radio reasons) to reselect a
different cell. Further details are provided in [R1].
If the primary cell is under the DRNC, on step 1 AO condition the SRNC requests the
UE to downsize on CELL_FACH, which is rejected by the Alcatel-Lucent DRNC. The
UE call is release with the user inactivity RRC cause and reestablished on the new
SRNC (this of the primary cell).
To avoid the release of the RRC connection in case of CAC when moving to CELLFACH, a pre-CAC on the primary cell is done before ordering the UE to CELL-FACH.
If it fails, the UE is kept on CELL-DCH and is eligible to AO downsizing again.
If the UE moves to CELL_FACH but reselects another cell than the primary cell, and
the CAC fails then the RRC connection is released.
5.2.3 DECISION TO CHANGE RATE

The decision to upsize is based on traffic volume monitoring in both uplink and
downlink directions on the logical DTCH channel. The signaling exchanged over the
logical DCCH is not taken into account. The decision to upsize is based on the
RLC/MAC buffer occupancy.
The traffic which is monitored corresponds to the frames which are actually sent over
the radio interface. Therefore, this includes both users PDU (as they are submitted by
higher layers to radio protocol PDCP/RLC/MAC) and repeated RLC frames which may
be sent when RLC-AM (Acknowledged Mode) is used.
The principle is that:
downsizing is performed if the traffic is below a threshold for a certain period

of time (downsizing timer)
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 36/84
PS call management
upsizing is performed as soon as the user traffic exceeds a given limit
UL or DL Traffic
downsizing
upsizing
Threshold
downsizing timer
downsizing timer
Figure 12: downsizing decision process

For the decision process, upsize and downsize criteria are defined for the 2 directions
(uplink and downlink).
Downsize criteria
This criteria is valid if the UL downsize and DL downsize conditions are

verified
Upsize criteria
This criteria is valid if the UL upsize or DL upsize conditions are verified
Conditions:
The DL downsize condition is based on traffic volume monitoring on non-sliding time
windows. The following parameters are used:
Ntti: length of the time window in TTI (Ntti is therefore a multiple of 10 ms)
NbTB: Number of Transport Blocks transferred during the time window
TBsize: size of a L1 Transport Block (in bits)
timerT1: downsizing timer.

The downsize criteria is met if
NbTB TBsize
< (ThroughputThreshold )b / s
Ntti
during, at least, timerT1 seconds
The UL downsize condition is based on traffic volume monitoring on non-sliding time

Ntti: length of the time window in TTI (Ntti is therefore a multiple of 10 ms)
TBsize: size of a L1 Transport Block (in bits)
timerT1: downsizing timer.

The downsize criteria is met if
NbTB TBsize
< (ThroughputThreshold )b / s
Ntti
during, at least, timerT1 seconds
The DL upsize condition is based on the buffer occupancy. The BO corresponds to the
sum of pending SDU + RLC retransmissions.
The criteria is met if the buffer occupancy for a given user DTCH RLC/MAC
buffer exceeds a given threshold known as step1DlRlcBoThreshold, as
described in figure below.
This condition is evaluated in the SRNC.

UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 37/84
PS call management
DTCH RLC/MAC
buffer
DTCH RLC/MAC
buffer
threshold
No upsize needed
Upsize is needed
Figure 13: Upsizing decision process

The UL upsize condition is verified as the sum of Buffer Occupancies of RB
multiplexed onto the RACH exceeds a certain threshold known as repThreshold.
This condition relies on event triggered UE traffic volume measurement on RACH
Transport Channel, as specified in 25.331 14.4.2.1 (event 4A), described in the figure
below. On reception of this event, the SRNC considered the UL upsize condition as
fulfilled.
Transport
Channel
Traffic
Volume
Threshold
Time
Reporting
event 4A
Reporting
event 4A
Figure 14: Traffic volume reporting - event 4A
5.2.4 TRANSITION PROCESS

The downsizing transition from CELL_DCH to CELL_FACH is shown in Figure 15.
The procedure is modified in UA06 to reserve dedicated resources (a C-RNTI) before
ordering the UE to CELL_FACH and directing the UE towards a given cell (specifically
the primary cell determined in CELL_DCH state). Another positive evolution consists
in giving the C-RNTI to the UE at the time of the RB reconfiguration, which enables to
decrease the overall delay for the transition from CELL_DCH to CELL_FACH.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 38/84
PS call management
UE
Node B
RNC
SGSN
Based on Always-On criteria,and after pre-CAC on the

primary cell, the mobile is moved to the CELL_FACH state
RRC/ DCH / RB Reconfiguration (

RRC state = CELL_FACH,
Frequency Info,
C-RNTI,
Primary CPICH Info)
RRC/ RACH / RB Reconfiguration Complete
The old Radio Link is released at the NodeB
NBAP/ Radio Link Deletion Request
NBAP/ Radio Link Deletion Response
Figure 15: CELL_DCH to CELL_FACH transition

UE
Node B
RNC
SGSN
Based on Always-On criteria,and after pre-CAC on the

primary cell, the mobile is moved to the CELL_FACH state
RRC/ DCH / RB Reconfiguration (

RRC state = CELL_FACH,
Frequency Info,
Primary CPICH Info)
If the UE re-selects a cell different from the one indicated
by the "Primary CPICH Info", the UE shall 1st perform a
cell update in the new cell.
RRC/ RACH / Cell Update (cause cell re-selection)

RRC/ RACH / Cell Update Confirm
RRC/ RACH / RB Reconfiguration Complete
The old Radio Link is released at the NodeB
NBAP/ Radio Link Deletion Request
NBAP/ Radio Link Deletion Response
Figure 16: CELL_DCH to CELL_FACH transition with cell-reselection

The upsizing transition from CELL_FACH to CELL_DCH is shown in Figure 17.
UE
Node B
RNC
SGSN
Based on Always-On criteria, the mobile is moved to the

CELL_DCH state. For that purpose, a dedicated Radio
Link is setup at the NodeB
NBAP/ Radio Link Setup Request
NBAP/ Radio Link Setup Response
RRC/ FACH / RB Reconfiguration (
RRC state = CELL_DCH,
Radio Link Info)
RRC/ DCH / RB Reconfiguration Complete
Figure 17: CELL_FACH to CELL_DCH transition
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 39/84
PS call management
5.2.5 PARAMETERS
Table 4 enumerates the parameters that can be modified at the OMC-R level.
Name
Object/Class
repThreshold
AoOnFachPara
m Class 3
timeToTrigger
AoOnFachPara
m Class 3
step1AverageWindow
AoOnFachPara
m
Class 3
step1DlRlcBoThreshold
AoOnFachPara
m Class 3
step1DlUlThroughputThreshol AoOnFachPara
d
m Class 3
timerT1
AlwaysOnTimer
Class 3
timerT1ForHsdpa
AlwaysOnTimer
Class 3
AlwaysOnTimer
Class 3
isAlwaysOnAllowed
AlwaysOnConf
Class 3
Description
3GPP TS 25.331 Reporting Threshold. Threshold on
UL user data rate for transition from CELL_FACH to
CELL_DCH.
This parameter is used as part of event4A
configuration.
3GPP TS 25.331 Time to trigger. It indicates the
period of time between the timing of event detection
and the timing of sending Measurement Report. This
parameter is used as part of event4A configuration.
Length of the averaging non-sliding time windows,
referred to as Ntti in the description above, used to
evaluate the throughput and compare it with the
step1DlUlThroughputthreshold parameter.
From 10 to 10000 step 10 (in ms)
Threshold on TRB RLC Buffer occupancy that is
monitored by the RNC on the downlink for transition
from CELL_FACH to CELL_DCH.
From 0 to 32000, in bytes
Threshold on user rate for DL and UL transition from
CELL_DCH to CELL_FACH.
From 0 to 32000 (in bit/s)
Timer for uplink/downlink downsizing for a PS RAB
on DCH/DCH.
There is one specific value for each of the OLS
levels (Gold, Silver Bronze).
This parameter is common to AO Step 1 in CellDCH and AO Step 1 in Cell-FACH
From 10 ms to 60 min, step 10 (in ms)
on HSDPA/DCH.
on HSDPA/E-DCH.
This parameter is used to activate/de-activate the
Always On features. This parameter is a global
one, used to activate/deactivate the feature on a
RNC basis.
The possible values are: true or false
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 40/84
PS call management
Name
Object/Class
Description

Always On features. It is available for each
DlUserService downlink RAB configuration.
The possible values are:
Class 3
False
True
Always On features. It is available for each uplink
UlUserService RAB configuration.
Class 3
False
True
Always On features. It is available for each
downlink Radio Bearer configuration.
DlRbSetConf
Class 3
Disabled
Degraded2AlwaysOnOnly
ReleaseOnly
Always On features. It is available for each uplink
Radio Bearer configuration.
UlRbSetConf
Class 3
Disabled
Degraded2AlwaysOnOnly
ReleaseOnly
Table 4: AO related params
isAlwaysOnAllowed
isAlwaysOnAllowed
isAlwaysOnAllowed
isAlwaysOnAllowed
Remark on activation/de-activation parameters :

Always-On is only active for a given radio bearer if all the conditions are fulfilled:
5.3.
The isAlwaysOnAllowed activation parameter at the AlwaysOnConf (RNC)

level is set to true
The isAlwaysOnAllowed activation parameter for the uplink and downlink user
service is set to true
The isAlwaysOnAllowed activation parameter for the uplink and downlink

radio bearer service is not set to disabled. This parameter can be set to one of
the following multiple states, assuming the activation of the xxx_PCH feature:
o
Degraded2AlwaysOnOnly: In this case AO will allow transitions to AO

Step 1 and AO Step 2, but it will not allow a subsequent transition to
AO Step 3.
ReleaseOnly: In this case AO will not allow a transition to AO Step 1

or AO Step 2. It will only allow a transition to AO Step 3.
CELL/URA PCH RELATED STATE TRANSITIONS

This mechanism is also referred to as Always-On Step 2.
PCH states (i.e. CELL_PCH and URA_PCH) are useful for data subscribers who can
fallback to one of these states when they are completely inactive. Since no cell
resources are allocated to the UE in these states (i.e. no dedicated physical channel is
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 41/84
PS call management
allocated to the UE), they have no impact on the cell capacity. Nevertheless,
subscribers benefit from a quicker re-establishment time compared to when in idle
mode and the UE battery consumption is low (i.e. equivalent to when the UE is in idle
mode).
The basic principles of the Cell/URA_PCH transitions are provided in section 5.1. This
section provides additional information:
The case of a transition from CELL_DCH to CELL_PCH for a PS I/B (or PS

I/B + I/B) RB is shown in Figure 18.
UE
UTRAN
DCCH/RB Reconfiguration
(state = CELL_PCH; freq info)
CCCH/Cell Update
(cell reselection)
Cell update only if UE selects

another cell or if it comes from
CELL_DCH (no Primary
CPICH info provided in
reconfiguration)
DCCH/Cell Update Confirm

Complete
Figure 18: Reconfiguration to CELL_PCH from CELL_DCH
The case of a transition from CELL_FACH to URA_PCH for a PS I/B RB (or PS

I/B + I/B) is shown in Figure 19.
UE
UTRAN
(state = URA_PCH; URA_identity; freq info)
CCCH/URA Update
(URA reselection)
DCCH/URA Update Confirm
URA update only if UE

selects another URA than
the one assigned
Complete
Figure 19: Reconfiguration to URA_PCH from CELL_FACH

In the case where a CS RAB is established with one or more PS I/B RAB, this
combination is not eligible to be reconfigured to CELL_PCH or URA_PCH before the
CS RAB is released.
The mono PS I/B RAB case where the UE requests UL data transfer when the UE
is in CELL_PCH or URA_PCH state is shown in Figure 20.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 42/84
PS call management
UE
UTRAN
RACH/CELL UPDATE
(uplink data tx)
FACH/CELL UPDATE CONFIRM

DCCH/RB RECONF COMPLETE
Figure 20: UL Data transfer request (FACH)
The multi-RAB PS I/B + PS I/B case where the UE requests UL data transfer
when the UE is in CELL_PCH or URA_PCH state is shown in Figure 21. In this
case the UE is directly reconfigured to CELL_DCH (using the iRM table in the
case of a DCH RB).
UE
UTRAN
CCCH/CELL UPDATE
(uplink data tx)
CCCH/CELL UPDATE CONFIRM

(RRC state=CELL_DCH; RB info to
reconfigure)
RRC state is CELL_DCH
Figure 21: UL Data transfer request (DCH)
The mono PS I/B RAB case where the UE is in CELL_PCH or URA_PCH state
and the CN sends DL UP data to the RNC, is shown in Figure 22.
UE
CN
UTRAN
data
PCH/Paging Type 1
CCCH/Cell Update
(paging response)
CCCH/Cell Update Confirm
(RRC state=CELL_FACH; CRNTI)
DCCH/UTRAN Mobility Info
Confirm
RRC state is CELL_FACH
Figure 22: DL Data transfer request (FACH)

UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 43/84
PS call management
The multi-RAB PS I/B + PS I/B case where the UE is in CELL_PCH or URA_PCH

state and the CN sends DL UP data to the RNC, is shown in Figure 23.
UE
CN
UTRAN
data
PCH/Paging Type 1
CCCH/Cell Update
(paging response)
CCCH/Cell Update Confirm

(RRC state=CELL_DCH; RB info
to reconfigure)
Complete
Figure 23: DL Data transfer request (DCH)
The mono PS I/B case where the UE is in CELL_PCH or URA_PCH state and it
requests establishment of a new service (either CS or PS) is shown in Figure 24.
This is also applicable to the case where the UE requests resumption of traffic for
a pure signaling transaction.
CN
UTRAN
UE
CCCH/CELL UPDATE
(uplink data tx)

(RRC state= CELL_FACH; C-RNTI)
DCCH/UTRAN MOBILITY INFO
CONFIRM
DCCH/Initial Direct Transfer
(Service Request)
RRC state is CELL_FACH, except

in the case of PS I/B+PS I/B where
it is CELL_DCH
Direct Transfer (Service Request)
Other phases of the setup are not of

interest and not show here
RRC state is
CELL_DCH.
Reconfiguration is
synchronous if coming
from CELL_DCH, else
it is asynchronous
DCCH/RB Setup
DCCH/RB Setup Complete
RAB Assignment Request
RAB Assignment Response
Figure 24: UE Service request
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 44/84
PS call management
The case where the UE is in CELL_PCH or URA_PCH state (mono PS I/B or

PS + PS I/B) and the CS CN request establishment of a new service is shown in
Figure 25. This is also applicable to the case where the CN requests resumption
of traffic for a pure signaling transaction.
CN
UTRAN
UE
PCH/Paging Type 1
Paging
CCCH/CELL UPDATE
(paging response)
(RRC state=CELL_DCH; RB info to
reconfigure)

Direct Transfer (Service Request)
RRC state is
CELL_DCH.
Reconfiguration is
synchronous
DCCH/Initial Direct Transfer

(Paging Response)
Other phases of the setup are not of

interest
DCCH/RB Setup
DCCH/RB Setup Complete
Figure 25: CS MT Request
The case where the UE is in CELL_PCH or URA_PCH state (mono PS I/B or

PS + PS I/B) and the PS CN request establishment of a new service is shown in
Figure 26.
CN
UTRAN
UE
PCH/Paging Type 1
CCCH/CELL UPDATE
(paging response)
(RB setup)
DCCH/RB SETUP COMPLETE

Figure 26: PS Request

UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 45/84
PS call management
In the case where the UE does not support the URA/CELL_PCH RRC state, the RRC
procedure used to reconfigure the UE to this state will fail (e.g.: RB
RECONFIGURATION FAILURE).
If for any reason the reconfiguration fails then the RNC shall release the RRC
connection (move the UE to Idle). The only functional consequence of this behavior is
the longer resume time (from Idle to DCH instead of PCH to DCH).
5.3.1 PARAMETERS
Name
Object/Class
Description
PchRRCStates (none, UraPchEnabled,

CellPchEnabled,UraAndCellPchEnable
d)
RadioAccessServi
ce Class 3
Enables/disables the PCH related states.
nbOfCellUpdatesFromCellPchToUraPc
h (1..65535)
RadioAccessServi
ce Class 3
Controls the transition from CELL_PCH

to URA_PCH.
Threshold value for the number of Cell
update procedures -with cause "cell
reselection"- initiated by a UE in
CELL_PCH state (i.e. for a maximum
duration of CellPCHtoIdleTimer) for the
RNC to trigger a state change of this UE
to URA_PCH
AlwaysOnConf / AlwaysOnTimer /
FACHtoCellPCHTimer (aka T2 for
Cell_PCH) : 1..3600s
RadioAccessServi
ce Class 3
AO timer used for inactivity monitoring
RadioAccessServi
ce Class 3
RadioAccessServi
ce Class 3
RadioAccessServi
ce Class 3
FACHtoURAPCHTimer (aka T2 for
URA_PCH) : 1..3600s
CellPCHtoIdleTimer (aka T3 for
Cell_PCH) : 1..7200mn
URAPCHtoIdleTimer (aka T3 for
URA_PCH) : 1..7200mn
Table 5: PCH related transition params
5.3.2 COUNTERS
Detailed counter info is provided in [R9], [R10] and [R11].
RNC:
Number of mobiles in CELL_PCH state
Number of mobiles in URA_PCH state
Number of transitions from CELL_PCH to URA_PCH
Number of transitions from CELL_DCH to URA/CELL_PCH
Number of transitions from CELL_FACH to URA/CELL_PCH
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 46/84
PS call management
Number of upsize initiated by RNC from URA/CELL_PCH to CELL_FACH or

CELL_DCH - Mobile initiated upsize are tracked by Cell Update (UL data
transfer) counter.
FDDCell:
5.4.
Number of paging (type 1) sent on PCCH

o
CELL_PCH
URA_PCH
Number of URA update received

o
Change of URA
Periodic URA update
Number of URA update rejected

o
Unknown U-RNTI
Incorrect message
FACH CAC failure
Other
"PMM-IDLE" STATE TRANSITION
5.4.1 PRINCIPLE
This mechanism is also referred to as Always-On Step 3.
Figure 27 illustrates the PMM (Packet Mobility Management) states as maintained by
the UE and the SGSN. When the mobile is switched-on, it can be either in PMMCONNECTED state (i.e. there exists a RRC connection between the UE and the
RNC) or in PMM-Idle mode (i.e. the connection has been released, but the user PDP
context is still active).
PMMDETACHED
Mobile cannot be
reached
PS Detach
Mobile can be reached

PDP context is active
PMM-IDLE
SM-ACTIVE or
INACTIVE
PS Attach
PS Signalling
Connection Establish
PS Signalling
Connection Release
Detach
PMMCONNECTED
SM-ACTIVE or
INACTIVE
Figure 27: The PMM states

When the connection is considered inactive for a certain period of time, the RNC asks
the SGSN for connection release, while keeping the user PDP context active.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 47/84
PS call management
Figure 28 shows what context info remains in PMM-Idle mode, once the connection
with the network has been released:
the PDP context at the SGSN
the PPP (or IP) link between UE and ISP
the SGSN-GGSN tunnel. The GTP tunnel is kept alive until the PDP context is
deactivated
PPP
GTP tunnel
UE
RNC
SGSN
GGSN
PDP
ctx
Figure 28: in PMM-Idle state

Resuming uplink or downlink traffic requires the mobile network connection and the
RAB to be re-established. From a UTRAN perspective, resuming user traffic looks like
any Mobile Originated or Mobile Terminated call. From a CN perspective, there is less
signaling involved, since there is no PDP context establishment required, and
therefore no signaling needed with the GGSN to negotiate the PDP context attributes
or to setup the GTP tunnel.
5.4.2 DECISION FOR PMM-IDLE TRANSITION

The decision to change to PMM-Idle state is based on traffic volume monitoring in
both uplink and downlink directions on the logical DTCH channel if the RRC state is
CELL_FACH. The signaling exchanged over the logical DCCH is not taken into
account. In CELL_PCH or URA_PCH state, there is no DTCH so traffic inactivity
cannot be measured at RLC/MAC level. The T3 timer shall be stopped on reception of
data from the Core Network in DL or on the reception of a CELL UPDATE (uplink data
transmission) in UL. At T3 timer expiration, the UE is transitioned to PMM-Idle state.
The decision for PMM-Idle transition can be made in any of the "downsized state", i.e.
as the mobile is using
CELL_FACH state
CELL_PCH state
URA_PCH state
The basic principle is that the "Idle MM" transition is performed if there is no user
traffic for a certain period of time (inactivity timer)
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 48/84
PS call management
UL or DL Traffic
"Idle MM"
transition
downsizing timer
downsizing timer
Figure 29: PMM-Idle decision process

For the decision process, upsize and downsize criteria are defined for the 2 directions
(uplink and downlink).
PMM-Idle transition criteria
This criteria is valid if the UL release and DL release conditions are verified
The UL release condition is based on traffic volume monitoring on non-sliding time

Ntti: length of the time window in TTI (Ntti is therefore a multiple of 10ms)
Tinactivity: inactivity timer

The criteria is met if (NbTB=0) at least during Tinactivity seconds.
The DL release condition is using the same algorithm.
5.4.3 TRANSITION TO PMM-IDLE MODE

The generic case of a transition to PMM-Idle mode is triggered by an inactivity timer
running in the RNC. The connection is then released on RNC request.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 49/84
PS call management
UE
RNS
SGSN
RRC connection is setup

SCCP connection is setup
PDP context is activated

Mobile is in
CONNECTED
mode
Packet Transfer Uplink & Downlink
Inactivity timer
RANAP Iu release request
RANAP Iu release command
RRC RRC Connection Release
RRC RRC Connection Release Complete
All the connections

are released
RANAP Iu Release Complete

SCCP Released
Mobile is in
IDLE mode
...
...
...
...
Figure 30: transition to PMM-Idle

From the UTRAN (RNC and NodeB) perspective, this process is seen as a RNC
originated call termination. The RRC connection is released and all the associated
UTRAN resources are released.
From the SGSN point of view, the active PDP contexts will remain, although the RAB
and associated SCCP connection is released.
This procedure is transparent to the GGSN.
In the case of a transition from Cell/URA PCH to Idle, when the PS I/B RAB(s) has
been inactive for time CellPCHToIdleTimer (or URAPCHToIdleTimer), a release will
occur, as shown in Figure 31.
UE
CN
UTRAN
Iu Release Request
Iu Release Command
PCH/Paging Type 1
CCCH/Cell Update
(paging response)
CCCH/RRC Connection Release
Possibly repeated
Iu Release Complete
Figure 31: Release from CELL_PCH or URA_PCH

UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 50/84
PS call management
5.4.4 UPLINK DATA TRAFFIC RESUMING

In order to be able to initiate uplink data transfer from the PMM-Idle state, the mobile
needs to re-establish a new connection with the network. This is shown in Figure 32.
UE
RNS
Mobile is in
IDLE mode
...
SGSN
...
...
...
RRC RACH (RRC connection Request)
The RRC
connection is setup
on mobile request
RRC FACH (RRC Connection Setup

RRC RRC Connection Setup Complete
RRC Initial Direct Transfer (Service Request)

SCCP Connection Request
SCCP Connection Confirm
The connection with

the SGSN is setup
RANAP Initial UE msg (Service Request)

RANAP/ RAB Assignment Request
Radio resource &
connection are setup
RRC/ RB Setup
RRC/ RB Setup Complete
RANAP/ RAB Assignment Response
Mobile is in
CONNECTED
mode
GMM Service Accept
User data transfer

can proceed
Figure 32: Resuming UL activity

From the UTRAN (RNC and NodeB) perspective, this process is seen as a new
mobile originated PS call setup. A new RRC connection is setup, and corresponding
RAB resources are established.
From the SGSN point of view, this is seen as a service re-establishment. The RAB
attributes which are sent in the RAB Assignment Request correspond to the PDP
context(s) which is (are) activated.
5.4.5 DOWNLINK DATA TRAFFIC RESUMING

Although the connection is no longer active, the mobile is still allocated a PDP address
(since the PDP context remains). Therefore, the network may initiate downlink data
transfer by paging the mobile, which would have the effect of creating a new
connection. This is shown in Figure 33.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 51/84
PS call management
UE
RNS
Mobile is in
IDLE mode
...
SGSN
...
...
...
RANAP Paging
RRC Paging type 1
RRC RACH (RRC connection Request)
RRC FACH (RRC Connection Setup)
RRC RRC Connection Setup Complete
RRC Initial Direct Transfer (Service Request, cause = answer to paging)
The connection
with the SGSN is
setup
RANAP Initial UE msg (Service Request, cause = answer to paging)
... same as previous case ...
Figure 33: resuming DL activity

From the UTRAN (RNC and NodeB) perspective, this is seen as a new mobile
terminated PS call setup. A new RRC connection is setup, and corresponding RAB
resources are established.
From the SGSN point of view, this is seen as a service re-establishment. The RAB
attributes which are sent in the RAB Assignment Request correspond to the PDP
contexts which are activated.
5.4.6 PARAMETERS
This table describes the relevant parameters which may be modified at the OMC-R
level.
Name
Object/Class
Description
Length of the non-sliding time windows, referred to as

AoOnFachParam
Ntti in the description above.
Class 3
From 10 to 10000 step 10 (in ms)
Threshold on user rate for transition to PMM-Idle.
AoOnFachParam
step2ThroughputThreshold
From 0 to 32000 (in bit/s).
Class 3
The recommended value for this parameter is 0.
Timer for transition to PMM-Idle when RAB PS is over
DCH/DCH, referred to as Tinactivity in the description
AlwaysOnTimer above.
timerT2
Class 3
There is one specific value for each of the OLS levels
(Gold, Silver Bronze).
from 10 ms to 180 min step 10 (in ms)
HSDPA/DCH, referred to as Tinactivity in the
AlwaysOnTimer description above.
timerT2ForHsdpa
Class 3
step2AverageWindow
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 52/84
PS call management
Name
Object/Class
Description

HSDPA/E-DCH, referred to as Tinactivity in the
AlwaysOnTimer description above.
Class 3
Table 6: Parameters for CELL_FACH to PMM-Idle transition
Name
Object/Class
Description
AlwaysOnConf /
RadioAccessSer AO timer used for inactivity monitoring
AlwaysOnTimer /
vice Class 3
(T3 for CELL_PCH) : 1..7200 min
CellPCHtoIdleTimer
AlwaysOnConf /
RadioAccessSer AO timer used for inactivity monitoring
AlwaysOnTimer /
vice Class 3
(T3 for URA_PCH) : 1..7200 min
URAPCHtoIdleTimer
Table 7: Parameters for CELL_PCH or URA_PCH to PMM-Idle transition
5.5.
CASE OF SIMULTANEOUS CS & PS SERVICES
5.5.1 PRINCIPLE
In the CS + PS case, "AO Step 1 is not triggered as described in 5.2 since the
mobile cannot be in CELL_FACH state while still satisfying the CS service RAB
parameters. In this case, it is downsized to CS + PS I/B 8/8.
If AO step 2 conditions are met and CELL_PCH or URA_PCH is activated, the call is
reconfigured to CS + PS I/B 0/0. If not, the RAB PS is released if none of CELL_PCH
and URA_PCH is activated.
If a CS call is initiated / received while a PS session is already in the AO step 1 state,
the RNC will transition the PS session to a CS + PS 8/8. Hence, the AO state will be
exited.
When a UE is in CELL_PCH or URA_PCH and a CS call has to be established, the RNC
shall reconfigure the RB to CS + PS I/B 0/0.
When the UE is allocated CS + PS I/B 0/0 and UL or DL PS traffic resumes, the RNC shall
trigger an upsizing. A new UL traffic monitoring mechanism in CELL-DCH state based on
event 4A is configured when entering 0/0 state.
When the CS call is released and the PS RAB is still 0/0 (i.e. no upsizing during the
CS call), the RNC shall move the UE back to CELL_PCH if activated or URA_PCH
otherwise.
In the case of CS + PS configuration, if the idle mode transition criterion is fulfilled, the
PS part of the call is disconnected, so that the UE is in
PMM-Idle state for its PS part
MM-Connected for its CS part
Figure 34 shows what remains once the PS connection with the network has been
released:
the PDP context at the SGSN
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 53/84
PS call management
the PPP link between UE and ISP
the SGSN-GGSN tunnel. The GTP tunnel is kept alive until the PDP context is
deactivated
the RRC connection (maintained because CS service is still active)
the Iu-CS connection and user data bearer
PDP
ctx
GTP tunnel
SGSN
GGSN
PPP
UE
RNC
SRB + RRC connection
SCCP +
Iu-CS bearer
MSC
Figure 34: in CS + PS PMM-Idle state

The transition to PMM-Idle is described in Figure 35. The RRC Radio Bearer Release
procedure is used to remove the PS RAB and associated Radio Bearer. The RRC
connection and CS related resources (RAB and Radio Bearer) are still active.
UE
RNS
SGSN
RRC connection is setup

SCCP connection is setup
PDP context is activated

Mobile is in
CONNECTED
mode
Inactivity timer
RANAP Iu release request
RANAP Iu release command
RRC RB Release (delete PS RB)
RRC RB Release Complete
RANAP Iu Release Complete
All the connections

are released
SCCP Released
Mobile is in
PMM-Idle mode
...
...
...
...
Figure 35: transition to PMM-Idle in the CS + PS case

The UL or DL traffic resuming is described in Figure 36. In the case of DL traffic
resuming, a Paging Type 2 is sent on the DCCH, as the mobile is already connected
with the network.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 54/84
PS call management
UE
RNS
Mobile is in
IDLE mode
...
...
SGSN
...
...
Case of DL traffic
resuming only
RANAP Paging
RRC Paging type 2
RRC Initial Direct Transfer (Service Request)

RANAP Initial UE msg (Service Request)
RANAP/ RAB Assignment Request
RRC/ RB Setup
The connection
with the SGSN is
setup
Radio resource &

connection are
setup

GMM Service Accept
Mobile is in
CONNECTED
mode
User data transfer

can proceed
Figure 36: Resuming UL or DL activity in the CS + PS case
5.5.2 RRC STATE TRANSITIONS IN MULTISERVICE

Following table sums up the RRC transitions for multiservice calls CS + PS I/B:
Initial state
Final state
Relevant timer
Condition
Comment
CELL_DCH (PS R99

I/B TRB + CS + SRB)
CELL_DCH
(downsized R99 PS
I/B TRB + CS + SRB)
TimerT1
Low UL & DL traffic
Existing AO step 1
CELL_DCH
(downsized PS R99
I/B TRB + CS + SRB)
CELL_DCH (CS +
SRB)
TimerT2
No UL & DL traffic on
PS I/B RAB
Existing AO step 2
Downsize
CELL_PCH disabled
URA_PCH disabled
CELL_DCH
(downsized PS R99
I/B TRB + CS + SRB)
CELL_DCH (PS I/B

0/0 + CS + SRB)
FACHToCellPchTimer
PS I/B RAB
CELL_PCH enabled
CELL_DCH
(downsized PS R99
I/B TRB + CS + SRB)
CELL_DCH (PS I/B

0/0 + CS + SRB)
FACHToUraPchTimer
PS I/B RAB
CELL_PCH disabled
URA_PCH enabled
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 55/84
PS call management
Initial state
Final state
Relevant timer
Condition
Comment
CELL_DCH
(downsized R99 PS
I/B TRB + PS
Streaming/Conv RB +
SRB)
CELL_DCH (PS
Streaming/Conv RB +
SRB)
timerT2
PS I/B RAB
Existing AO step 2
CELL_DCH (PS I/B

0/0 + CS + SRB)
CELL_DCH (CS +
SRB)
CellPchToIdleTimer
PS I/B RAB (implicit)
CELL_PCH enabled
CELL_DCH (PS I/B

0/0 + CS + SRB)
CELL_DCH (CS +
SRB)
UraPchToIdleTimer
PS I/B RAB (implicit)
CELL_PCH disabled
URA_PCH enabled
CELL_DCH (PS
HSDPA or EDCH I/B
TRB + CS or PS
Streaming RB + SRB)
CELL_DCH (CS or PS
Streaming RB + SRB)
timerT2ForHsdpa or
timerT2ForHsdpaAndEd
ch
PS I/B RAB
Existing AO step 2
(no AO step 1 applied)
CELL_PCH disabled
URA_PCH disabled
CELL_DCH (PS
HSDPA or EDCH I/B
TRB + CS + SRB)
CELL_DCH (PS I/B

0/0 + CS + SRB)
timerT2ForHsdpa or
timerT2ForHsdpaAndEd
ch
CELL_DCH
(downsized PS I/B
TRB + CS or PS
Streaming RB + SRB)
CELL_FACH
(downsized PS I/B
TRB + SRB)
N/A
CELL_DCH (mux. PS
I/B TRBs + CS or PS
Streaming RB + SRB)
CELL_DCH (CS or PS
Streaming RB + SRB)
timerT2 or
timerT2ForHsdpa
PS I/B RAB
New AO step 2
CELL_PCH enabled
or URA_PCH enabled
Existing transition on
CS / PS Streaming
RAB release
both RABs (on
underlying TrCH)
Existing AO step 2 (no

AO step 1 applied)
CELL_PCH disabled
URA_PCH disabled
CELL_DCH (mux. PS
I/B TRBs + CS +
SRB)
CELL_DCH (MUX PS
I/B 0/0 + CS + SRB)
CELL_DCH (mux. PS
I/B TRBs + CS +
SRB)
CELL_DCH (MUX PS
I/B 0/0 + CS + SRB)
FACHToCellPchTimer
FACHToUraPchTimer
both PS I/B RABs (on
underlying TrCH)
New AO step 2
both PS I/B RABs (on
underlying TrCH)
New AO step 2
CELL_PCH enabled
CELL_PCH disabled
URA_PCH enabled
CELL_DCH (MUX PS
I/B 0/0 + CS + SRB)
CELL_DCH (CS +
SRB)
CellPchToIdleTimer
both PS I/B RABs
(implicit)
CELL_PCH enabled
CELL_DCH (MUX PS
I/B 0/0 + CS + SRB)
CELL_DCH (CS +
SRB)
UraPchToIdleTimer
both PS I/B RABs
(implicit)
CELL_PCH disabled
URA_PCH enabled
Upsize
CELL DCH (CS + PS
I/B downsized + SRB)
CELL DCH (CS + PS

I/B + SRB)
N/A
UL or DL PS traffic
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 56/84
PS call management
Initial state
Final state
Relevant timer
Condition
CELL FACH (PS I/B +

SRB)
CELL DCH (CS + PS

I/B downsized + SRB)
N/A
CS addition
CELL_DCH (PS I/B

0/0 + CS + SRB)
CELL_DCH (PS I/B +

CS + SRB)
N/A
UL or DL PS traffic
CELL_DCH (MUX PS
I/B 0/0+ CS + SRB)
CELL_DCH (mux. PS
I/B TRBs + CS + SRB)
N/A
UL or DL PS traffic
Comment
5.5.3 PARAMETERS
Name
Object/Class
repThreshold
aoOnDchParam
Class 3
timeToTrigger
aoOnDchParam
Class 3
pendTimeAfterTrig
aoOnDchParam
Class 3
txInterruptAfterTrig
aoOnDchParam
Class 3
5.6.
Description
TS 25.331 Reporting Threshold This parameter is part of
the Traffic Volume Measurement Reporting criteria. It is
part of upsize algorithm. It is used as part of event4A
configuration in cell DCH RRC state: threshold with which
the Transport Channel Traffic Volume is compared
25.331 Time to trigger This parameter is part of the Traffic
Volume Measurement Reporting criteria. It indicates the
period of time between the timing of event detection and
the timing of sending Measurement Report. It is part of
upsize algorithm. It's the period of time during which the
condition has be to satisfied before sending a
measurement report. It is used on the event4a reporting in
CELL DCH RRC state.
TS 25.331 Pending time after trigger Ii indicates the period
of time during which it is forbidden to send any new
measurement reports with the same Traffic volume event
identity even if the triggering condition is fulfilled. It is part
of upsize algorithm in CELL DCH RRC state.
TS 25.331 Tx interruption after trigger This 3GPP
parameter is part of the Traffic Volume Measurement
Reporting Criteria designated to indicate how long the UE
shall block the DTCH transmission on RACH after a
measurement report is triggered. It is part of upsize
algorithm in CELL DCH RRC state.
AO COUNTERS
Number of successful downsizing Step 1

PER CELL
#1101 VS.DownsizingStep1Success

per RNC
#1102
VS.DownsizingStep1SuccessNeighbRnc
Number of unsuccessful downsizing Step 1

per CELL
#1103 VS.DownsizingStep1Unsuccess
Number of unsuccessful downsizing Step 1
#1104
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 57/84
PS call management
per RNC
VS.DownsizingStep1UnsuccessNeighbR
nc

per CELL
#1105 VS.DownsizingStep2Success

per RNC
#1106
VS.DownsizingStep2SuccessNeighbRnc
Number of successful upsizing per CELL
#1107 VS.UpsizingSuccess
Number of successful upsizing per RNC
#1108 VS.UpsizingSuccessNeighbRnc
Number of unsuccessful upsizing per CELL
#1109 VS.UpsizingUnsuccess
Number of unsuccessful upsizing per RNC
#1110 VS.UpsizingUnsuccessNeighbRnc
The granularity of these counters is either CELL (case primary cell in the SRNS) or
RNC (case primary cell in the DRNS).
These counters are screened per AsConf of reference (Reference RB bit rate as
defined in section 11.2).
6.
MULTIPLE PS I/B RAB SUPPORT
6.1.
INTRODUCTION
At UA06.0 multiple PS RABs are limited to [Global Market - 2 PS RAB on deployments
with iBTS] and [USA Market - 3PS RAB on deployments with OneBTS].
There may be situations during which the UTRAN is required to manage 2 [USA
Market -or 3] simultaneous PS Interactive/Background RAB for a given user identified
by a single RRC connection:
A user is activating a primary and a secondary PDP context in order to open

bearers with different quality of service towards a given APN (Access Point
Name) or packet network.
A user is activating two primary PDP contexts, each of them corresponding to

a different APN
All I/B RAB are multiplexed onto a single DCH. The set of supported rates are:
UL: 32, 64, [USA Market -8, 128, 384]
DL: 64, 128, [Global Market - 384]
In the case where the different RABs multiplexed onto a DCH have different maximum
bit rates, the RNC will perform a best fit match to the maximum of the RAB rates. e.g.
if the CN requests 128 and 64kbps, the RNC will select the maximum DCH rate as
128kbps.
An example of DL 64+64 is shown in Figure 37. The detailed configuration parameters
are provided in [R5].
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 58/84
PS call management
PDP 1
RAB 1
PDP 2
RAB 2
DL 64
DL 64
DCH
DL 64
SF32
DCCH
DL
3,4
DCH
DL
3,4
DPCH
SF32
Figure 37: multiple PS multiplexing scheme

In this example, the 2 PDP contexts share the 64 kbps bandwidth delivered by the
DCH. This means that each of the 2 PDP contexts may use the available 64 kbps
bandwidth, but not simultaneously. With Interactive/Background traffic models, it is
expected that this configuration is efficient as it offers a statistical multiplexing gain at
a limited cost (slight increase in transmission delay).
For Interactive and Background services, this multiplexing is more efficient from a
radio resource usage than multiplexing two 64 kbps Radio Bearer over a 128 kbps
transport channel. The same is true for the other supported rate combinations.
PS + PS [USA Market - or PS + PS + PS] can also be supported on HS-DSCH, in
which case we have a separate MAC-d flow for each RAB which is multiplexed by the
MAC-HS in the BTS. This is further described in [R3].
6.2.
CALL STATE TRANSITIONS
6.2.1 OVERVIEW
The ability to support multiple PS RAB increases the number of transitions between
Radio Bearer combinations. Table 8 lists all the possible cases. The transitions
specific to Multiple PS RAB support are grayed.
From
To
Service activation use cases:
Nothing
PS
Nothing
PS + PS
Nothing
PS + PS+PS
Nothing
CS + PS
Purpose
Initial PDP activation
User traffic resuming (transition from PMM-Idle
to PMM-Connected)
or incoming 3G to 3G relocation
or 2G to 3G mobility in GPRS multiple PDP
context mode
User traffic resuming (transition from PMM-Idle
to PMM-Connected)
or incoming 3G to 3G relocation
or 2G to 3G mobility in GPRS multiple PDP
context mode
Incoming 3G to 3G relocation
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 59/84
PS call management
From
Nothing
Nothing
CS + PS+PS
To
CS + PS + PS
[USA Market CS + PS + PS+PS]
PS + PS
CS + PS
[USA Market CS + PS + PS]
CS + PS + PS+PS
CS
CS + PS + PS
PS
CS
CS + PS
CS + PS
CS
Purpose
Secondary or multiple primary activation
Initial PDP activation
Secondary or multiple primary
activation/reactivation
User traffic resuming (from PMM-Idle to PMMConnected)
User traffic resuming (from PMM-Idle to PMMConnected)

Service de-activation use cases:
PS
Nothing
PDP de-activation
PS + PS
Nothing
Iu-PS release
CS + PS + PS
Nothing
Outgoing 3G to 3G relocation
[USA Market Nothing
Outgoing 3G to 3G relocation
CS + PS + PS+PS]
PS + PS
PS
PDP de-activation/inactivity
[USA Market PS+PS
PS + PS+PS]
CS + PS
CS
PDP de-activation
CS + PS + PS
CS + PS
PDP de-activation
[USA Market CS + PS+PS
CS + PS + PS+PS]
[USA Market CS + PS
CS + PS + PS+
PS]
CS + PS + PS
CS
Iu-PS release
[USA Market CS
Iu-PS release
CS + PS + PS+PS]
Table 8: Multi PS RAB management use cases
For all cases leading to the simultaneous allocation of two PS RAB, if the RNC fails to
establish one of them (i.e. failure of the CAC or "reject" for one of the RAB in the iRM
table), no partial allocation is allowed by the RNC.
6.2.2 ACTIVATION/DE-ACTIVATION OF PDP CONTEXT

nd
As the 2 RAB is activated, iRM CAC is executed based on the rate associated with
the Radio Bearer.
If successful, the RB is allocated.
In case of failure, the existing RAB is kept unchanged.
nd
As the 2 RAB is de-activated, the user is possibly allocated the same RB resources
as initially allocated (because the RAB matching/mapping algorithm is applied on the
basis of the initial RAB parameters stored in the RNC). However, depending on iRM
CAC result, the user may also be allocated either larger or smaller Radio Bearer due
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 60/84
PS call management
to current network load. Figure 38 shows an example for the case of a 64 + 64 PS
I/B + I/B transition.
2nd RAB
allocation
PS
x Kb/s
SF n
2nd RAB
release
PS+PS
64 Kb/s
SF 32
PS
y Kb/s
SF m
Figure 38: one RAB / two RAB transition

The dataflow in Figure 39 is an example of multiple primary PDP context activation in
the case the mobile is already being assigned a PDP over dedicated radio resources
(DCH).
Similar procedures also apply in the following cases:
The mobile is requesting for a secondary PDP context instead of another

primary
The mobile was in CELL-FACH state instead of CELL_DCH
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 61/84
PS call management
UE
Node B
RNC
SGSN
A PDP context has already been setup. The following resources have been set up:
a SCCP connection over the Iu
a PS RAB for the support of the PDP context
a DCH for the support of associated DCCH (RRC and NAS signalling) and DTCH (PS user data)
The mobile requests another PDP context
GMM/ Activate PDP Context Request
The corresponding Radio Access Bearer is assigned
RANAP/ RAB Assignment Request (RAB param, binding Id)
Even in case the old transport channel was supporting the
same data rate as the new one (e.g. 64Kb/s) a synchronized
reconfiguration is needed due to the fact that the MAC header
is changing (4 additional bits for MAC-d multiplexing)
NBAP/ Radio Link Reconfiguration Prepare

(new transport & physical channel)
NBAP/ Radio Link Reconfiguration Ready
The reconfigured Radio Link is synchronised
UP/ DL Synchronisation (CFN)
UP/ UL Synchronisation (ToA)
NBAP/ Radio Link Reconfiguration Commit (CFN)
The UE is provided with the new radio link configuration.

A new RAB (corresponding to the new DTCH) is added to
the current configuration
RRC/ RB Setup (new DTCH)
The RAB is now established. the mobile is now waiting for end-to-end
connection request
GMM/ Activate PDP Context Accept
Figure 39: Second RAB processing
6.3.
MAC SCHEDULING
Because the DCH transport channel is smaller than the sum of the two or three DTCH
logical channels it supports, the MAC-d entity has to apply a specific scheduling
algorithm.
As allowed in the 3GPP specification, the two different PDP contexts may possibly
have specific A/R (Allocation/Retention) and THP (Traffic Handling Priority) parameter
values.
In order to cope with possibly different Core Network implementation, a table is
defined at the RNC level, allowing to derive the MLP (Mac Logical Priority) from the
OLS (which is a function of the Traffic Class, A/R and THP), as shown below.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 62/84
PS call management
Traffic Class
ARP
THP
OLS
Conversational 1
N/A
Gold
Conversational 2
N/A
Silver
Conversational 3
N/A
Bronze
Streaming
1
N/A
Gold
Streaming
2
N/A
Silver
Streaming
3
N/A
Bronze
Interactive
1
1
Gold
Interactive
1
2
Gold
Interactive
1
3
Gold
Interactive
2
1
Silver
Interactive
2
2
Silver
Interactive
2
3
Silver
Interactive
3
1
Bronze
Interactive
3
2
Bronze
Interactive
3
3
Bronze
Background
1
N/A
Gold
Background
2
NA
Silver
Background
3
N/A
Bronze
Table 9: example of MAC-d priority setting
MLP
N/A
N/A
N/A
N/A
N/A
N/A
8 (highest)
7
6
5
4
3
2
2
2
1
1
1 (lowest)
In case the 2 RAB have the same MLP, a Round-Robin algorithm over the 2/3 DTCH
waiting queues is applied.
In case 2 flows of different priority are multiplexed by the MAC-d, MAC-d scheduling
algorithm ensures the lowest priority queue is not stalled.
6.4.
INTERWORKING WITH ALWAYS-ON
6.4.1 PRINCIPLE
With the PS + PS [USA Market -and PS + PS +PS] RB configuration presented above,
"Always-On" is managed in a simple manner, using the following rules.
If one of the 2/[USA Market -3] RAB is inactive, there is no change to the
configuration (i.e. no synchronous Radio Link or Radio Bearer
reconfiguration).
If the 2 RAB are both inactive (i.e. 0 Kb/s in uplink and downlink during a
certain period of time) then the IU and RRC connection are released, as for
"PMM-Idle state transition" specified in the [Always-On] section 5.
It is managed the same way if there is a simultaneous speech call, with a

small difference in case of no PS traffic (only the Iu-PS connection is
released, the Iu-CS connection is kept)
AO Step 1 is not supported for the case of a PS + PS configuration. However, a

transition to AO step 2 (i.e. CELL_PCH or URA_PCH) may occur.
6.4.2 PMM-IDLE TRANSITION

As the "multiple RAB" traffic profile may be different from the mono RAB case, the
transition to PMM-Idle may be set independently as described in section 6.5allowing a
possibly different value for multiple PS I/B configurations.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 63/84
PS call management
6.4.3 RESUMING USER TRAFFIC

This may happen in the following cases:
For any of the 2 PDP contexts, the Network has to send data to the mobile.
The Network will initiate a Paging procedure followed by a Service Request
procedure initiated by the mobile. This case is already discussed in section
5.4.
For any of the 2 PDP contexts, the mobile has to send data to the Network.
The mobile will initiate a Service Request procedure. This case is already
discussed in section 5.4.
It may also happen that, during the Service Request procedure, the mobile
requests simultaneously for the 2 PDP contexts to support service again. In
this case, the resulting RAB ASSIGNMENT REQUEST message from the
SGSN will contain the 2 corresponding RAB. This case is shown in Figure 40.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 64/84
PS call management
UE
Node B
RNC
SGSN
The mobile is in PMM-Idle. There is no RRC connection.

There are 2 active PDP context, but no associated UTRAN resource (RAB)
The mobile is resuming UL activity on its 2 PDP contexts simultaneously
The mobile requests for a RRC connection to be setup. A DCCH is allocated

in CELL_FACH mode.
RRC/ RACH (RRC connection Request (cause))
RRC/ FACH (RRC Connection Setup (DCCH, U-RNTI))
RRC/ RRC Connection Setup Complete
The mobile requests for resources to support both PDP contexts.
GMM/ Service Request (PDP 1 & PDP 2)
The ciphering and integrity procedures are activated by the serving SGSN
RANAP/ Security Mode Command (UIAx, UEAy)
RRC/ FACH / Security Mode Command
"Common Id" is used to provide the RNC with the user IMSI
RANAP/ Common Id (IMSI)
RRC/ RACH / Security Mode Complete
RANAP/ Security Mode Complete
The reception of "security mode command" by the mobile is an implicit
indication that the Service Request procedure is accepted by the Core
Network.
The corresponding two Radio Access Bearer is
assigned
RANAP/ RAB Assignment Request (RAB1, RAB2)
NBAP/ Radio Link Setup Request
NBAP/ Radio Link Setup response
FP/ DL Synchronisation (CFN)
A new DCH radio link supporting all the DCCH

and the 2 DTCH is setup in the current cell
The DCH is synchronised
FP/ UL Synchronisation (ToA)
The UE is provided with the new radio link configuration.

A new RAB (corresponding to the new DTCH) is added to
the current configuration
RRC/ FACH / RB Setup (DCCH + DTCH + DTCH,
RRC state = CELL_DCH)
RRC/ DCH / RB Setup Complete
The RAB is now established. the mobile is now waiting for end-to-end
connection request
GMM/ Service Accept
Figure 40: Traffic resumption for PS I/B + I/B
6.4.4 ALWAYS-ON AND 1 RAB/2 RAB TRANSITIONS

ALWAYS-ON STATES
The 1 RAB to 2 or 3 RAB transition is supported in any of the following cases :
User with a DCH allocated initially (following RAB assignment)
User in CELL-FACH, following always on step 1 transition to CELL-FACH
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 65/84
PS call management
User in Cell/URA-PCH, following always on step 2 transition to PCH state
INTERACTION BETWEEN ALWAYS-ON PROCESS AND RAB

ALLOCATION
When a RAB is requested by the PS Core Network in addition to an existing one,
Always-On may already be active. Similarly, as one of the 2 established PS RAB is
released following e.g. a PDP context de-activation, Always-on may already be active
on the 2 RAB.
In both cases, the RNC behaves as follows:
6.5.
In the "1 RAB to 2 [USA Market -or 3] RAB" transition, the on-going AlwaysOn process is stopped, meaning that T1 or T2 timers are stopped if running.
Once the new RAB is established and the transport channel is reconfigured
accordingly, Always-on traffic observation on the 2 RAB (as described in the
sections above) is started again.
In the "2 RAB [USA Market -or 3] RAB to 1 RAB" transition, the on-going
Always-On process is stopped, meaning that the T2 timer for multiple PS is
stopped if running. Once the transport channel resources are re-configured,
Always-on traffic observation based on the remaining is started again.
INDIVIDUAL RAB RELEASE
6.5.1 OVERVIEW
The following RRC states and channel types are supported for multiple I/B RABs in
UA06.0 :
2,3 I/B Cell_DCH, DCH/DCH
2,3 I/B Cell_DCH, DCH/HSDPA
2,3 I/B Cell_DCH, DCH/DCH+CS
2,3 I/B Cell_DCH, DCH/HSDPA+CS
2,3 I/B Cell_DCH, 0/0+CS
2,3 I/B Cell/URA_PCH
This leaves the following channel types unsupported for 2,3 I/B:
Cell_DCH, E-DCH/HSDPA
Cell_FACH
6.5.2 [USA MARKET] INDIVIDUAL RAB RELEASE

At UA06.0, the RNC has the capability to monitor activity/inactivity on individual RABs
and trigger RAB release for inactive RABs. In this way the above restrictions
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 66/84
PS call management
associated with multiple RABs (e.g. lack of Cell_FACH or E-DCH) are removed when
the RNC has released down to one I/B RAB.
OAM parameter isMpdpExtendedRabCombsAllowed may be used to enable the
enhanced handling of inactivity release requirements. If set to FALSE, the RNC will
revert back to the UA05 behaviour where the RNC releases the Iu in Cell/URA_PCH
state. If set to TRUE, the RNC performs the enhanced behaviour.
OAM parameter AlwaysOnConf::mpdpInactivityIuRelease is used to determine
whether individual RAB release is supported. If it is set to FALSE, then when there are
more than one PS I/B RABs existing, the RNC will monitor inactivity on RABs and
trigger a RAB release request to the SGSN for an inactive RAB.
The inactivity timers are based upon the following OAM parameters depending upon
the channel type that the RNC has assigned to the UE in Cell_DCH state :
AlwaysOnTimer::tRabInactivityReleaseTimerMpdpDchAndDch
AlwaysOnTimer::tRabInactivityReleaseTimerMpdpHsdpaAndDch
The parameters are defined for each of the OLS levels (Gold, Silver Bronze), in the
case that there are multiple RABs mapped with different OLS, the timer for the most
stringent OLS is used.
The high level call flow for individual RAB release is given in Figure 41. In this call flow
it is seen that the UE starts with two I/B RABs in Cell_DCH state on a Rel-6 mobile.
The RABs are mapped to HSDPA/DCH. Inactivity is detected on one of the RABs and
the RNC triggers a RAB release request. The SGSN responds with a RAB
Assignment response to release the requested RAB. The RNC then performs the RB
release procedure to release down to one RAB and reconfigure the UE onto
HSDPA/E-DCH.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 67/84
PS call management
UE
Node B
RNC
SGSN
Two PS I/B RABs (RAB1, RAB 2) have been set up and the UE is in Cell_DCH on an HSDPA/DCH channel.
The UE is Release-6 and E-DCH capable
The RNC has started inactivity timer based upon OAM parameter
tRabInactivityDchPchMpdpForHsdpaAndDch
RAB2 is inactive for longer than the inactivity time, RNC triggers RAB
release
RANAP/ RAB Release Request (RAB ID,Cause)

SGSN sends RAB Assignment to release the requested
RAB and place it in a preserved state
RANAP/ RAB Assignment Request (RABs to Release List)
RNC determines that the UE will be released down to a single RAB/PDP
context and selects channel E-DCH/HSDPA for the UE
NBAP/ Radio Link Reconfiguration Prepare

(new transport & physical channel)
NBAP/ Radio Link Reconfiguration Ready
The reconfigured Radio Link is synchronised
NBAP/ Radio Link Reconfiguration Commit (CFN)
The UE is provided with the new radio link configuration
going from two to one RAB and mapped to EDCH/HSDPA
RRC/ RB Release (new Transport Channel, one RB)
RRC/ RB Release Complete
The RAB is now released and placed into a preserved state by the SGSN
Figure 41: Individual RAB Release Call Flow

The RNC will use inactivity release to release inactive RABs until one RAB is left, and
once the RNC has released down to one RAB, normal procedures associated with 1
I/B RABs are performed.
The SGSN will preserve any PDP contexts that have had the associated RAB
released, which means that at a user level the service is maintained.
The RNC has the ability to release from 2 to 1 or 3 to 1 RABs. The decision to release
from 3 to 1 RABs is based upon inactivity of a first as described above, plus a hold off
timer (AlwaysOnTimer::tHoldOffMpdp) to allow time for a second RAB to become
inactive. If both RABs become inactive between the inactivity timer and holdoff timer
expiry, the RNC initiates a RAB release request for two RABs.
RAB Release Interactions with XX_PCH state
In the case that the RNC detects individual RAB inactivity whilst in Cell/URA_PCH
state, the RNC will wait until the UE next transitions to Cell_DCH before releasing the
RAB. When the UE transitions from PCH to Cell_DCH state, it runs a 2 second
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 68/84
PS call management
inactivity timer to ensure that the RAB which triggered the transition to Cell_DCH is
not released due to inactivity.
In addition, the RNC will not run PCH to Idle timer whilst multiple I/B RABs exist
towards
the
UE
and
individual
RAB
release
is
enabled
(AlwaysOnConf::mpdpInactivityIuRelease=FALSE).
RAB Release Interactions with Streaming
It should be noted that when Streaming+1,2xI/B RABs exist, the RNC does not
attempt to release the RABs due to inactivity.
6.5.3 REACTIVATION FOLLOWING INDIVIDUAL RAB RELEASE

The re-activation of a RAB from preserved state when a UE already has an existing
RAB in connected mode follows similar procedures to those described in section
6.4.3, with the following differences :
RRC connection is already established
Security procedures are already complete.
For DL initiated traffic there is no paging of the UE or no Service request
For UL initiated traffic, the NAS Service request is explicitly acknowledged by

a NAS Service Accept.
UE
UE has data to
send in a
preserved
context
Node B
RNC
SGSN
Service Request type DATA

Service Accept
RL Reconfig Prepare
Add MAC-d
flow
Establish
MAC-d Flow
Set up new
MAC-d flow
Synchronised
reconfig procedure
RL Reconfig ready
ALCAP ERQ
ALCAP ECF
RL Reconfig Commit
Radio bearer Setup
Radio bearer Setup Complete
Figure 42: UL Re-activation of a RAB from Preserved State When one RAB already Exists on HSDPA
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 69/84
PS call management
UE
Node B
RNC
SGSN

RL Reconfig Prepare
Add MAC-d
flow
Synchronised
reconfig procedure
RL Reconfig ready
ALCAP ERQ
ALCAP ECF
RL Reconfig Commit
Radio bearer Setup
Establish
MAC-d Flow
Set up new
MAC-d flow
SGSN has data to

send in a
preserved context.
RAB Assignment
is sent without
NAS Signalling
Radio bearer Setup Complete

Figure 43: DL Re-activation of a RAB from Preserved State When one RAB already Exists on HSDPA
One noteworthy point is that prior to Rel-7 of the NAS specification (TS 24.008) the
Service request message does not indicate which RABs are triggering the service
request, so the SGSN has no choice but to re-activate all preserved RABs upon
reception of the Service Request (Type=Data).
From Rel-7 the UE may signal in the Service Request (Type=Data) message which
RAB is triggering the Service Request procedure and the SGSN may then select
which RABs to Re-establish.
Different OAM settings can be used to determine different system behaviour as shown
in Table 10 :
mpdpInactivityIuRelease=
TRUE
timerT2ChannelType >=
tRabInactivityDchPchMpdpChann
elType
No Individual RAB release.

Transition to PCH state following
inactivity time
elType.
Iu Release will occur in PCH state
when inactivity is detected on all
RABs with PCHtoIdle timers
TRUE
timerT2ChannelType<
elType
No Individual RAB release. Iu

Release will occur in Cell_DCH
state when inactivity is detected
on all RABs
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 70/84
PS call management
FALSE
tRabInactivityReleaseTimerChann
elType >=
elType
UE transitions to PCH state.

Individual RAB release occurs in
Cell_DCH state.
No Iu Release due to inactivity in
PCH state whilst multiple RABs
exist
FALSE
tRabInactivityReleaseTimerChann
elType <
elType
No transitions to PCH with

multiple RABs
Individual RAB release occurs in
Cell_DCH state.
Table 10: Individual RAB Release Feature Switch Configuration with

isMpdpExtendedRabCombsAllowed=TRUE
[Global
Markets
For
reference,
the
following
behaviour
is
observed
when
isMpdpExtendedRabCombsAllowed=FALSE and the new MPDP inactivity RAB release behaviour is
disabled. OAM parameters tRabInactivityDchPchMpdpChannelType, mpdpInactivityIuRelease are
ignored. The UE transitions to Cell/URA_PCH state when tRabInactivityDchPchMpdpChannelType
expires, and the RNC issues an Iu release when timer CellPchToIdleTimer/ UraPchToIdleTimer
expire].
6.5.4 SGSN CONSIDERATIONS FOR INDIVIDUAL RAB RELEASE

Before enabling individual RAB release in the RNC, the SGSN should be checked for
compatibility with this feature, i.e.
6.6.
SGSN supports preservation of some RABs whilst others are active.
SGSN supports RNC triggered RAB Release request and preserves the
necessary RABs
[USA MARKET] INTERWORKING WITH RB ADAPTATION

At UA06.0 the RNC is capable of performing RB Adaptation on 2 or 3 I/B RABs
mapped to DCH. The way that this is adapted is as follows :
Data Rate Measurements (Section 4.2.2) are adapted to measure the data
rate of the transport channel that all of the radio bearers are MAC-d
multiplexed onto.
Buffer Occupancy Measurements (Section 8.1) are adapted so that the buffer
occupancy is measured as the sum of the RLC buffer occupancy across all of
the RBs.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 71/84
PS call management
In this way, RB adaptation may be applied in the same way for multiple I/B RABs as
for a single I/B RAB.
In addition, new RAB combinations are introduced at UA06.0 for UL DCH rates to
provide more rates to RB adapt between, namely 8kbps, 32kbps, 384kbps on top of
the existing 64kbps and 128kbps.
OAM parameter isMpdpRbAdaptationAllowed is used to switch on and off RB
Adaptation for multiple PDP contexts.
6.7.
COUNTERS
The following events will be observed:
Number of transitions into PS + PS
Number of transitions into PS + PS + Speech
Number of PMM-Idle transitions from the PS + PS configuration
Number of PMM-Idle transitions from the PS + PS + Speech configuration
[USA Market -
6.8.
Number of attempts and successes to setup a PS 'interactive' or 'background'

RAB on top of an existing PS 'interactive' or 'background' RAB for the same
UE.
Number of PS RABs released with 'RAB Release Request' due to inactivity on

top of an existing PS RAB.
Mean number of connections with the UE in Cell_DCH with Multiple PS RABs

for different channel combinations.
SPECIFIC PARAMETERS
Name
[USA Market mpdpInactivityIuReleas

e]
Object/Class
Description
AlwaysOnConf
Class 3-A2
This parameter is used when the UE has multiple I/B PS

RABs present (Without streaming) to determine whether
the RNC releases a RAB after a period of
tRabInactivityReleaseTimerMpdp on the RAB (FALSE), or
whether it releases the whole Iu based upon inactivity on
all of the RABs (TRUE).
In addition, parameter tRabInactivityReleaseTimerMpdp
describes the behavior when this is set to FALSE, and
parameter timerT2 describes the behavior when this is set
to TRUE.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 72/84
PS call management
Name
Object/Class
[USA Market tRabInactivityReleaseTi AlwaysOnConf

merMpdpHsdpaAndDc Class 3-A2
h]
[USA Market AlwaysOnTimer

tRabInactivityReleaseTi
Class 3-A2
merMpdpDchAndDch]
tRabInactivityDchPchM
pdpForHsdpaAndDch
AlwaysOnTimer
Class 3-A2
Description
This parameter is the RAB inactivity time applied when
multiple I/B RABs exist to release a RAB. Upon detection
of inactivity, the RNC requests the release of the inactive
RAB.
A setting of 0 means that the timer is disabled.
(Gold, Silver Bronze), in the case that there are multiple
RABs mapped with different OLS, the timer for the most
This inactivity timer is applied when the UE is mapped onto
HSDPA/DCH channel.
This parameter interacts with the URA_PCH inactivity timer
tRabInactivityDchPchMpdpForHsdpaAndDch as to
whether the RAB release will occur in Cell_DCH or
URA_PCH.
tRabInactivityReleaseTimerMpdpHsdpaAndDch describes
the behavior when alwaysOnConf.mpdpInactivityIuRelease
is set to FALSE, and parameter timerT2 describes the
behavior when this is set to TRUE.
multiple I/B RABs exist to release a RAB. Upon detection
of inactivity, the RNC requests the release of the inactive
RAB.
(Gold, Silver, Bronze), and in case there are multiple RABs
mapped with different OLS, the timer for the most stringent
OLS is used.
DCH/DCH channel.
This parameter interacts with the URA_PCH inactivity timer
tRabInactivityDchPchMpdpForDchAndDch as to whether
the RAB release will occur in Cell_DCH or URA_PCH.
tRabInactivityReleaseTimerMpdpDchAndDch describes
the behavior when alwaysOnConf.mpdpInactivityIuRelease
is set to FALSE, and parameter timerT2 describes the
behavior when this is set to TRUE.
multiple I/B RABs exist to transition a UE into Cell/URA
PCH. Upon detection of inactivity, the RNC performs the
state transition.
HSDPA/DCH channel.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 73/84
PS call management
Name
Object/Class
Description
tRabInactivityDchPchM
pdpForDchAndDch
AlwaysOnTimer
Class 3-A2
[USA Market tHoldOffMpdp]
AlwaysOnTimer
Class 3-A2
[USA Market isThreeRabAllowed]

[USA Market isMpdpRbAdaptationAll
owed]
RadioAccessSer
vice Class 3-A2

multiple I/B RABs exist to transition a UE into Cell/URA
PCH. Upon detection of inactivity, the RNC performs the
state transition.
DCH/DCH channel.
This is the time required for the MAC-d to hold off informing
the RRC that a PS RAB is inactive when there are more
than 2 PS RABs for a UE.
This parameter determines whether three I/B RABs or two
I/B+ 1 Streaming RABs are allowed to be set up.
RadioAccessSer
vice Class 3-A2
This parameter determines whether RB Adaptation is

allowed on multiple I/B RABs.
[USA Market RadioAccessSer

isMpdpExtendedRabCo
vice Class 3-A2
mbsAllowed]
Determines inactivity release behaviour for multiple I/B

RABs :
If set to FALSE, the old behaviour is performed i.e.
individual RAB release due to inactivity is disabled, and the
Iu Release due to inactivity is determined based upon
UA05 behaviour i.e. transition to PCH and then to idle.
If set to TRUE, the new inactivity release behaviour is
performed taking into account parameters
mpdpInactivityIuRelease, timerT2ChannelType and
tRabInactivityDchPchMpdpChannelType,
tRabInactivityReleaseTimerMpdpChannelType
7.
HANDLING OF STREAMING RAB
7.1.
OVERVIEW
Support for streaming type services is focused on the support of Real Time Media
(Video or Audio) Streaming applications. According to [A6], RTP is the recommended
bearer plane protocol for support of the media streaming, whereas RTSP & HTTP are
the control plane protocols. Since a streaming application will generate two different
types of traffic (RTSP and RTP/RTCP traffics) mapping these two types of protocols
onto the following separate UMTS bearers maximizes the performance and flexibility
of the solution:
A UMTS bearer carrying the RTSP signaling traffic: This UMTS bearer will be
based on an Interactive RAB, which may (and in most cases should) be
identified as Signaling (in the RAB Assignment Request from the CN). In this
document, this bearer will be referred as a Signaling RAB.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 74/84
PS call management
A separate UMTS bearer carrying the RTP/RTCP media/feed-back control

traffic: This UMTS bearer will be a streaming RAB.
In support of this, the following capabilities are supported:
7.2.
Multiple Streaming Rates
Multi-service Streaming Support.
Enhanced handling of Streaming RAB
Signaling RAB Handling
Feature inter-working
MULTIPLE STREAMING RATES

The following streaming RB rates are supported:
UL: 16, 32, 128 kbps
DL: 16, 64, 128, 256 kbps or HSDPA
Detailed attributes of these Streaming RB is provided in [R5].
7.3.
MULTI-SERVICE STREAMING SUPPORT

A variety of multi-service combinations are supported (See [R5] for details) :
Standalone PS Streaming (UL: 16, 32 or 128. DL: 16, 64, 128 or 256)
PS Streaming (UL: 16, 32 or 128) + PS Interactive (UL: 8, 16, 32, 64, 128,
384) - UA06.0
PS Streaming (DL: 16, 64, 128, 256 or 384) + PS Interactive (DL: 8) - UA06.0
CS Speech + PS Streaming (UL: 16, 32 or 128. DL: 16, 64, 128 or 256)
CS Speech + PS Streaming (UL: 16, 32 or 128. DL: 16, 64, 128 or 256) + PS
Interactive 8/8
PS Streaming DL and I/B may be supported over HSDPA at UA06.0
CS Speech + PS Streaming DL and I/B may be supported over HSDPA at

UA06.0
[USA Market - PS Streaming DL and 2xI/B may be supported over HSDPA at

UA06.0]
[USA Market - CS Speech + PS Streaming DL and 2xI/B may be supported

over HSDPA at UA06.0]
[USA Market - PS Streaming (UL 16, 32, 64, 128) + PS Interactive (8+8,
64+64) is supported at UA06.0]
[USA Market - CS Speech + PS Streaming (UL 16, 32, 64, 128) + PS

Interactive (8+8, 64+64) is supported at UA06.0]
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 75/84
PS call management
While the configuration details for each of these combinations are provided in [R5], an
example of the basic logical channel multiplexing for the case of PS Streaming DL 64
+ PS I/B over DCH is shown in Figure 44.
PDP 1 - Streaming
RAB 1
DL 64
DCH
DL 64
PDP 2 I/B
RAB 2
DCCH
DL 8
DL
3,4
DCH
DL 8
DCH
DL
3,4
DPCH
SF32
Figure 44: PS Streaming + PS I/B multiplexing

A summary of the transition states is shown in Figure 45.
5.3
PS Streaming Multi-Media
communication:
PS Streaming
+ CS speech
5.3
PS Streaming only
communication
5.6
5.7
CS speech
5.5
5.8
5.9
PS Streaming
PS Streaming
+ CS speech
+ PS I/B 8/8
5.2
CS speech
+ PS I/B 8/8
5.5
B4
5.1
5.4
B3
PS Streaming
+ PS I/B 8/8
B2
PS Streaming only
communication
B1
PS I/B x/y
Standalone
SRB
5.1
B5
With PS I/B used for support

of end to end signalling
PS
CS
I/B
B6
Packet Switched
Circuit Switched
Interactive or Background
Figure 45: Streaming related transition states

B1) Signaling RAB setup.
B2) PS Streaming setup.
B3) The signaling RAB should no more be eligible to Always On, i.e. this transition
would only occur if Core Network initiated release.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 76/84
PS call management
B4) Signaling RAB re-establishment by core network.
B5) PS Streaming release
B6) Signaling RAB release.
5.1) CS speech service activation hit

5.1) Multi-service is not defined in model leading to a matching failure. CS service is
preserved.
5.2) PS streaming service activation hit
5.3) CS Speech service activation hit
5.4) CS Speech service release
5.5) Release of the PS Streaming RAB
5.6) CS Speech service release
5.7) Release of the PS Streaming RAB
5.8) Release of the PS I/B Signaling RAB
5.9) Setup of the PS I/B Signaling RAB
7.4.
ENHANCED HANDLING OF STREAMING RAB

The typical Streaming case is where the requested GBR is equal to or greater than the
lowest provisioned bit rate (RbSetConf): At admission time, the RNC RAB Matching
algorithm, in conjunction with iRM, will select a RB bit rate between GBR and the MBR
ranges based on the subscribers OLS and the current system load. During the call,
the RNC may possibly perform any RB reconfiguration based on radio conditions (i.e.
via iRM Scheduling) between the GBR & MBR ranges. Further details are provided in
[R4].
7.5.
FEATURE INTERWORKING
RAB Matching and iRM:
RAB to RB mapping based on cell load and radio conditions applies to

Streaming RAB and is described in [R4].
RB adaptation:
Streaming RAB: Disabled
Non-Signaling Interactive RAB of multi-service Streaming +I/B: Enabled
Signaling Interactive RAB of multi-service Streaming +I/B: Enabled (8 kbps

rate committed for UL DL necessarily on 8 kbps)
Always-On:
Streaming RAB: Disabled
Signaling Interactive RAB of multi-service Streaming +I/B: Disabled
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 77/84
PS call management
iRM Scheduling:
8.
Streaming RAB: Enabled (requested GBR committed)
Signaling Interactive RAB of multi-service Streaming +I/B: Enabled (8 kbps

rate committed)
STATE TRANSITIONING ENHANCEMENT

[USA Market]
The State Transitioning Enhancement feature introduced in release UA06.0 addresses
the following enhancements related to state transitions:
8.1.
RB Adaptation Enhancements
Initial rate capping during RB reconfiguration
Initial R99 DL Rate Allocation during FACH to DCH transition and Oneshot
Ec/Io report
Ability to retransmit the RRC RB Reconfiguration message for FACH to DCH

and FACH to PCH transitions.
RB ADAPTATION ENHANCEMENTS
Two extra triggers are introduced in RB Adaptation for I/B PS RAB data rate upsizing
in addition to the data throughput triggers described in section 4. These triggers which
are introduced to provide a better responsivity to data traffic increase are:
4A Traffic Volume Measurement (RLC buffer payload) by the UE for UL
Buffer Occupancy measurement by RNC MAC layer for DL
As an adjunct to the 4A measurement a UE Transmit Power additional measurement

is requested of the UE and this allows the RNC to ensure that there is sufficient Tx
power headroom for any UL upsize.
The RB Adaptation is also extended in application to multiple PS RABs as well as
single RABs.
8.1.1 PARAMETERS
Name
Object/Class
isBOTriggerForRbAdaptati RadioAccessSer
onAllowed
vice
isUeTxPowerOn4AAllowed
RadioAccessSer
vice
Description
RB Adaptation activation flag
Determines whether a UE internal measurement is to
be used as an additional measurement on a 4A buffer
occupancy traffic volume measurement report.
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 78/84
PS call management
Name
Object/Class
dchUlBoTrafVolMeas
MeasurementCo
nfClass
dchUlBoTrafVol
Meas
dchUlBoTrafVol
Meas
dchUlBoTrafVol
Meas
repMode
measQtyQty
measQtyAverageTime
rcMeasPendingTriggerTim dchUlBoTrafVol
e
Meas
ueTrafficVolumeInhibitTim
er
RadioAccessSer
vice
ulRbRaTrafficMonitoring.ul
UlRbSetConf
4AParams
ulRbRaTrafficMo
nitoring.ul4APara
ul4ATimeToTrigger
ms
ulRbRaTrafficMo
ul4AThreshold
nitoring.ul4APara
ms
ulRbRaTrafficMo
ul4AMaxRateStep
nitoring.ul4APara
ms
DlRbRaTrafficMonitoring.d
DlRbSetConf
chDlBoTrafVolMeas
dchDlBoTrafVol
Meas
boAverageTimeDlDch
boPendingTriggerTimeDlD dchDlBoTrafVol
ch
Meas
boThresholdDlDch
dchDlBoTrafVol
Meas
boTimeToTriggerDlDch
dchDlBoTrafVol
Meas
8.2.
Description
This parameter contains the data required for the UE
4A Traffic Volume measurement which are required
for State transition in Cell DCH for a data rate
increase triggered in the UL.
Traffic Volume Measurement Report Transfer Mode
on the DCCH (AM/UM)
Measurement type for a traffic volume measurement
Time interval to take an average or a variance on a
traffic volume measurement
Indicates the period of time during which it is
forbidden to send any new measurement reports with
the same TrafficVolume event identity even if the
triggering condition is fulfilled.
A timer run following a RB Adpatation rate change,
during which time any Buffer Occupancy 4A
measurement reports received from the UE shall be
ignored
This SMO (structure) contains all the data required for
UL RB rate adaption traffic monitoring.
Time to trigger for UE traffic volume measurement
(buffer occupancy 4A) in CELL DCH.
Reporting threshold for UE traffic volume
measurement (buffer occupancy 4A) in CELL DCH for
RB Adaptation
Upon reception of a 4A measurement report, the RNC
shall use this parameter to determine the maximum
UL data rate to reconfigure to.
The averaging period for the downlink buffer

occupancy measurement in CELL DCH. A value of
zero will disable averaging
Indicates the period of time during which it is
forbidden to send any new measurement reports with
the same Traffic volume event identity even if the
triggering condition is fulfilled
The threshold of the downlink buffer occupancy in
CELL DCH to trigger a data rate increase. A value of
zero disables the measurement
The period of time between the timing of event
detection and the timing of triggering the downlink
buffer occupancy measurement event
INITIAL RATE CAPPING

The RNC supports Initial rate capping during RB reconfiguration for better use of
Radio, Transport and Node B resources. An OAM configurable cap on the output of
the existing iRM algorithm is provided for different scenarios :
RAB Establishment of DCH/DCH (UL and DL)
RAB Establishment of HS-DSCH/DCH (UL)
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 79/84
PS call management
FACH/PCH to DCH Transition DL Trigger ( UL/DL for R99 and HS-DSCH UL)
FACH/PCH to DCH Transition UL Trigger ( UL/DL for R99 and HS-DSCH UL)
HS-DSCH/DCH to DCH/DCH (DL DCH rate)
HS-DSCH/E-DCH to HS-DSCH/DCH (UL DCH rate)
The OAM parameters are configurable on an RNC basis
8.2.1 PARAMETERS
Name
Object/Class
Description
isOamCappingOfDataAllo
wd
RadioAccessSer
vice
Rate capping activation flag
dchRateCapping
CacConfClass
This parameter is a structure contains all the data

attributes required for DCH Rate Capping
dchRateCapping
Max UL rate during RAB establishment on DCH/DCH
dchRateCapping
Max DL rate during RAB establishment on DCH/DCH
maxUlRateRabEstablishD
chAndDch
maxDlRateRabEstablishD
chAndDch
maxUlRateRabEstablishH
sdpaAndDch
dchRateCapping
maxUlRateTransitionToDc
hDlTriggerDchAndDch
dchRateCapping
hUlTriggerDchAndDch
dchRateCapping
maxDlRateTransitionToDc
hDlTriggerDchAndDch
dchRateCapping
maxDlRateTransitionToDc
hUlTriggerDchAndDch
dchRateCapping
hDlTriggerHsdpaAndDch
dchRateCapping
hUlTriggerHsdpaAndDch
dchRateCapping
maxDlRateHsdpaAndDchT
oDchAndDch
maxUlRateHsdpaAndDchT
oDchAndDch
maxUlRateHsdpaAndEdch
ToHsdpaAndDch
maxDlRateHsdpaAndEdch
ToDchAndDch
maxUlRateHsdpaAndEdch
ToDchAndDch
dchRateCapping
dchRateCapping
dchRateCapping
dchRateCapping
dchRateCapping
Max UL rate during RAB establishment on

HSDPA/DCH
Max UL rate during state transition from Cell_FACH or
XX_PCH to Cell_DCH with a downlink trigger onto
DCH/DCH
XX_PCH to Cell_DCH with an uplink trigger onto
DCH/DCH
Max DL rate during state transition from Cell_FACH or
DCH/DCH
Max DL rate during state transition from Cell_FACH or
DCH/DCH
HSDPA/DCH
HSDPA/DCH
DL rate during RB reconfiguration from HSDPA/DCH
to DCH/DCH
Max UL rate during RB reconfiguration from
HSDPA/DCH to DCH/DCH
HSDPA/E-DCH to HSDPA/DCH
Max DL rate during RB reconfiguration from
HSDPA/E-DCH to DCH/DCH
HSDPA/E-DCH to DCH/DCH
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 80/84
PS call management
8.3.
FACH TO DCH TRANSITION AND EC/IO

The RNC supports the use of a One-Shot Ec/Io report for the Active and Monitored
sets following a transition from Cell_FACH to Cell_DCH so as to improve the reliability
of R99 FACH to DCH transition. The RNC supports two methods of requesting UEs to
initiate these reports:
the broadcast on SIB 11 of a periodic Intra-Frequency measurement of Ec/Io

with Amount of reporting=1 ("One-Shot" report) for the Active set and
Monitored set for a Ec/Io report when the UE transitions to Cell_DCH
the transmission of a measurement control for periodic Intra-Frequency

measurement of Ec/Io with Amount of reporting=1 (One Shot report) for the
Active set and Monitored set for a Ec/Io report when the UE transitions to
Cell_DCH.
Upon reception of a One-Shot Ec/Io report the RNC performs the following actions:
Update the iRM status for the UE
Determine whether to trigger SHO on the neighbour cells based upon

configurable thresholds.
8.3.1 PARAMETERS
Name
Object/Class
isFachToDchEnhancemen RadioAccessSer
tAllowed
vice
isSib11IntraFreqOneShotA
FDDCell
llowed
isIntraFreqOneShotDchAll
owed
RadioAccessSer
vice
intraFreqOneShotFilterCoe MeasurementCo
fficient
nfClass
softHoAddThresholdOneS
hot
RadioAccessSer
vice
boHoldoffTimeInitialDlFach MeasurementCo
Dch
nfClass
8.4.
Description
Determines whether the enhanced handling of Cell
Update and RB Reconfiguration Failure messages is
supported during transition Cell FACH to Cell DCH
Determines whether a oneshot intra-frequency
measurement is transmitted on SIB11
Determines whether a oneshot intra-frequency
measurement is transmitted to the UE when it enters
Cell DCH.
This is used to cater for UEs which do not support the
SIB based measurement reporting.
Filter coefficient for a oneshot intra-frequency
measurement for the case where the measurement
control is sent in Cell DCH
Threshold for addition of a SHO leg from a UE IntraFrequency measurement report following transition to
Cell_DCH state
This parameter defines a period in which the first DL
buffer occupancy measurement is ignored following a
Cell_FACH to Cell_DCH transition
RETRANSMISSION RB RECONFIG FOR FACH TO DCH OR

PCH
The RNC has the ability to retransmit the AM RB reconfiguration message to the UE
for the transition from FACH to DCH or Cell/URA_PCH with the benefit of improved
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 81/84
PS call management
drop call rate for this transition. The number of retransmissions and time interval
between messages is configurable.
8.4.1 PARAMETERS
Name
Object/Class
fachRetransmissions
reconfigRetriesFachDch
reconfigTimeFachDch
reconfigRetriesFachPch
reconfigTimeFachPch
9.
Description
RadioAccessSer
vice
fachRetransmissi
ons
fachRetransmissi
ons
This parameter is a structure contains all the data

attributes required for FACH Retransmissions.
Maximum number of reconfiguration message retries
to transmit for Cell FACH to Cell DCH transition
Timer for retransmission of reconfiguration messages
in Cell FACH for Cell_FACH to Cell_DCH transition
Maximum number of retransmissions of Radio Bearer
fachRetransmissi Reconfiguration message due to response message
ons
timeout to transition a UE from Cell FACH to xx_PCH
state.
fachRetransmissi Timer for response of Radio Bearer reconfiguration
ons
complete for Cell_FACH to xx_PCH transition
RNC INITIATED RAB MODIFICATION

[USA Market]
9.1.
PRINCIPLE
If feature 34226 is enabled, it provides a mechanism for the RNC to request a
downgrade of GBR for a streaming RAB when the GBR can no longer be sustained on
the physical channel. This could be
DL radio link power is no longer sustainable for the UE
UL UE transmit power can no longer sustain the required GBR
RNC or UE experiences congestion
The RNC will request a downgrade by sending a RAB Modify Request to the CN after
receiving either a 6A UE measurement report, or an NBAP dedicated measurement
report indicating that DL transmit code power is too high. The modify request may also
be sent if the RNC needs to downgrade the GBR due to congestion (triggered by PM
id 34227).
9.2.
PARAMETERS
Name
Object/Class
isRncRabModificationAllo
wed
PsCoreNetworkA
RNC initiated RAB modification activation flag
ccess
Description
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 82/84
PS call management
Name
Object/Class
Description
uE6AOffsetFromMax
UlRncRabModM
eas
Threshold for a 6A UE internal measurement

configured for the UE when a PS radio bearer is
present.
UlRncRabModM
eas
DlRncRabModM
eas
uE6AtxPowerFilter
Filter coefficient for UE 6A internal measurement.
Filter coefficient for the NBAP dedicated

measurement.
Parameter used when the RNC determines a target
bit rate for RAB modification. Any bit rate
minRateForRabModificatio RadioAccessSer
corresponding to a guaranteed bit rate lower than this
n
vice
rate in the direction of modification will not be
considered.
Parameter indicated the maximum UL guaranteed bit
RadioAccessSer rate to which a RNC can accept to downgrade a
uLTxcpMaxBitRate
vice
streaming PS RAB when a 6A measurement event is
received.
Period during which the condition of the event 6A
FullEventHOConf
TimeToTrigger6A
must be satisfied before sending a measurement
HhoMgtEvent6A
report.
dLtxCPFilter
9.3.
COUNTERS
Detailed counter information is provided in [R4].
RNC:
Number of attempts the RNC makes to the SGSN to modify a PS RAB with
guaranteed bit rate
FDDCell:
Number of attempts to decrease the data rate on the RB initiated by an RNC

RAB modification
Number of failed attempts to modify the data rate on the RB initiated by an

RNC modification
10. FIELD INTRODUCTION

10.1. HARDWARE CONSTRAINTS
SRB on E-DCH is only supported on xCEM board.
10.2. SPARE PART CONSTRAINTS

Not applicable
10.3. INTER RNS VERSION INTERWORKING

No impact due to AO evolutions:
URA(s) spread over two RNS is not supported in this release
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 83/84
PS call management
URA-PCH, Cell-PCH and Cell-FACH states are not supported over Iur
10.4. CORE NETWORK INTERWORKING

No impact
10.5. UE INTERWORKING
In case the UE does not support the URA-PCH or Cell-PCH RRC state, the RRC
procedure used to reconfigure the UE to this state will fail (e.g. RB
RECONFIGURATION FAILURE).
If for any reason, the reconfiguration fails then the RNC will release the RRC
connection (The UE will be moved to RRC Idle mode).
11. ABBREVIATIONS AND DEFINITIONS

11.1. ABBREVIATIONS
AO
Always On
CAC
Call Admission Control
GBR
Guaranteed Bit Rate
RAB
Radio Access Bearer
RB
Radio Bearer
I/B
Interactive / Background
11.2. DEFINITIONS
Reference RB bit rate: The RAB matching provides a Reference RB bit rate that is
selected among the RB configuration, as the bit rate that is immediately lower or equal
to the Requested Maximum Bit Rate.
PS AO RB: it corresponds to the RB configuration towards which the current RB is
reconfigured as Always-On step 1 downsizing is triggered. PS AO can either be a low
rate RB in CELL_DCH (configurable but generally PS I/B 8/8) or CELL_FACH.
END OF DOCUMENT
UMT/SYS/DD/0034
07.03 /EN
Standard
16/APR/2008
Page 84/84

PS Call Management

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PS Call Management

Uploaded by

Copyright:

Available Formats

PS call management

Copyright 2007 Alcatel-Lucent, All Rights Reserved

Removal of PS RAB modification

Misc editorial corrections/improvements

Removal of support for Cell-DCH 8/8 in AO step 1 (308097)

Disabling AO for a PS Interactive RAB if the Signaling Indicator is set

Feature content from Cell/URA PCH (26673/26675)

SCOPE OF THIS DOCUMENT .......................................................................................................8

AUDIENCE FOR THIS DOCUMENT ................................................................................................8

DEFINITIONS AND SPECIFICATION PRINCIPLES ............................................................................9

RELATED DOCUMENTS ..............................................................................................................9

APPLICABLE DOCUMENTS ..........................................................................................................9

REFERENCE DOCUMENTS ........................................................................................................10

RB ADAPTATION BASED ON TRAFFIC ...................................................................................14

INTERWORKING WITH OTHER FEATURES ...................................................................................28

TRANSITIONS OVERVIEW ..........................................................................................................31

AO STEP 1 IN CELL-FACH .....................................................................................................35

MULTIPLE PS I/B RAB SUPPORT.............................................................................................58

CALL STATE TRANSITIONS .......................................................................................................59

INTERWORKING WITH ALWAYS-ON ...........................................................................................63

SPECIFIC PARAMETERS ...........................................................................................................72

HANDLING OF STREAMING RAB.............................................................................................74

MULTIPLE STREAMING RATES ...................................................................................................75

MULTI-SERVICE STREAMING SUPPORT ......................................................................................75

ENHANCED HANDLING OF STREAMING RAB ................................................................................77

FEATURE INTERWORKING ........................................................................................................77

STATE TRANSITIONING ENHANCEMENT [USA MARKET] ...................................................78

RB ADAPTATION ENHANCEMENTS ............................................................................................78

RNC INITIATED RAB MODIFICATION.......................................................................................82

FIELD INTRODUCTION ..............................................................................................................83

HARDWARE CONSTRAINTS .......................................................................................................83

SPARE PART CONSTRAINTS .....................................................................................................83

INTER RNS VERSION INTERWORKING ......................................................................................83

CORE NETWORK INTERWORKING..............................................................................................84

ABBREVIATIONS AND DEFINITIONS.......................................................................................84

HSDPA/E-DCH including SRB on E-DCH

RB adaptation based on traffic

Always-On & CELL_PCH-URA_PCH

Streaming PS RAB handling

SCOPE OF THIS DOCUMENT

33565 Always-On developments

33581 SRB on E-DCH during call

The HSDPA/E-DCH UA06.0 features are covered by documents [R1]a.[R3] and

Multiple PS RAB Support

State Transitioning enhancement

34227 State Transitioning Enhancement

RNC RAB modification

34170 3 PDP Contexts support in UTRAN

34226 RNC Initiated RAB Modification

AUDIENCE FOR THIS DOCUMENT

DEFINITIONS AND SPECIFICATION PRINCIPLES

This tagging indicates that the enclosed text following the

Common test environments for User Equipment

UTRAN Iu interface RANAP signalling

UTRAN Overall Description

Mobile radio interface layer 3 specification; Core

UMTS Radio Mobility

UTRAN Traffic Management

UMT/SYS/DD/013319 HSDPA System specification

intelligent RAB mapping (iRM)

Radio Bearer Configuration Parameters

TCP Congestion Control

UMT/SYS/DD/018826 Call Admission Control

411-8111-822P1 06.02 AN Observation Counters -Volume 1 (RNC