PS Call Management

PS call management

Document number: UMT/SYS/DD/0034 Document issue: 07.03 / EN Document status: Standard Date: 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 Alcatel-Lucent. 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

Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization

UMT/SYS/DD/0034 07.03 /EN Standard 16/APR/2008 /84

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


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

PS call management



CONTENTS

CONTENTS..............................................................................................................................................5

1. 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

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

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

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

3. HSDPA/E-DCH ............................................................................................................................10

3.1. BACKGROUND ........................................................................................................................10

3.2. SRB ON E-DCH.....................................................................................................................11

3.2.1 E-DCH CONFIGURATION............................................................................................11 3.2.2 SRB MATCHING...........................................................................................................11 3.2.3 Mobility ..........................................................................................................................12 3.2.4 Parameters....................................................................................................................12 3.2.5 Counters........................................................................................................................14

4. 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

4.4. COUNTERS .............................................................................................................................26

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

5. 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

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 WITH RB ADAPTATION ....................................................................................71

6.7. COUNTERS .............................................................................................................................72

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

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

8. 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

PS call management



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

9.1. PRINCIPLE ..............................................................................................................................82

9.2. PARAMETERS .........................................................................................................................82

9.3. COUNTERS .............................................................................................................................83

10. 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

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

11.1. ABBREVIATIONS ......................................................................................................................84

11.2. DEFINITIONS ...........................................................................................................................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 34170 3 PDP Contexts support in UTRAN

• State Transitioning enhancement

o 34227 State Transitioning Enhancement

• RNC RAB modification

o 34226 RNC Initiated RAB Modification

1.3. AUDIENCE FOR THIS DOCUMENT

External document

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

PS call management



[A3] 3GPP TS 25.331 Radio Resource Control (RRC) Protocol Specification

[A4] 3GPP TS 25.401 UTRAN Overall Description

[A5] 3GPP 24.008 Mobile radio interface layer 3 specification; Core Network Protocols

[A6] 3GPP 26.234 End-to-end transparent streaming service; Protocols and codecs

2.2. 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 E-DCH System Specification

[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

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].

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 RAB/Signaling RB SRB #1 SRB #2 SRB #3 SRB #4

Logical channel type DCCH DCCH DCCH DCCH

RLC mode UM AM AM AM

Payload sizes, bit 136 128 128 128

Max data rate, bps Depends on UE category and TTI

RLC

AMD PDU header, bit 8 16 16 16

MAC-es multiplexing 4 logical channel multiplexing

MAC-d PDU size, bit 144

MAC

MAC-e/es header fixed part, bit

18

TrCH type E-DCH

TTI 2 ms

Coding type TC

Layer 1

CRC, bit 24

The E-DCH will be configured using non-scheduled traffic.

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

• 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

reserved0 – Bit 2

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

isSrbOnEdchAllowedWhenTrbOnEdch

RadioAccessService

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

srbQos.srbSpi RadioAccessService

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.

PS call management



source Modification Managed Object radioAccessService parameter name Reserved0 – bit 0 category Reserve

class 3-a2 Associated Event Mobility decision taken for the call domain RNC definition 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]

Optional No Range Bit: 0 or 1 unit Kind of Boolean Initial values [Global Market – 0] [USA Market – 1] Recommended value [Global Market – 0] [USA Market – 1] Upgrade rule [Global Market – 0] [USA Market – 1] Control rule No


class 3-a2 Associated Event Mobility decision taken for the call domain RNC definition 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]



class 3-a2 Associated Event Mobility decision taken for the call domain RNC definition 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]


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

Screening Criteria The screening criteria aims to differentiate a successful configuration due to a mobility action (screening 0) or a reconfiguration of the call (screening 1)

Screening 0 Descr.: This screening shall be used when the SRB on E-DCH is entering a new primary cell. Therefore, it means that the call was already with SRB on E-DCH on the former primary cell. 3GPP: Mobility First release: UA06

Screening 1 Descr.: This screening shall be used 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)

The counter indicates the number of calls that can be candidate for SRB on E-DCH

VS.SRBonEdchEnteringCellAttempt

Screening Criteria 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 0 Descr.: Attempted reconfiguration 3GPP: AttemptedReconfiguration First release: UA06

Screening 1 Descr.: Unsuitable NodeB Capabilities 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)

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.

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.

PS call management



384 256

128 64

32

AO

idle

Always-On process

AO step 1 & 2 Cell-FACH/Cell_PCH, URA-PCH

RB adaptation processes (UL & DL)

AO step3 RRC-Idle, PMM-connected

DCH rate adaptation

8

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].

o 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.

o In UL, the initial bit rate is, in addition, determined according to a pre-configured 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.

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 Tup(RB#n) and the maximum bit rate of the RB#n. (1st 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

o the RLC-SDU buffer occupancy. (2nd upsize in the figure where this last condition is not fulfilled and therefore the upsize not triggered)

PS call management



Bit rate (kbps)

time

384

256

128

Th-up(256)

Th-down(384)

Th-up(128)

Th-down(256)

Allocated RB bit rate

Real bit rate

Low RLC-SDU Buffer Occupancy, thus no Upsize*

Observation duration

RB reconfiguration latency

RB upsize trigger

RB downsize trigger

Legend

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).

PS call management



Bit rate (kbps)

time

384

128

64

Th-up(128)

Th-down(384)

Th-up(64)

Th-down(128)

Allocated RB rate

Real bit rate

Observation duration

RB reconfiguration latency

RB upsize trigger

RB downsize trigger

Legend

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.

PS call management



384

256

128

64

32

DL RB adaptation

384

128

64

32

UL RB adaptation

8

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 (Th-down(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 are OAM configurable (Ul/DlRbRateAdaptationDownsizeThreshold).

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.

PS call management



Congestion window

Time

Slow start Congestion avoidance

Timeout or failure

Slow start threshold

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-by-step 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.

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).

384

256

128

64

32

DL RB adaptation

384

128

64

32

UL RB adaptation

Step-by-step adaptation Multi -stage adaptation

8

8

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.

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.

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

0

1ˆK

i

iRK

R

When the number K of samples is large, ( ) ( )KRR //ˆ σ− 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 Student’s t-distribution with (K-1) degrees of freedom is used. The variance 2σ is also replaced with its estimator 2S as follows:

[ ]( )∑ −−

=⋅

−= 1

0

22 ˆ1

1 K

i RiRS K

The estimation R̂ is considered as reliable if the following condition is fulfilled:

βδ ≤⋅

⋅KR

St K ˆ,

Where

• δ is the confidence level that is targeted (e.g. 95%)

• t K,δ is a coefficient depending on δ and K parameters.

• β is OA&M controllable (RaMaxConfidenceInt) and represents the maximum width of confidence interval of the estimated value R̂ .

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).

time

Start of Traffic Monitoring

R[0]=0 R[1]=0 R[2]=0

T T T T T

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

PS call management



4.3. PARAMETERS


rbRateAdaptationPingPongTimer

RadioAccessService

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

maxDlEstablishmentRbRate

CacConfClass This customer parameter specifies the max DL bit-rate, 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.

maxUlEstablishmentRbRate

CacConfClass 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

dlRbRateAdaptationUpsizeAlgorithm

RadioAccessService

This Customer parameter allows selection of the type of upsize algorithm for DL RB rate adaptation. The possible values are “multiStageUpsize” or “stepByStepUpsize”

isDlRbRateAdaptationAllowed

RadioAccessService

isUlRbRateAdaptationAllowed

RadioAccessService

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”

isDlRbRateAdaptationAllowedForThisDlUserService

DlUserService

isUlRbRateAdaptationAllowedForThisUlUserService

UlUserService

These Manufacturer parameters indicate if the current DL/UL User Service is eligible to “DL / UL RB rate adaptation”. The possible values are “True” or “False”

isDlRbRateAdaptationAllowedForThisDlRbSetConf

DlRbSetConf

isUlRbRateAdaptationAllowedForThisUlRbSetConf

UlRbSetConf

These Customer parameters indicate if the current DL/UL RB is eligible to “DL/UL RB rate adaptation”. The possible values are “True” or “False”

isThisRbRateAdaptationDlRbSetTargetAllowed

DlRbSetConf

isThisRbRateAdaptationUlRbSetTargetAllowed

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. The possible values are “True” or “False”

DlRbRateAdaptationDownsizeThreshold

DlRbSetConf These Customer parameters (one parameter per RB) define the thresholds (expressed as a rate value)

PS call management




UlRbRateAdaptationDownsizeThreshold

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

DlRbRateAdaptationUpsizeThreshold

DlRbSetConf

UlRbRateAdaptationUpsizeThreshold

UlRbSetConf

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:

• threshold (N) < (N) Kbps

• threshold (N-1) < threshold (N)

dlRbRaTrafficMonitoring. raSduQueueThreshold

DlRbSetConf 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 %

dlRbRaTrafficMonitoring. raSduQueueThresholdBytes

DlRbSetConf This Customer parameter represents a threshold (expressed in bytes) over which, a multi-stage upsize of the DL RB should be triggered (provided that multi-stage 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

dlRbRaTrafficMonitoring. RaUnitPeriodTime

DlRbSetConf

ulRbRaTrafficMonitoring. RaUnitPeriodTime

UlRbSetConf

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.

dlRbRaTrafficMonitoring. RaNbOfSample

DlRbSetConf These Customer parameters define the number K of samples to be considered for calculation of the

PS call management




ulRbRaTrafficMonitoring. RaNbOfSample

UlRbSetConf average throughput. They define the size of sliding windows used for the traffic monitoring. The range is from 0 up to 255

dlRbRaTrafficMonitoring. RaModifiedStudentCoef

DlRbSetConf

ulRbRaTrafficMonitoring. RaModifiedStudentCoef

UlRbSetConf

These Customer parameters define the coefficient of

Student t K,δ divided by the square root of

RaNbOfSample (K) and multiplied by 109. The range is from 0 up to 232

dlRbRaTrafficMonitoring. RaMaxConfidenceInt

DlRbSetConf

ulRbRaTrafficMonitoring. RaMaxConfidenceInt

UlRbSetConf

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

dlRbRaTrafficMonitoring. RaMaxConfidenceIntLowBitRate

DlRbSetConf

ulRbRaTrafficMonitoring. RaMaxConfidenceIntLowBitRate

UlRbSetConf

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

dlRbRaTrafficMonitoring. RAthresholdLowBitRate

DlRbSetConf

ulRbRaTrafficMonitoring. RAthresholdLowBitRate

UlRbSetConf

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

4.4. 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

Number of deactivations of the traffic monitoring (RB loses eligibility to DL RB rate adaptation)

#1669 - VS.UEDlRBRateAdapDeactiv

Number of DL RB rate downsize requested by the traffic monitoring

#1672 - VS.UEDlRBRateAdapDownReq

PS call management



Number of DL RB rate upsize requested by the traffic monitoring

#1673 - VS.UEDlRBRateAdapUpReq

Number of successful DL RB rate downsize (RB reconfiguration)

#1674 - VS.UEDlRBRateAdapDownSucc

Number of successful DL RB rate upsize (RB reconfiguration)

#1675 - VS.UEDlRBRateAdapUpSucc

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

Number of activation/modification of the traffic monitoring (RB becomes eligible to UL RB rate adaptation)

#1670 - VS.UEUlRBRateAdapActiv

Number of deactivations of the traffic monitoring (RB loses eligibility to UL RB rate adaptation)

#1671 - VS.UEUlRBRateAdapDeactiv

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 (RB reconfiguration)

#1678 - VS.UEUlRBRateAdapDownSucc

Number of successful UL RB rate upsize (RB reconfiguration)

#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

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 traffic monitoring per CELL

#0653 - VS.UERBRateAdapUpReqCell

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 traffic monitoring per RNC

#0657 - VS.UERBRateAdapUpReqNeighbCell

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

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

Call transition iRM scheduling upgrading

iRM scheduling downgrading

DL RB adaptation upsize

DL RB adaptation downsize

Upgrade through iRM scheduling upgrading

No Yes Yes Yes

Downgrade through iRM scheduling downgrading

Yes No No No

Upsize through DL RB adaptation upsize

No Yes Yes Yes

Downsize through DL RB adaptation downsize

No Yes Yes Yes

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.

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.

o 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.

Normal Mode

Downsized Mode*

(contains sub-steps 1 and 2)

Idle Mode

(a.k.a. Step 3)

Downsizing (Tdownsize expiry) Idle State Transition

(Tinactivity expiry)

RB Restablishment (traffic resumption)

Upsizing (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)

PS call management



• 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).

5.1. 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

Normal Mode

AO Step 1

AO Step 3 AO Step 2

T1 (low traffic) Mobility signalling load criteria

T2

CELL_DCH

CELL_PCH

URA_PCH

RRC / PMM IDLE

T3

T3

CELL_FACH

T2

load criteria

Cell Update signaling load criteria

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).

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)

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

Downsize

CELL_DCH

(PS I/B TRB + SRB)

CELL_FACH (PS I/B

TRB + SRB)

timerT1 or

timerT1ForHsdpa or

timerT1ForHsdpaAndEdch

(T1 timer)

Low UL & DL traffic

Existing AO step 1

CELL_DCH

(PS I/B TRB + SRB)

Idle timerT2 or

timerT2ForHsdpa or

timerT2ForHsdpaAndEdch

(T3 timer)

No UL & DL traffic

AO step 1 disabled

CELL_PCH disabled

URA_PCH disabled

CELL_DCH

(PS I/B TRB + SRB)

CELL_PCH FACHToCellPchTimer

(T2 timer)

No UL & DL traffic

AO step 1 on FACH disabled (TimerT1 is assumed null)

CELL_PCH enabled

CELL_DCH

(PS I/B TRB + SRB)

URA_PCH

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

(T3 timer)

No UL & DL traffic

Existing "AO step 2"

PMM-Idle transition

CELL_PCH disabled

URA_PCH disabled

PS call management




CELL_FACH

(PS I/B TRB + SRB)

CELL_PCH

FACHToCellPchTimer

(T2 timer)

No UL & DL traffic

CELL_PCH enabled

CELL_FACH

(PS I/B TRB + SRB)

URA_PCH

FACHToUraPchTimer

(T2 timer)

No UL & DL traffic

CELL_PCH disabled

URA_PCH enabled

CELL_PCH

Idle

CellPchToIdleTimer

(T3 timer)

No UL & DL signaling

(implicit)

URA_PCH

Idle

UraPchToIdleTimer

(T3 timer)

No UL & DL signaling

(implicit)

CELL_DCH

(mux. PS I/B TRBs + SRB)

Idle

timerT2ForMultiIbRab

(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 No UL & DL traffic on both RAB (on underlying TrCH)

no AO step 1 applied

CELL_PCH enabled

CELL_DCH


URA_PCH

tRabInactivityDchPchMpdp

No UL & DL traffic on both RAB (on underlying TrCH)

no AO step 1 applied

CELL_PCH disabled

URA_PCH enabled

Upsize

CELL_PCH

CELL_FACH

(TRB + SRB)

N/A

UL or DL traffic or (RRC, NAS) signaling

URA_PCH

CELL_FACH

(TRB + SRB)

N/A

UL or DL traffic or (RRC, NAS) signaling

CELL_FACH

(TRB + SRB)

CELL_DCH

(TRB +SRB)

N/A

UL or DL traffic

RAB Assign Request

initiated either on UE or on network request

PS call management




Other cases

CELL_PCH

URA_PCH

N/A

Cell update frequency

URA_PCH enabled

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.

DTCH: 64Kb/s

3 DCCH: 3.4Kb/s DCH SF32

DTCH : 32/32Kb/s

3 DCCH: 13/25Kb/s: RACH/FACH

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

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

RACH/FACH

downsizing

SF32

Upsizing (via iRM)

RACH/FACH

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 CELL-FACH, 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)

PS call management



• upsizing is performed as soon as the user traffic exceeds a given limit

downsizing timer

UL or DL Traffic

Threshold

downsizing timer

downsizing upsizing

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 ( ) sbThresholdThroughputNtti

TBsizeNbTB/<×

during, at least, timerT1 seconds

The UL 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 ( ) sbThresholdThroughputNtti

TBsizeNbTB/<×

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.

PS call management



threshold

DTCH RLC/MACbuffer

DTCH RLC/MACbuffer

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.

Threshold

Transport Channel Traffic Volume

Reporting event 4A

Time

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.

PS call management



SGSN Node B RNC UE

NBAP/ Radio Link Deletion Request

NBAP/ Radio Link Deletion Response

RRC/ DCH / RB Reconfiguration (RRC state = CELL_FACH,

Frequency Info,C-RNTI,

Primary CPICH Info)

RRC/ RACH / RB Reconfiguration Complete

Based on Always-On criteria,and after pre-CAC on the primary cell, the mobile is moved to the CELL_FACH state

The old Radio Link is released at the NodeB

Figure 15: CELL_DCH to CELL_FACH transition

SGSN Node B RNC UE

NBAP/ Radio Link Deletion Request

NBAP/ Radio Link Deletion Response

RRC/ DCH / RB Reconfiguration ( RRC state = CELL_FACH,

Frequency Info, Primary CPICH Info)

RRC/ RACH / RB Reconfiguration Complete

Based on Always-On criteria,and after pre-CAC on the primary cell, the mobile is moved to the CELL_FACH state

The old Radio Link is released at the NodeB

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

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.

SGSN Node B RNC UE

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

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

Figure 17: CELL_FACH to CELL_DCH transition

PS call management



5.2.5 PARAMETERS

Table 4 enumerates the parameters that can be modified at the OMC-R level.


repThreshold AoOnFachParam Class 3

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.

timeToTrigger AoOnFachParam Class 3

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.

step1AverageWindow AoOnFachParam Class 3

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)

step1DlRlcBoThreshold AoOnFachParam Class 3

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

step1DlUlThroughputThreshold

AoOnFachParam Class 3

Threshold on user rate for DL and UL transition from CELL_DCH to CELL_FACH. From 0 to 32000 (in bit/s)

timerT1 AlwaysOnTimer Class 3

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 Cell-DCH” and “AO Step 1 in Cell-FACH” From 10 ms to 60 min, step 10 (in ms)

timerT1ForHsdpa AlwaysOnTimer Class 3

Timer for uplink/downlink downsizing for a PS RAB on HSDPA/DCH. There is one specific value for each of the OLS levels (Gold, Silver Bronze). This parameter is common to “AO Step 1 in Cell-DCH” and “AO Step 1 in Cell-FACH” From 10 ms to 60 min, step 10 (in ms)

timerT1ForHsdpaAndEdch AlwaysOnTimer Class 3

Timer for uplink/downlink downsizing for a PS RAB on HSDPA/E-DCH. There is one specific value for each of the OLS levels (Gold, Silver Bronze). This parameter is common to “AO Step 1 in Cell-DCH” and “AO Step 1 in Cell-FACH” From 10 ms to 60 min, step 10 (in ms)

isAlwaysOnAllowed AlwaysOnConf Class 3

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”

PS call management




isAlwaysOnAllowed DlUserService Class 3

This parameter is used to activate/de-activate the “Always On” features. It is available for each downlink RAB configuration. The possible values are:

• False • True

isAlwaysOnAllowed UlUserService Class 3

This parameter is used to activate/de-activate the “Always On” features. It is available for each uplink RAB configuration. The possible values are:

• False • True

isAlwaysOnAllowed DlRbSetConf Class 3

This parameter is used to activate/de-activate the “Always On” features. It is available for each downlink Radio Bearer configuration. The possible values are:

• Disabled • Degraded2AlwaysOnOnly • ReleaseOnly

isAlwaysOnAllowed UlRbSetConf Class 3

This parameter is used to activate/de-activate the “Always On” features. It is available for each uplink Radio Bearer configuration. The possible values are:

• Disabled • Degraded2AlwaysOnOnly • ReleaseOnly

Table 4: AO related params

Remark on activation/de-activation parameters :

Always-On is only active for a given radio bearer if all the conditions are fulfilled:

• 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.

o 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.

5.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

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.

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.

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.

UE UTRAN

DCCH/RB Reconfiguration (state = URA_PCH; URA_identity; freq info)

DCCH/RB Reconfiguration Complete

URA update only if UE selects another URA than the one assigned

CCCH/URA Update (URA reselection)

DCCH/URA Update Confirm

UE UTRAN

DCCH/RB Reconfiguration (state = CELL_PCH; freq info)


Cell update only if UE selects another cell or if it comes from CELL_DCH (no “Primary CPICH info” provided in reconfiguration)

CCCH/Cell Update (cell reselection)

DCCH/Cell Update Confirm

PS call management



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).

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.

Figure 22: DL Data transfer request (FACH)

UE UTRAN

RACH/CELL UPDATE (uplink data tx)

FACH/CELL UPDATE CONFIRM (RB reconfiguration)

DCCH/RB RECONF COMPLETE

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

UE UTRAN

PCH/Paging Type 1

CCCH/Cell Update (paging response)

CCCH/Cell Update Confirm (RRC state=CELL_FACH; C-

RNTI) DCCH/UTRAN Mobility Info

Confirm

CN

data

RRC state is CELL_FACH

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.

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.

Figure 24: UE Service request

UE UTRAN

PCH/Paging Type 1


CCCH/Cell Update Confirm (RRC state=CELL_DCH; RB info

to reconfigure)


CN

data


UE UTRAN

CCCH/CELL UPDATE (uplink data tx)

CCCH/CELL UPDATE CONFIRM (RRC state= CELL_FACH; C-RNTI)

DCCH/UTRAN MOBILITY INFO CONFIRM

RRC state is CELL_FACH, except in the case of PS I/B+PS I/B where it is CELL_DCH

DCCH/Initial Direct Transfer (Service Request)

CN

Direct Transfer (Service Request)

Other phases of the setup are not of interest and not show here…

RAB Assignment Request

RAB Assignment Response

DCCH/RB Setup

DCCH/RB Setup Complete

RRC state is CELL_DCH. Reconfiguration is synchronous if coming from CELL_DCH, else it is asynchronous

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.

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.

Figure 26: PS Request

UE UTRAN

CCCH/CELL UPDATE (paging response)

CCCH/CELL UPDATE CONFIRM (RB setup)

DCCH/RB SETUP COMPLETE


CN



PCH/Paging Type 1

UE UTRAN

CCCH/CELL UPDATE (paging response)

CCCH/CELL UPDATE CONFIRM (RRC state=CELL_DCH; RB info to

reconfigure)



DCCH/Initial Direct Transfer (Paging Response)

CN

Paging

Other phases of the setup are not of interest…



DCCH/RB Setup

DCCH/RB Setup Complete

RRC state is CELL_DCH. Reconfiguration is synchronous

Direct Transfer (Service Request)

PCH/Paging Type 1

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


PchRRCStates (none, UraPchEnabled, CellPchEnabled,UraAndCellPchEnabled)

RadioAccessService Class 3 Enables/disables the PCH related states.

nbOfCellUpdatesFromCellPchToUraPch (1..65535)

RadioAccessService 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


AO timer used for inactivity monitoring

AlwaysOnConf / AlwaysOnTimer / FACHtoURAPCHTimer (aka T2 for URA_PCH) : 1..3600s



AlwaysOnConf / AlwaysOnTimer / CellPCHtoIdleTimer (aka T3 for Cell_PCH) : 1..7200mn



AlwaysOnConf / AlwaysOnTimer / URAPCHtoIdleTimer (aka T3 for URA_PCH) : 1..7200mn

RadioAccessService Class 3 AO timer used for inactivity monitoring

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

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:

• Number of paging (type 1) sent on PCCH

o CELL_PCH

o URA_PCH

• Number of URA update received

o Change of URA

o Periodic URA update

• Number of URA update rejected

o Unknown U-RNTI

o Incorrect message

o FACH CAC failure

o Other

5.4. "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 PMM-CONNECTED 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).

PMM-DETACHED

PS Attach

PS SignallingConnection Release

PS SignallingConnection Establish

PS Detach

PMM-CONNECTEDPMM-IDLE

Detach

SM-ACTIVE orINACTIVE

SM-ACTIVE orINACTIVE

Mobile cannot bereached

Mobile can be reachedPDP context is active

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.

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

UE RNC SGSN GGSN

GTP tunnel

PPP

PDPctx

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)

PS call management



downsizing timer

UL or DL Traffic

downsizing timer

"Idle MM"transition

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 windows. The following parameters are used: • Ntti: length of the time window in TTI (Ntti is therefore a multiple of 10ms) • NbTB: Number of Transport Blocks transferred during the time window • 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.

PS call management



RNS SGSN UE

Packet Transfer Uplink & Downlink

RRC connection is setup

SCCP connection is setup

PDP context is activated

Inactivity timer

RANAP Iu release command

RRC RRC Connection Release

RRC RRC Connection Release Complete

SCCP Released

RANAP Iu Release Complete

... ... ... ...

All the connections are released

Mobile is in IDLE mode

Mobile is in CONNECTED

mode

RANAP Iu release request

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.

Figure 31: Release from CELL_PCH or URA_PCH

UE UTRAN

PCH/Paging Type 1


CCCH/RRC Connection Release

CN

Iu Release Request

Iu Release Command

Iu Release Complete

Possibly repeated

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.

RNS SGSNUE

... ... ... ...

RRC RACH (RRC connection Request)

RRC FACH (RRC Connection Setup

RRC RRC Connection Setup Complete

SCCP Connection Request

SCCP Connection Confirm

RRC Initial Direct Transfer (Service Request)

RANAP Initial UE msg (Service Request)

The RRCconnection is setupon mobile request

The connection withthe SGSN is setup

GMM Service Accept


RANAP/ RAB Assignment Response

RANAP/ RAB Assignment RequestRRC/ RB Setup

RRC/ RB Setup Complete

Radio resource &connection are setup

User data transfercan proceed

Mobile is inIDLE mode

Mobile is inCONNECTED

mode

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.

PS call management



RNS SGSN UE

... ... ... ...

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)

RANAP Initial UE msg (Service Request, cause = answer to paging)

The connection with the SGSN is setup


RANAP Paging

RRC Paging type 1

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


step2AverageWindow AoOnFachParam Class 3

Length of the non-sliding time windows, referred to as Ntti in the description above. From 10 to 10000 step 10 (in ms)

step2ThroughputThreshold AoOnFachParam Class 3

Threshold on user rate for transition to PMM-Idle. From 0 to 32000 (in bit/s). The recommended value for this parameter is 0.

timerT2 AlwaysOnTimer Class 3

Timer for transition to PMM-Idle when RAB PS is over DCH/DCH, referred to as Tinactivity in the description above. There is one specific value for each of the OLS levels (Gold, Silver Bronze). from 10 ms to 180 min step 10 (in ms)

timerT2ForHsdpa AlwaysOnTimer Class 3

Timer for transition to PMM-Idle when RAB PS is over HSDPA/DCH, referred to as Tinactivity in the description above. There is one specific value for each of the OLS levels (Gold, Silver Bronze). from 10 ms to 180 min step 10 (in ms)

PS call management




timerT2ForHsdpaAndEdch AlwaysOnTimer Class 3

Timer for transition to PMM-Idle when RAB PS is over HSDPA/E-DCH, referred to as Tinactivity in the description above. There is one specific value for each of the OLS levels (Gold, Silver Bronze). from 10 ms to 180 min step 10 (in ms)

Table 6: Parameters for CELL_FACH to PMM-Idle transition


AlwaysOnConf / AlwaysOnTimer / CellPCHtoIdleTimer


AO timer used for inactivity monitoring (T3 for CELL_PCH) : 1..7200 min

AlwaysOnConf / AlwaysOnTimer / URAPCHtoIdleTimer


AO timer used for inactivity monitoring (T3 for URA_PCH) : 1..7200 min

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

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

UE RNC

SGSN

MSC SRB + RRC connection

GGSN

GTP tunnel

PDP ctx

PPP

SCCP + Iu-CS bearer

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.

RNS SGSN UE


RRC connection is setup

SCCP connection is setup

PDP context is activated

Inactivity timer

RANAP Iu release command

RRC RB Release (delete PS RB)

RRC RB Release Complete

SCCP Released

RANAP Iu Release Complete

... ... ... ...

All the connections are released

Mobile is in PMM-Idle mode


mode

RANAP Iu release request

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.

PS call management



RNS SGSN UE

... ... ... ...



RRC Initial Direct Transfer (Service Request)

RANAP Initial UE msg (Service Request)

The connection with the SGSN is setup

GMM Service Accept



RANAP/ RAB Assignment Request RRC/ RB Setup


Radio resource & connection are setup

User data transfer can proceed



mode

RANAP Paging RRC Paging type 2

Case of DL traffic resuming only

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:


Downsize

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

CELL_PCH disabled

URA_PCH disabled


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

FACHToCellPchTimer No UL & DL traffic on PS I/B RAB

CELL_PCH enabled



FACHToUraPchTimer No UL & DL traffic on PS I/B RAB

CELL_PCH disabled

URA_PCH enabled

PS call management




CELL_DCH (downsized R99 PS I/B TRB + PS Streaming/Conv RB + SRB)

CELL_DCH (PS Streaming/Conv RB + SRB)

timerT2 No UL & DL traffic on PS I/B RAB

Existing AO step 2


CELL_DCH (CS + SRB)

CellPchToIdleTimer No UL & DL traffic on PS I/B RAB (implicit)

CELL_PCH enabled


CELL_DCH (CS + SRB)

UraPchToIdleTimer No UL & DL traffic on 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 timerT2ForHsdpaAndEdch

No UL & DL traffic on 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)


timerT2ForHsdpa or timerT2ForHsdpaAndEdch

No UL & DL traffic on PS I/B RAB

New AO step 2

CELL_PCH enabled or URA_PCH enabled

CELL_DCH (downsized PS I/B TRB + CS or PS Streaming RB + SRB)

CELL_FACH (downsized PS I/B TRB + SRB)

N/A Existing transition on CS / PS Streaming RAB release

CELL_DCH (mux. PS I/B TRBs + CS or PS Streaming RB + SRB)

CELL_DCH (CS or PS Streaming RB + SRB)

timerT2 or timerT2ForHsdpa

No UL & DL traffic on 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)

FACHToCellPchTimer No UL & DL traffic on both PS I/B RABs (on underlying TrCH)

New AO step 2

CELL_PCH enabled



FACHToUraPchTimer No UL & DL traffic on both PS I/B RABs (on underlying TrCH)

New AO step 2

CELL_PCH disabled

URA_PCH enabled


CELL_DCH (CS + SRB)

CellPchToIdleTimer No UL & DL traffic on both PS I/B RABs (implicit)

CELL_PCH enabled


CELL_DCH (CS + SRB)

UraPchToIdleTimer No UL & DL traffic on 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

PS call management




CELL FACH (PS I/B + SRB)

CELL DCH (CS + PS I/B downsized + SRB)

N/A CS addition


CELL_DCH (PS I/B + CS + SRB)


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



5.5.3 PARAMETERS


repThreshold

aoOnDchParam Class 3

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

timeToTrigger aoOnDchParam Class 3

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.

pendTimeAfterTrig aoOnDchParam Class 3

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.

txInterruptAfterTrig aoOnDchParam Class 3

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.

5.6. AO COUNTERS

Number of successful downsizing Step 1 PER CELL

#1101 VS.DownsizingStep1Success

Number of successful downsizing Step 1 per RNC

#1102 VS.DownsizingStep1SuccessNeighbRnc

Number of unsuccessful downsizing Step 1 per CELL

#1103 VS.DownsizingStep1Unsuccess

Number of unsuccessful downsizing Step 1 #1104

PS call management



per RNC VS.DownsizingStep1UnsuccessNeighbRnc

Number of successful downsizing Step 2 per CELL

#1105 VS.DownsizingStep2Success

Number of successful downsizing Step 2 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].

PS call management



DPCH SF32

DCH DL 64 SF32

DL 64 DL 64

PDP 1 RAB 1

PDP 2 RAB 2

DL 3,4

DCCH

DCH DL 3,4

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 Purpose Service activation use cases: Nothing PS Initial PDP activation Nothing PS + PS 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

Nothing PS + PS+PS 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

Nothing CS + PS Incoming 3G to 3G relocation

PS call management



From To Purpose Nothing CS + PS + PS Incoming 3G to 3G relocation Nothing [USA Market -

CS + PS + PS+PS] Incoming 3G to 3G relocation

PS PS + PS Secondary or multiple primary activation CS CS + PS Initial PDP activation CS + PS [USA Market -

CS + PS + PS] Secondary or multiple primary activation/reactivation

CS + PS [USA Market -CS + PS + PS+PS]

Secondary or multiple primary activation/reactivation

CS + PS+PS CS + PS + PS+PS Secondary or multiple primary activation/reactivation

CS CS + PS + PS User traffic resuming (from PMM-Idle to PMM-Connected)

CS [USA Market -CS + PS + PS+PS]

User traffic resuming (from PMM-Idle to PMM-Connected)

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 -CS + PS + PS+PS]

Nothing Outgoing 3G to 3G relocation

PS + PS PS PDP de-activation/inactivity [USA Market -PS + PS+PS]

PS+PS PDP de-activation/inactivity

CS + PS CS PDP de-activation CS + PS + PS CS + PS PDP de-activation [USA Market -CS + PS + PS+PS]

CS + PS+PS PDP de-activation/inactivity

[USA Market -CS + PS + PS+ PS]

CS + PS PDP de-activation/inactivity

CS + PS + PS CS Iu-PS release [USA Market -CS + PS + PS+PS]

CS Iu-PS release

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

As the 2nd 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.

As the 2nd 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

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.

PS+PS 64 Kb/s SF 32

2nd RAB allocation

2nd RAB release

PS x Kb/s SF n

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

PS call management



SGSN Node B RNC UE

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)


RANAP/ RAB Assignment Request (RAB param, binding Id)

RRC/ RB Setup (new DTCH)


The corresponding Radio Access Bearer is assigned

UP/ DL Synchronisation (CFN)

UP/ 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

NBAP/ Radio Link Reconfiguration Prepare (new transport & physical channel)

NBAP/ Radio Link Reconfiguration Ready

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 Commit (CFN)

The reconfigured Radio Link is synchronised

The RAB is now established. the mobile is now waiting for end-to-end connection request

GMM/ Activate PDP Context Request

The mobile requests another PDP context

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.

PS call management



Traffic Class ARP THP OLS MLP Conversational 1 N/A Gold N/A Conversational 2 N/A Silver N/A Conversational 3 N/A Bronze N/A Streaming 1 N/A Gold N/A Streaming 2 N/A Silver N/A Streaming 3 N/A Bronze N/A Interactive 1 1 Gold 8 (highest) Interactive 1 2 Gold 7 Interactive 1 3 Gold 6 Interactive 2 1 Silver 5 Interactive 2 2 Silver 4 Interactive 2 3 Silver 3 Interactive 3 1 Bronze 2 Interactive 3 2 Bronze 2 Interactive 3 3 Bronze 2 Background 1 N/A Gold 1 Background 2 NA Silver 1 Background 3 N/A Bronze 1 (lowest)

Table 9: example of MAC-d priority setting

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.

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.

PS call management



SGSN Node B RNC UE

• 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


RANAP/ RAB Assignment Request (RAB1, RAB2)

The corresponding two Radio Access Bearer is assigned

The RAB is now established. the mobile is now waiting for end-to-end connection request

GMM/ Service Request (PDP 1 & PDP 2)

The mobile requests for resources to support both PDP contexts.

RRC/ RACH (RRC connection Request (cause))

RRC/ FACH (RRC Connection Setup (DCCH, U-RNTI))

RRC/ RRC Connection Setup Complete

The mobile requests for a RRC connection to be setup. A DCCH is allocated in CELL_FACH mode.

NBAP/ Radio Link Setup Request

NBAP/ Radio Link Setup response

A new DCH radio link supporting all the DCCH and the 2 DTCH is setup in the current cell

FP/ DL Synchronisation (CFN)

FP/ UL Synchronisation (ToA)

The DCH is synchronised

RRC/ FACH / RB Setup (DCCH + DTCH + DTCH, RRC state = CELL_DCH)

RRC/ DCH / RB Setup Complete

The UE is provided with the new radio link configuration. A new RAB (corresponding to the new DTCH) is added to the current configuration

RANAP/ Security Mode Command (UIAx, UEAy)

RANAP/ Security Mode Complete

RRC/ FACH / Security Mode Command

RRC/ RACH / Security Mode Complete

The ciphering and integrity procedures are activated by the serving SGSN

RANAP/ Common Id (IMSI)

"Common Id" is used to provide the RNC with the user IMSI

The reception of "security mode command" by the mobile is an implicit indication that the Service Request procedure is accepted by the Core Network.

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”

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:

• In the "1 RAB to 2 [USA Market -or 3] RAB" transition, the on-going Always-On 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.

6.5. 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

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.

PS call management



SGSN Node B RNC UE

• 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


RANAP/ RAB Assignment Request (RABs to Release List)

RRC/ RB Release (new Transport Channel, one RB)

RRC/ RB Release Complete

SGSN sends RAB Assignment to release the requested RAB and place it in a preserved state

The UE is provided with the new radio link configuration going from two to one RAB and mapped to E-DCH/HSDPA

NBAP/ Radio Link Reconfiguration Prepare (new transport & physical channel)

NBAP/ Radio Link Reconfiguration Ready

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 Commit (CFN)

The reconfigured Radio Link is synchronised

The RAB is now released and placed into a preserved state by the SGSN

RAB2 is inactive for longer than the inactivity time, RNC triggers RAB release

RANAP/ RAB Release Request (RAB ID,Cause)

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

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 Node B RNC SGSN


UE has data to send in a preserved context

Service Request type DATA

RL Reconfig Prepare

RL Reconfig ready

Radio bearer Setup

Radio bearer Setup Complete RAB Assignment Response

Add MAC-d flow

Set up new MAC-d flow

Synchronised reconfig procedure

Service Accept

ALCAP ERQ

ALCAP ECF Establish MAC-d Flow

RL Reconfig Commit

Figure 42: UL Re-activation of a RAB from Preserved State When one RAB already Exists on HSDPA

PS call management



UE Node B RNC SGSN


SGSN has data to send in a preserved context. RAB Assignment is sent without NAS Signalling

RL Reconfig Prepare

RL Reconfig ready

Radio bearer Setup

Radio bearer Setup Complete RAB Assignment Response

Add MAC-d flow

Set up new MAC-d flow

Synchronised reconfig procedure

ALCAP ERQ

ALCAP ECF Establish MAC-d Flow

RL Reconfig Commit

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 >= tRabInactivityDchPchMpdpChannelType

No Individual RAB release.

Transition to PCH state following inactivity time tRabInactivityDchPchMpdpChannelType.

Iu Release will occur in PCH state when inactivity is detected on all RABs with PCHtoIdle timers

mpdpInactivityIuRelease= TRUE

timerT2ChannelType< tRabInactivityDchPchMpdpChannelType

No Individual RAB release. Iu Release will occur in Cell_DCH state when inactivity is detected on all RABs

PS call management



mpdpInactivityIuRelease= FALSE

tRabInactivityReleaseTimerChannelType >= tRabInactivityDchPchMpdpChannelType

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

mpdpInactivityIuRelease= FALSE

tRabInactivityReleaseTimerChannelType < tRabInactivityDchPchMpdpChannelType

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.

• SGSN supports preservation of some RABs whilst others are active.

• SGSN supports RNC triggered RAB Release request and preserves the necessary RABs

6.6. [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.

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 -

• 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.

6.8. SPECIFIC PARAMETERS


[USA Market - mpdpInactivityIuRelease]

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.

PS call management




[USA Market - tRabInactivityReleaseTimerMpdpHsdpaAndDch]

AlwaysOnConf Class 3-A2

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. There is one specific value 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. 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.

[USA Market - tRabInactivityReleaseTimerMpdpDchAndDch]

AlwaysOnTimer Class 3-A2

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. There is one specific value for each of the OLS levels (Gold, Silver, Bronze), and in case there are multiple RABs mapped with different OLS, the timer for the most stringent OLS is used. This inactivity timer is applied when the UE is mapped onto 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.

tRabInactivityDchPchMpdpForHsdpaAndDch


This parameter is the RAB inactivity time applied when multiple I/B RABs exist to transition a UE into Cell/URA PCH. Upon detection of inactivity, the RNC performs the state transition. A setting of 0 means that the timer is disabled. There is one specific value 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. This inactivity timer is applied when the UE is mapped onto HSDPA/DCH channel.

PS call management




tRabInactivityDchPchMpdpForDchAndDch


This parameter is the RAB inactivity time applied when multiple I/B RABs exist to transition a UE into Cell/URA PCH. Upon detection of inactivity, the RNC performs the state transition. A setting of 0 means that the timer is disabled. There is one specific value 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. This inactivity timer is applied when the UE is mapped onto DCH/DCH channel.

[USA Market - tHoldOffMpdp]


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. There is one specific value 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.

[USA Market - isThreeRabAllowed]

RadioAccessService Class 3-A2

This parameter determines whether three I/B RABs or two I/B+ 1 Streaming RABs are allowed to be set up.

[USA Market - isMpdpRbAdaptationAllowed]


This parameter determines whether RB Adaptation is allowed on multiple I/B RABs.

[USA Market - isMpdpExtendedRabCombsAllowed]


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”.

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:

• Multiple Streaming Rates

• Multi-service Streaming Support.

• Enhanced handling of Streaming RAB

• Signaling RAB Handling

• Feature inter-working

7.2. 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]

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.

DCH DL 64

DL 64 DL 8

PDP 1 - Streaming RAB 1

PDP 2 – I/B RAB 2

DCH DL 8

DPCH SF32

DL 3,4

DCCH

DCH DL 3,4

Figure 44: PS Streaming + PS I/B multiplexing

A summary of the transition states is shown in Figure 45.

PS Streaming + CS speech + PS I/B 8/8

Standalone SRB

5.3

PS Streaming Multi-Media communication:

PS Streaming only communication

PS Packet Switched CS Circuit Switched I/B Interactive or Background

CS speech + PS I/B 8/8

PS Streaming + CS speech

PS Streaming + PS I/B 8/8

5.1

5.2

PS Streaming

5.4

5.5

5.6

CS speech 5.7

5.5

5.8

B4

B3

5.9

B1

B6

5.1’

5.3’

PS Streaming only communication

With PS I/B used for support

of end to end signalling

PS I/B x/y

B2

B5

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.

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 subscriber’s 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

PS call management



iRM Scheduling:

• Streaming RAB: Enabled (requested GBR committed)


• Signaling Interactive RAB of multi-service “Streaming +I/B”: Enabled (8 kbps rate committed)

8. STATE TRANSITIONING ENHANCEMENT

[USA Market]

The State Transitioning Enhancement feature introduced in release UA06.0 addresses the following enhancements related to state transitions:

• 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.

8.1. 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


isBOTriggerForRbAdaptationAllowed

RadioAccessService

RB Adaptation activation flag

isUeTxPowerOn4AAllowed RadioAccessService

Determines whether a UE internal measurement is to be used as an additional measurement on a 4A buffer occupancy traffic volume measurement report.

PS call management




dchUlBoTrafVolMeas MeasurementConfClass

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.

repMode dchUlBoTrafVolMeas

Traffic Volume Measurement Report Transfer Mode on the DCCH (AM/UM)

measQtyQty dchUlBoTrafVolMeas

Measurement type for a traffic volume measurement

measQtyAverageTime dchUlBoTrafVolMeas

Time interval to take an average or a variance on a traffic volume measurement

rcMeasPendingTriggerTime

dchUlBoTrafVolMeas

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.

ueTrafficVolumeInhibitTimer

RadioAccessService

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

ulRbRaTrafficMonitoring.ul4AParams

UlRbSetConf This SMO (structure) contains all the data required for UL RB rate adaption traffic monitoring.

ul4ATimeToTrigger ulRbRaTrafficMonitoring.ul4AParams

Time to trigger for UE traffic volume measurement (buffer occupancy 4A) in CELL DCH.

ul4AThreshold ulRbRaTrafficMonitoring.ul4AParams

Reporting threshold for UE traffic volume measurement (buffer occupancy 4A) in CELL DCH for RB Adaptation

ul4AMaxRateStep ulRbRaTrafficMonitoring.ul4AParams

Upon reception of a 4A measurement report, the RNC shall use this parameter to determine the maximum UL data rate to reconfigure to.

DlRbRaTrafficMonitoring.dchDlBoTrafVolMeas DlRbSetConf

boAverageTimeDlDch dchDlBoTrafVolMeas

The averaging period for the downlink buffer occupancy measurement in CELL DCH. A value of zero will disable averaging

boPendingTriggerTimeDlDch

dchDlBoTrafVolMeas

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

boThresholdDlDch dchDlBoTrafVolMeas

The threshold of the downlink buffer occupancy in CELL DCH to trigger a data rate increase. A value of zero disables the measurement

boTimeToTriggerDlDch dchDlBoTrafVolMeas

The period of time between the timing of event detection and the timing of triggering the downlink buffer occupancy measurement event

8.2. 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)

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


isOamCappingOfDataAllowd

RadioAccessService

Rate capping activation flag

dchRateCapping CacConfClass This parameter is a structure contains all the data attributes required for DCH Rate Capping

maxUlRateRabEstablishDchAndDch dchRateCapping Max UL rate during RAB establishment on DCH/DCH

maxDlRateRabEstablishDchAndDch dchRateCapping Max DL rate during RAB establishment on DCH/DCH

maxUlRateRabEstablishHsdpaAndDch dchRateCapping

Max UL rate during RAB establishment on HSDPA/DCH

maxUlRateTransitionToDchDlTriggerDchAndDch dchRateCapping

Max UL rate during state transition from Cell_FACH or XX_PCH to Cell_DCH with a downlink trigger onto DCH/DCH

maxUlRateTransitionToDchUlTriggerDchAndDch dchRateCapping

Max UL rate during state transition from Cell_FACH or XX_PCH to Cell_DCH with an uplink trigger onto DCH/DCH

maxDlRateTransitionToDchDlTriggerDchAndDch dchRateCapping

Max DL rate during state transition from Cell_FACH or XX_PCH to Cell_DCH with a downlink trigger onto DCH/DCH

maxDlRateTransitionToDchUlTriggerDchAndDch dchRateCapping

Max DL rate during state transition from Cell_FACH or XX_PCH to Cell_DCH with an uplink trigger onto DCH/DCH

maxUlRateTransitionToDchDlTriggerHsdpaAndDch dchRateCapping

Max UL rate during state transition from Cell_FACH or XX_PCH to Cell_DCH with a downlink trigger onto HSDPA/DCH

maxUlRateTransitionToDchUlTriggerHsdpaAndDch dchRateCapping

Max UL rate during state transition from Cell_FACH or XX_PCH to Cell_DCH with an uplink trigger onto HSDPA/DCH

maxDlRateHsdpaAndDchToDchAndDch dchRateCapping

DL rate during RB reconfiguration from HSDPA/DCH to DCH/DCH

maxUlRateHsdpaAndDchToDchAndDch dchRateCapping

Max UL rate during RB reconfiguration from HSDPA/DCH to DCH/DCH

maxUlRateHsdpaAndEdchToHsdpaAndDch dchRateCapping

Max UL rate during RB reconfiguration from HSDPA/E-DCH to HSDPA/DCH

maxDlRateHsdpaAndEdchToDchAndDch dchRateCapping

Max DL rate during RB reconfiguration from HSDPA/E-DCH to DCH/DCH

maxUlRateHsdpaAndEdchToDchAndDch dchRateCapping

Max UL rate during RB reconfiguration from HSDPA/E-DCH to DCH/DCH

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


isFachToDchEnhancementAllowed

RadioAccessService

Determines whether the enhanced handling of Cell Update and RB Reconfiguration Failure messages is supported during transition Cell FACH to Cell DCH

isSib11IntraFreqOneShotAllowed FDDCell

Determines whether a oneshot intra-frequency measurement is transmitted on SIB11

isIntraFreqOneShotDchAllowed

RadioAccessService

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.

intraFreqOneShotFilterCoefficient

MeasurementConfClass

Filter coefficient for a oneshot intra-frequency measurement for the case where the measurement control is sent in Cell DCH

softHoAddThresholdOneShot

RadioAccessService

Threshold for addition of a SHO leg from a UE Intra-Frequency measurement report following transition to Cell_DCH state

boHoldoffTimeInitialDlFachDch

MeasurementConfClass

This parameter defines a period in which the first DL buffer occupancy measurement is ignored following a Cell_FACH to Cell_DCH transition

8.4. 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

PS call management



drop call rate for this transition. The number of retransmissions and time interval between messages is configurable.

8.4.1 PARAMETERS


fachRetransmissions RadioAccessService

This parameter is a structure contains all the data attributes required for FACH Retransmissions.

reconfigRetriesFachDch fachRetransmissions

Maximum number of reconfiguration message retries to transmit for Cell FACH to Cell DCH transition

reconfigTimeFachDch fachRetransmissions

Timer for retransmission of reconfiguration messages in Cell FACH for Cell_FACH to Cell_DCH transition

reconfigRetriesFachPch fachRetransmissions

Maximum number of retransmissions of Radio Bearer Reconfiguration message due to response message timeout to transition a UE from Cell FACH to xx_PCH state.

reconfigTimeFachPch fachRetransmissions

Timer for response of Radio Bearer reconfiguration complete for Cell_FACH to xx_PCH transition

9. 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


isRncRabModificationAllowed

PsCoreNetworkAccess

RNC initiated RAB modification activation flag

PS call management




uE6AOffsetFromMax UlRncRabModMeas

Threshold for a 6A UE internal measurement configured for the UE when a PS radio bearer is present.

uE6AtxPowerFilter UlRncRabModMeas Filter coefficient for UE 6A internal measurement.

dLtxCPFilter DlRncRabModMeas

Filter coefficient for the NBAP dedicated measurement.

minRateForRabModification

RadioAccessService

Parameter used when the RNC determines a target bit rate for RAB modification. Any bit rate corresponding to a guaranteed bit rate lower than this rate in the direction of modification will not be considered.

uLTxcpMaxBitRate RadioAccessService

Parameter indicated the maximum UL guaranteed bit rate to which a RNC can accept to downgrade a streaming PS RAB when a 6A measurement event is received.

TimeToTrigger6A FullEventHOConfHhoMgtEvent6A

Period during which the condition of the event 6A must be satisfied before sending a measurement report.

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

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

PS Call Management

Documents

Transcript of PS Call Management