packet scheduler

7/30/2019 Packet Scheduler

http://slidepdf.com/reader/full/packet-scheduler 1/181

Nokia Siemens Networks

WCDMA RAN, Rel. RU20,

Operating Documentation,Issue 02

WCDMA RAN RRM Packet Scheduler

DN0495772

Issue 14CApproval Date 2010-03-19



2 DN0495772

Issue 14C


Id:0900d805807455be

The information in this document is subject to change without notice and describes only the

product defined in the introduction of this documentation. This documentation is intended for the

use of Nokia Siemens Networks customers only for the purposes of the agreement under whichthe document is submitted, and no part of it may be used, reproduced, modified or transmitted

in any form or means without the prior written permission of Nokia Siemens Networks. The

documentation has been prepared to be used by professional and properly trained personnel,

and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes

customer comments as part of the process of continuous development and improvement of the

documentation.

The information or statements given in this documentation concerning the suitability, capacity,

or performance of the mentioned hardware or software products are given "as is" and all liability

arising in connection with such hardware or software products shall be defined conclusively and

finally in a separate agreement between Nokia Siemens Networks and the customer. However,

Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions

contained in the document are adequate and free of material errors and omissions. Nokia

Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which

may not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO

EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTA-

TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-

RECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED

TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY

OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION

IN IT.

This documentation and the product it describes are considered protected by copyrights and

other intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark

of Nokia Corporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respectiveowners, and they are mentioned for identification purposes only.

Copyright © Nokia Siemens Networks 2010. All rights reserved

f Important Notice on Product SafetyElevated voltages are inevitably present at specific points in this electrical equipment.

Some of the parts may also have elevated operating temperatures.

Non-observance of these conditions and the safety instructions can result in personal

injury or in property damage.

Therefore, only trained and qualified personnel may install and maintain the system.

The system complies with the standard EN 60950 / IEC 60950. All equipment connected

has to comply with the applicable safety standards.

The same text in German:

Wichtiger Hinweis zur Produktsicherheit

In elektrischen Anlagen stehen zwangsläufig bestimmte Teile der Geräte unter Span-

nung. Einige Teile können auch eine hohe Betriebstemperatur aufweisen.

Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Körperverlet-

zungen und Sachschäden führen.

Deshalb wird vorausgesetzt, dass nur geschultes und qualifiziertes Personal die

Anlagen installiert und wartet.

Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Angeschlossene

Geräte müssen die zutreffenden Sicherheitsbestimmungen erfüllen.



DN0495772

Issue 14C

3


Id:0900d805807455be

Table of ContentsThis document has 181 pages.

Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1 Introduction to the packet scheduler functionality . . . . . . . . . . . . . . . . . 12

1.1 Overview of the packet scheduler functionality . . . . . . . . . . . . . . . . . . . 12

1.2 Packet scheduler working environment. . . . . . . . . . . . . . . . . . . . . . . . . 13

1.3 Features related to the packet scheduler functionality. . . . . . . . . . . . . . 15

1.3.1 Selective NRT DCH data rate set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.3.2 Enhanced priority based scheduling and overload control for NRT traffic.

15

1.3.3 Throughput-based optimisation of the packet scheduler algorithm . . . . 16

1.3.4 Flexible upgrade of NRT DCH data rate . . . . . . . . . . . . . . . . . . . . . . . . 17

1.3.5 HSDPA (high speed downlink packet access). . . . . . . . . . . . . . . . . . . . 171.3.6 HSUPA (high speed uplink packet access) . . . . . . . . . . . . . . . . . . . . . . 17

1.3.7 QoS aware HSPA scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.3.8 Streaming QoS for HSPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.3.9 PS NRT RAB reconfiguration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.3.10 Support for I-HSPA Sharing and Iur Mobility Enhancements . . . . . . . . 18

1.3.11 CS voice over HSPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2 Radio resource management functions . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 Packet data transfer states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Procedures for packet data handling . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1 State transition from CELL_FACH state to CELL_DCH state . . . . . . . . 25

4.2 State transition from CELL_DCH state to CELL_FACH state . . . . . . . . 27

4.3 Packet data transmission on CELL_FACH state. . . . . . . . . . . . . . . . . . 29

4.4 Transport format combination control procedure. . . . . . . . . . . . . . . . . . 30

4.5 Downgrading of the non-real time dedicated channel bit rate . . . . . . . . 32

4.6 Upgrading of the non-real time dedicated channel bit rate . . . . . . . . . . 35

5 Packet scheduling principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6 UE-specific part of the packet scheduler . . . . . . . . . . . . . . . . . . . . . . . . 40

6.1 Traffic volume measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.2 UE radio access capability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.3 Final bit rate selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.4 Transport format combination set construction . . . . . . . . . . . . . . . . . . . 50

6.5 Radio link and transmission resources . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.6 Throughput-based optimisation of the packet scheduler algorithm . . . . 55

6.6.1 Throughput measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.6.2 Throughput-based optimisation of the NRT DCH data rate. . . . . . . . . . 63

6.7 Flexible upgrade of the NRT DCH data rate . . . . . . . . . . . . . . . . . . . . . 66

6.8 High throughput measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.9 DCH bit rate balancing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

7 Cell-specific part of the packet scheduler . . . . . . . . . . . . . . . . . . . . . . . 76

7.1 Cell- and radio link-specific load status information. . . . . . . . . . . . . . . . 76



4 DN0495772

Issue 14C


Id:0900d805807455be

7.2 Target load level of the cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

7.3 Queuing of capacity requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7.4 Channel type selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7.5 Power budget for packet scheduling. . . . . . . . . . . . . . . . . . . . . . . . . . . . 917.6 Bit rate allocation method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

7.7 Estimation of power change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

7.7.1 Uplink power estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

7.7.2 Downlink power estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

7.8 Output information to load control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

7.9 Response to UE-specific packet scheduler . . . . . . . . . . . . . . . . . . . . . 114

7.10 Load control actions for PS radio bearers. . . . . . . . . . . . . . . . . . . . . . . 115

7.11 Enhanced priority based scheduling. . . . . . . . . . . . . . . . . . . . . . . . . . . 125

8 UE- and cell-specific parts of the packet scheduler . . . . . . . . . . . . . . . 135

8.1 RT-over-RT and RT-over-NRT functionality . . . . . . . . . . . . . . . . . . . . . 135

8.2 PS streaming over NRT functionality . . . . . . . . . . . . . . . . . . . . . . . . . . 136

8.3 Dynamic link optimisation for non-real time traffic coverage. . . . . . . . . 137

8.3.1 Dynamic link optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

8.3.2 Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

8.3.3 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

8.3.4 Enhanced dynamic link optimisation for non-real time traffic coverage 144

8.4 Reduction of NRT signalling load with NRT DCH maximum bit rate modifi-

cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

8.5 PS NRT RAB reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

9 Features per release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

10 Management data for packet scheduler . . . . . . . . . . . . . . . . . . . . . . . . 152

10.1 Alarms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

10.2 Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

10.2.1 RAN1.029: Packet scheduler algorithm . . . . . . . . . . . . . . . . . . . . . . . . 153

10.2.2 RAN2.0084: Packet scheduler interruption timer . . . . . . . . . . . . . . . . . 168

10.2.3 RAN395: Enhanced priority based scheduling and overload control for

NRT traffic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

10.2.4 RAN409: Throughput-based optimisation of the packet scheduler algo-

rithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

10.2.5 Counters for quality of service (QoS) management . . . . . . . . . . . . . . . 170

10.3 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17010.3.1 RAN866: Dynamic link optimisation for NRT traffic coverage. . . . . . . . 170

10.3.2 RAN242: Flexible upgrade of NRT DCH data rate . . . . . . . . . . . . . . . . 171

10.3.3 RAN1.029: Packet scheduler algorithm . . . . . . . . . . . . . . . . . . . . . . . . 172

10.3.4 RAN395: Enhanced priority based scheduling and overload control for

NRT traffic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

10.3.5 RAN409: Throughput-based optimisation of the packet scheduler algo-

rithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

10.3.6 Parameters for quality of service (QoS) management . . . . . . . . . . . . . 178

10.3.7 Common measurements over Iub. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

10.3.8 RAN973: HSUPA Basic RRM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

10.3.9 RAN1759: Support for I-HSPA Sharing and Iur Mobility Enhancements . .179



DN0495772

Issue 14C

5


Id:0900d805807455be

10.3.10 DCH bit rate balancing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181



6 DN0495772

Issue 14C


Id:0900d805807455be

List of FiguresFigure 1 Capacity division between non-controllable and controllable traffic . . . . 13

Figure 2 Logical working environment of the packet scheduler . . . . . . . . . . . . . . 14

Figure 3 UMTS packet data user plane protocol stacks (the application is HTTP)21

Figure 4 Simplified model of UMTS packet data user plane protocol stack . . . . . 22

Figure 5 RRC states and state transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Figure 6 State transition from CELL_FACH state to CELL_DCH state. . . . . . . . . 27

Figure 7 State transition from CELL_DCH state to CELL_FACH state. . . . . . . . . 29

Figure 8 Downlink packet data transmission on FACH. . . . . . . . . . . . . . . . . . . . . 30

Figure 9 Uplink transport format combination control procedure . . . . . . . . . . . . . 31

Figure 10 Downlink transport format combination control. . . . . . . . . . . . . . . . . . . . 32

Figure 11 Downlink Radio Bearer Reconfiguration. . . . . . . . . . . . . . . . . . . . . . . . . 34

Figure 12 Upgrade of DL NRT DCH data rate when allocated bit rate is below the

maximum allowed bit rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Figure 13 Allocation example - DCH allocations due to downlink user data. . . . . . 38

Figure 14 Allocation example - multiple bearers in uplink and downlink. . . . . . . . . 38

Figure 15 Division of the packet scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Figure 16 Reattempt of NRT DCH allocation with decreased bit rate. . . . . . . . . . . 46

Figure 17 Example of TFCS construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Figure 18 TFS subsets for TFCS construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Figure 19 Initiation of a bit rate downgrade and channel release based on throughput

measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Figure 20 Throughput measurement of NRT DCHs . . . . . . . . . . . . . . . . . . . . . . . . 59

Figure 21 NRT DCH throughput measurement and usage indication by the MAC-d

entity of the RNC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Figure 22 Throughput-based optimisation of the packet scheduler algorithm . . . . 65

Figure 23 Triggering of traffic volume measurement in downlink when bit rate depen-

dent high threshold is exceeded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Figure 24 Example 1: Flexible upgrade of the NRT DCH data rate in downlink. . . 71

Figure 25 States of bearer allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Figure 26 Event-triggered report when transport channel traffic volume exceeds a

threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Figure 27 Pending time after trigger limits the amount of consecutive measurement

reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Figure 28 Channel type selection on MAC-c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Figure 29 Thresholds and margins in downlink channel type selection . . . . . . . . . 89Figure 30 Load distribution in a WCDMA cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Figure 31 Total received interference power of a cell . . . . . . . . . . . . . . . . . . . . . . . 92

Figure 32 Allowed power for uplink packet scheduling . . . . . . . . . . . . . . . . . . . . . . 92

Figure 33 Averaged received wideband interference power in uplink. . . . . . . . . . . 92

Figure 34 Example of inactive NRT, one NRT RB . . . . . . . . . . . . . . . . . . . . . . . . . 93

Figure 35 Total transmitted power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Figure 36 Allowed power for downlink packet scheduling. . . . . . . . . . . . . . . . . . . . 95

Figure 37 Averaged transmitted carrier power in downlink . . . . . . . . . . . . . . . . . . . 95

Figure 38 RL(U): Power estimation due to establishment or upgrade of a DL NRT

DCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Figure 39 RL(D): Power estimation due to release or downgrade of a downlink NRTDCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96



DN0495772

Issue 14C

7


Id:0900d805807455be

Figure 40 RL(RN): Power estimation at an early stage of the establishment or up-

grade of a DL NRT DCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Figure 41 RL(RT): Power estimation at an early stage of the establishment or up-

grade of a DL RT DCH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Figure 42 RL(RI): Power estimation due to the inactivity indication received for a DL

NRT DCH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Figure 43 Example of bit rate allocation method . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Figure 44 Throughput and interference targets for UL DCH scheduling . . . . . . . . 99

Figure 45 Packet scheduler bit rate allocation algorithm in DL . . . . . . . . . . . . . . 100

Figure 46 Packet scheduler bit rate allocation algorithm in UL . . . . . . . . . . . . . . 101

Figure 47 Load increase algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Figure 48 Uplink condition for the estimated new load . . . . . . . . . . . . . . . . . . . . 102

Figure 49 Downlink condition for the estimated new load. Symbols Lallowed_maxDCH,

Lallowed_minDCH, Prx_allowed and Ptx_allowed refer to the capacity conditions of

the chapter Power budget for packet scheduling. . . . . . . . . . . . . . . . . 103

Figure 50 Estimation of total received power after allocation. . . . . . . . . . . . . . . . 103

Figure 51 Example of load increase algorithm, 1 capacity request in queue. . . . 103

Figure 52 Example of load increase algorithm, 2 capacity requests in queue. . . 103




Figure 56 Priority scheduling algorithm in marginal load area . . . . . . . . . . . . . . . 105

Figure 57 Load factor change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Figure 58 Sum of the uplink DCH load factor changes . . . . . . . . . . . . . . . . . . . . 108

Figure 59 Uplink power increase estimation (PIE). . . . . . . . . . . . . . . . . . . . . . . . 108

Figure 60 Uplink power decrease estimation (PDE) . . . . . . . . . . . . . . . . . . . . . . 108Figure 61 Downlink power change estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Figure 62 Initial power estimation at radio link setup . . . . . . . . . . . . . . . . . . . . . . 109

Figure 63 Estimated total controllable power. . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Figure 64 Estimated uplink interference power of the allocated streaming users (Prx-

Streaming) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Figure 65 Estimated downlink interference power of the allocated streaming users

(PtxStreaming) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Figure 66 Thresholds of the UL DCH overload control . . . . . . . . . . . . . . . . . . . . 115

Figure 67 Load decrease algorithm for UL NRT DCHs . . . . . . . . . . . . . . . . . . . . 117

Figure 68 Example of load decrease algorithm, DCH modification . . . . . . . . . . . 118

Figure 69 Example of load decrease algorithm, DCH modification and release . 118Figure 70 Load decrease algorithm for DL NRT DCHs . . . . . . . . . . . . . . . . . . . . 119

Figure 71 Enhanced overload control for the DL NRT DCH radio bearer, OCdlNrtD-

CHgrantedMinAllocT and LoadControlPeriodPS interactions . . . . . . . 122

Figure 72 Enhanced overload decrease algorithm . . . . . . . . . . . . . . . . . . . . . . . 123

Figure 73 Example of enhanced over load decrease algorithm, physical channel re-

lease and reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Figure 74 Example of PBS functionality in uplink interference congestion . . . . . 126

Figure 75 The principle of dynamic link optimisation . . . . . . . . . . . . . . . . . . . . . . 137

Figure 76 Decision algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Figure 77 Example of triggering of dynamic link optimisation . . . . . . . . . . . . . . . 143

Figure 78 Modification of the maximum temporary bit rate of a BTS. . . . . . . . . . 148



8 DN0495772

Issue 14C


Id:0900d805807455be

List of TablesTable 1 Uplink traffic volume measurement reports . . . . . . . . . . . . . . . . . . . . . . 40

Table 2 Downlink traffic volume measurement reports . . . . . . . . . . . . . . . . . . . . 42

Table 3 Transport channel parameters in downlink . . . . . . . . . . . . . . . . . . . . . . 47

Table 4 Transport channel parameters in uplink . . . . . . . . . . . . . . . . . . . . . . . . . 47

Table 5 FDD Physical channel parameters in downlink . . . . . . . . . . . . . . . . . . . 47

Table 6 FDD Physical channel parameters in uplink . . . . . . . . . . . . . . . . . . . . . 47

Table 7 Constant TTI values for allowed dedicated channel bit rates . . . . . . . . 49

Table 8 Example of TFCS representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Table 9 Usage of throughput-based optimisation of the PS algorithm . . . . . . . . 57

Table 10 Lower and upper downgrade target bit rates for the NRT DCH. . . . . . . 63

Table 11 RABs bit rate for HSDPA UL DCH return channel before and after DCH bit

rate balancing activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Table 12 RABs bit rate for HSDPA UL DCH return channel before and after DCH bitrate balancing activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Table 13 RABs bit rate for DL DCH / UL DCH before and after DCH bit rate balancing

activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74


activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Table 15 Cell-based load information parameters . . . . . . . . . . . . . . . . . . . . . . . . 77

Table 16 Radio link based information parameters . . . . . . . . . . . . . . . . . . . . . . . 79

Table 17 Radio network planning parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Table 18 Handling capacity requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Table 19 Rules for channel type selection in the CELL_FACH state, uplink . . . . 87

Table 20 Rules for channel type selection in the CELL_FACH state, downlink . . 90Table 21 Variables for allowed power for uplink packet scheduling . . . . . . . . . . . 92

Table 22 Variables for allowed power for downlink packet scheduling . . . . . . . . . 95

Table 23 Variables for load factor change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Table 24 Variables for power estimation at radio link reconfiguration . . . . . . . . 110

Table 25 Parameters for non-real time traffic load information . . . . . . . . . . . . . . 112

Table 26 Parameters for estimated total transmitted controllable power . . . . . . 112

Table 27 Parameters for estimated interference power of the allocated streaming

users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Table 28 Capacity allocation in priority based scheduling . . . . . . . . . . . . . . . . . 130

Table 29 Iur-users and own-users prioritisation in the DRNC . . . . . . . . . . . . . . . 134

Table 30 The PRFILE parameter defines an additional offset (Hysteresis) to preventimmediate upgrade if the radio link (DL DCH bit rate) has been downgrad-

ed due to dynamic link optimisation in the cell. . . . . . . . . . . . . . . . . . . 142

Table 31 Cell resource measurements for the packet scheduling algorithm . . . 153

Table 32 Traffic measurements for the packet scheduling mechanism . . . . . . . 154

Table 33 Counters for packet scheduler interruption timer . . . . . . . . . . . . . . . . . 168

Table 34 Cell resource measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Table 35 L3 signalling at Iub measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Table 36 Counters for throughput-based optimisation of the packet scheduler

algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Table 37 RAN866: Dynamic link optimisation for NRT traffic coverage . . . . . . . 170

Table 38 RAN242: Flexible upgrade of NRT DCH data rate . . . . . . . . . . . . . . . 171Table 39 RAN242: Flexible upgrade of NRT DCH data rate . . . . . . . . . . . . . . . 172



DN0495772

Issue 14C

9


Id:0900d805807455be

Table 40 RAN1.029: Packet scheduler algorithm . . . . . . . . . . . . . . . . . . . . . . . 172

Table 41 RAN395: Enhanced priority based scheduling and overload control for

NRT traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Table 42 RAN409: Throughput-based optimisation of the packet scheduler

algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Table 43 Common measurements over Iub . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Table 44 RAN973: HSUPA Basic RRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Table 45 RAN1759: Support for I-HSPA Sharing and Iur Mobility Enhancements .

179

Table 46 DCH bit rate balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181



10 DN0495772

Issue 14C


Id:0900d805807455be



DN0495772

Issue 14C

11

WCDMA RAN RRM Packet Scheduler Summary of changes

Id:0900d8058071bf17

Summary of changesChanges between document issues are cumulative. Therefore, the latest document

issue contains all changes made to previous issues.

Note that the issue numbering system is changing. For more information, see Guide to

WCDMA RAN operating documentation.

Changes between issues 14B and 14C

The variable Hysteresis has been introduced in section Dedicated channel bit rate

upgrade in Dynamic link optimisation for non-real time traffic coverage.

Changes between issues 14A and 14B

Information on supported multi-services has been updated in section Packet scheduling

principles.

Section DCH bit rate balancing has been added.

Information on the supported total DCH user bit rate of all DCHs for one UE has been

updated in section Bit rate allocation method.

Changes between issues 14-0 and 14A

Sections Load control actions for PS radio bearers and Enhanced priority based sched-

uling have been updated according to changes in feature RAN1759: Support for I-HSPA

Sharing and Iur Mobility Enhancements.

Changes between issues 13-4 and 14-0

Section Features related to the packet scheduler functionality :

• Section CS voice over HSPA added.Section Power budget for packet scheduling :

• Equation on minimum and maximum available uplink load Lallowed _ minDCH in the

uplink DCH scheduling updated.

Section Bit rate allocation method :

• Equation Throughput and interference targets for UL DCH scheduling upated.

• Equation Estimation of total received power after allocation updated.

Section Load control actions for PS radio bearers:

• Equation Thresholds of the UL DCH overload control updated.

Section Enhanced priority based scheduling :• Information on traditional traditional Priority Based Scheduling (PBS for DCHs) func-

tionality added.

http://guide_to_wcdma_operating_doc.pdf/






12 DN0495772

Issue 14C


Id:0900d8058074cfa9

Introduction to the packet scheduler functionality

1 Introduction to the packet scheduler func-

tionality

The packet scheduler takes care of scheduling radio resources for non-real time and PSstreaming radio bearers in both the uplink and the downlink directions. Packet access is

implemented for dedicated (DCH) as well as common control transport channels

(RACH/FACH). Additionally, packet access is implemented for high speed downlink

shared channel (HS-DSCH) when using the HSDPA and for enhanced dedicated

channel (E-DCH) in the case of HSUPA. For more information on HSDPA packet

access, see Section Description of WCDMA RAN radio resource management of

HSDPA in WCDMA RAN RRM HSDPA and on HSUPA packet access see Section

Architecture of Radio Resource Management of HSUPA in WCDMA RAN RRM HSUPA.

1.1 Overview of the packet scheduler functionality

The radio access network (RAN) supports both real-time (RT) and non-real time (NRT)

radio access bearer (RAB) services. The proportion between real-time and non-real

time traffic varies all the time as shown in the Figure 1 Capacity division between non-

controllable and controllable traffic. It is characteristic of real-time traffic that the load

caused by it cannot be controlled in an efficient way. Load caused by real-time traffic

(excluding PS streaming), interference from other cell users and noise are together

called non-controllable load.

The part of the available capacity that is not used for non-controllable load can be used

for PS streaming and non-real time radio bearers on best effort basis. The load caused

by best effort non-real time traffic is called controllable load. The load caused by PS

streaming traffic is called semi-controllable load. The packet scheduler can control thesemi-controllable load and controllable load. Therefore, the controllable power includes

semi-controllable power in the figure below. However, the semi-controllable load can be

only released in overload situation because downgrading from guaranteed bit rate is not

possible. In overload situations, needed power is taken first from the controllable part

and after that from the semi-controllable part. In order to fill the whole load budget and

achieve the maximum capacity the algorithm responsible for allocating non-real time

traffic needs to be fast.

http://general_glossary.pdf/


http://wran_fad_rrm_hsdpa.pdf/



http://wran_fad_rrm_hsupa.pdf/













DN0495772

Issue 14C

13

WCDMA RAN RRM Packet Scheduler Introduction to the packet scheduler functionality

Id:0900d8058074cfa9

Figure 1 Capacity division between non-controllable and controllable traffic

The packet scheduler and the medium access control (MAC) layer together make the

decision regarding which type of channel to use in the downlink direction. With regard

to the uplink direction, the UE decides which type of channel to use, on the basis of

parameters controlled by the network. The channel type selection is fast and takes into

account the amount of data in the buffer and the current radio conditions. Uplink data

transmission on dedicated channel is initiated when UE sends a capacity request. In thedownlink it is the MAC layer that requests transmission capacity. Packet scheduling is

performed immediately if there are no queuing capacity requests, in other case it is done

periodically. The amount of scheduled capacity depends on:

• the UE and BTS capabilities

• the properties of the radio access bearer

• the current RNP parameter settings

• the availability of the capacity in RAN.

1.2 Packet scheduler working environment

The packet scheduler is located in the interface control and signalling unit (ICSU) of theserving radio network controller (SRNC). In the drift RNC, non-real time bearers are

handled as real-time bearers, and therefore are not taken into account in packet sched-

uling. Figure 2 Logical working environment of the packet scheduler shows the logical

working environment of the packet scheduler.

power

time

non-controllable load

controllable load

PrxNc / PtxNc

PrxTotal / PtxTotal

PrxNrt / PtxNrt

PrxTarget / PtxTargetPrxOffset / PtxOffset













14 DN0495772

Issue 14C


Id:0900d8058074cfa9


Figure 2 Logical working environment of the packet scheduler

AC Admission control

BTS Base transceiver station

HC Handover control

LC Load control

MAC Medium access control

NBAP Node B application protocol

PS Packet scheduler RLC Radio link control

RM Resource manager

RRC Radio resource control

TRM Transport resource manager

UE User equipment

The functions in figure Figure 2 Logical working environment of the packet scheduler are

presented from the point of view of the packet scheduler, and so all relations between

the functions are not shown. The packet scheduler (PS) co-operates with other radio

resource management functions like handover control (HC), load control (LC), admis-

sion control (AC) and the resource manager (RM). HC provides active set information,

LC provides periodical load information to PS on cell basis and PS informs AC and LC

of the load caused by PS radio bearers. AC informs PS when new PS radio bearers are

admitted, reconfigured or released. RM allocates the RNC internal resources, downlink

spreading codes and takes care of allocating radio links using the base station applica-

tion protocol (NBAP). RM also takes care of transport resource reservation for PS

streaming and NRT radio bearers using transport resource manager (TRM) services.

RM actions are done when requested by the PS. The radio resource control (RRC)

protocol takes care of L3 signalling between RNC and UE. L3 RRC signalling needed

by PS includes uplink capacity requests and channel allocation procedures in both

directions (uplink and downlink). The medium access control (MAC) protocol produces

radio bearer-specific downlink capacity requests to PS according to the radio link control

UE

RRM

RNC

BTSTRM

HC

RM

RRC

AC

PS

RLC-U

MAC

Radio Iub

NBAP

LC











DN0495772

Issue 14C

15


Id:0900d8058074cfa9

(RLC) buffer levels in the RNC. MAC also sends activity and inactivity indications on RB

basis.

Based on the cell-specific load information from load control (LC), uplink capacity

requests from the user equipment (UE) through the RRC-protocol and downlink capacityrequests from the MAC-layer of the RNC, the PS produces an appropriate transport

format combination set (TFCS) for the MAC-layer. The uplink and downlink transport

format combination set is delivered to MAC of the RNC, MAC of the UE and the BTS.

Uplink parameters are signalled to the UE through the RRC-protocol, which delivers the

parameters to the MAC-layer of the UE.

1.3 Features related to the packet scheduler functionality

1.3.1 Selective NRT DCH data rate set

The Selective NRT DCH data rate set feature enables the operator to limit the availableUL and DL DCH data rates for PS interactive and background RABs from the general

set introduced in section Supported bearer combinations and data rates in WCDMA

RAN RRM Admission Control. This selective or limited DCH data rate set contains only

rates 0, 8, 64 and 128 kbits/s in UL direction and 0, 8, 64, 128 and 384 kbits/s in DL

direction. The data rates listed in the set are the maximum data rates that can be allo-

cated for a DCH. When admission control and packet scheduler are defining the

maximum data rate for a DCH, they select it from the selective NRT DCH data rate set.

Limited bit rate set for PS NRT DCHs is taken in use with the Bit rate set for PS NRT

DCHs (BitRateSetPSNRT) RNC management parameter.

With the Maximum uplink bit rate for PS domain NRT data (MaxBitRateULPSNRT) man-

agement parameter, the operator can define the maximum allowed uplink DCH user bit

rate in a cell for the PS domain interactive and background RABs. Similarly, the downlink

DCH user bit rate of the NRT RABs can be controlled in a cell with the Maximum

downlink bit rate for PS domain NRT data (MaxBitRateDLPSNRT) management param-

eter.

If the selective NRT DCH data rate set is used together with the cell-specific NRT data

rate limiting parameters, a particular maximum DCH data rate can be used in a cell if

both of the features allow it.

Neither the selective NRT DCH data rate set nor the cell-specific NRT data rate limiting

parameters has an effect on the DCH data rate selection in the following situations:

• when the resource request is received from Iur in DRNC• in the target RNC of the SRNS relocation when the UE is not involved.

Cell-Specific data rate limitations are not significant in SRNC when the resource is allo-

cated for diversity handover.

1.3.2 Enhanced priority based scheduling and overload control for NRT

traffic

The Enhanced Priority Based Scheduling feature allows the operator to select alterna-

tive methods for the packet scheduling. These alternative methods, which can be

enabled by RNC configuration parameters, are based on the radio bearer reconfigura-

tion procedures.



http://wran_fad_rrm_admission_control.pdf/






16 DN0495772

Issue 14C


Id:0900d8058074cfa9


With the standard functionality of the packet scheduling algorithm, traffic handling

priority can be taken into account when allocating dedicated resources for NRT traffic

within one scheduling period, which is configured by the operator. A DCH allocation for

NRT is released when the RLC buffer is empty and the inactivity timer expires. Because

of the bursty nature of NRT traffic with most common applications (for example

web/WAP browsing), the allocations for NRT users are typically very short. However, in

some cases the large data amount or nature of application (for example FTP) allocation

times can be relatively long. The enhanced priority based scheduling algorithm by using

radio bearer reconfiguration procedures brings more powerful differentiation capabilities

to the operator’s network. Better QoS by enhanced bit rate allocation algorithm and

priority handling is achieved. Existing NRT allocations can be downgraded or released

if there are ‘higher’/’higher or equal’/’any’ priority users requesting capacity in the con-

gested situation.

Congestion of the following resources can trigger the enhanced priority based schedul-

ing function:

• downlink power

• uplink interference

• downlink spreading code

• BTS HW (WSP)

• Iub AAL2 transmission

Prioritisation of radio bearers is based on the QoS priority that is read from the QoSPri-

orityMapping RNP parameter with help of RAB QoS parameters such as traffic class,

traffic handling priority, and allocation and retention priority.

For more information on enhanced priority based scheduling, see Section Enhanced

priority based scheduling.

1.3.3 Throughput-based optimisation of the packet scheduler algorithm

The throughput-based optimisation of the packet scheduler algorithm enables the

operator to control the lowly used PS DCH that is allocated for the RAB of the non-real

time or PS streaming traffic. Non-real time traffic is interactive or background traffic class

that is connected to the PS domain.

In a mobile communication system, the application server can be located behind the IP

network. A bottleneck in the IP network causes low throughput and poor usage of the

radio, transport, and HW resources. Incomplete usage occurs also, for example, when

laptops keep sending small packets in the background or an e-mail application is offline.

In these cases, it is better to downgrade or release those NRT DCHs for capacityreasons.

The throughput-based optimisation adapts the DCH resource reservation to meet the

actual usage, that is, the used bit rate of the DCH. This is done by downgrading or

releasing the NRT DCH.

The usage is determined by specific throughput measurements: release throughput

measurement, lower throughput measurement, and upper throughput measurement.

These measurements indicate to the packet scheduler if the usage is below a specific

threshold but is not totally silent. The packet scheduler then initiates the release or

downgrade of the NRT DCH according to the principles defined by the throughput opti-

misation algorithm.



DN0495772

Issue 14C

17


Id:0900d8058074cfa9

The throughput-based optimisation of the packet scheduler algorithm reduces signifi-

cantly the capacity loss (mainly BTS HW, transmission and downlink spreading code

capacity loss), which is caused by too high bit rate allocation in the network.

For information on the basic principle of throughput-based optimisation, see SectionThroughput-based optimisation of the packet scheduler algorithm.

1.3.4 Flexible upgrade of NRT DCH data rate

The Flexible Upgrade of the NRT DCH Data Rate feature provides the means for

upgrading the NRT DCH bit rate from any bit rate up to the maximum bit rate of the radio

bearer when certain predetermined conditions are met.

When the NRT DCH bit rate is upgraded, the packet scheduler uses the averaged

downlink radio link power to estimate the power increase instead of using only the last

received measurement result, which is used otherwise when estimating power increase.

This is done to avoid a ping-pong effect when the downlink radio link power varies a lot.

The usage of the feature is controlled with the Usage of the flexible upgrade of the NRT

DCH data rate (FlexUpgrUsage) RNW configuration parameter. The feature can be acti-

vated by setting the parameter value to ‘On’.

The feature is activated also for the uplink NRT DCH HSDPA return channel if both

DynUsageHSDPAReturnChannel and FlexUpgrUsage RNP parameters are set to ‘On’.

For more information on flexible upgrade of NRT DCH data rate, see Section Flexible

upgrade of NRT DCH data rate.

1.3.5 HSDPA (high speed downlink packet access)

For information on HSDPA, see Section Description of WCDMA RAN radio resourcemanagement of HSDPA in WCDMA RAN RRM HSDPA.

1.3.6 HSUPA (high speed uplink packet access)

For information on HSUPA, see Section Architecture of Radio Resource Management

of HSUPA in WCDMA RAN RRM HSUPA.

1.3.7 QoS aware HSPA scheduling

This feature introduces QoS based prioritisation for PS NRT services according to the

QoSPriorityMapping RNP parameter. Based on operator-defined rules, PS NRT

services are handled according to their prioritisation value. The QoS prioritisation mech-

anism is used by all functions that need to prioritise PS RABs.

1.3.8 Streaming QoS for HSPA

This feature introduces QoS based prioritisation for PS streaming services according to

the QoSPriorityMapping RNP parameter. Based on operator-defined rules, PS stream-

ing services are handled according to their prioritisation value. Load caused by PS

streaming services is specified as semi-controllable load in this context, because it is

handled similar to controllable load but cannot be controlled as freely as NRT load.











18 DN0495772

Issue 14C


Id:0900d8058074cfa9


1.3.9 PS NRT RAB reconfiguration

With the PS NRT RAB reconfiguration feature, the SGSN or the UE can request to

modify the characteristics of a RAB service by using the RAB reconfiguration procedure.

In the RAN, the core network triggers the reconfiguration of an existing RAB with aRANAP: RAB ASSIGNMENT REQUEST message. The following QoS parameters can

be changed for interactive and background traffic class RABs:

• Traffic Class (TC) interactive or background

• Maximum Bit Rate (MBR) for UL and DL

• Traffic Handling Priority (THP) of an interactive RAB

• Allocation and Retention Priority (ARP)

For more information on the PS NRT RAB reconfiguration mechanism, see Section PS

NRT RAB reconfiguration.

1.3.10 Support for I-HSPA Sharing and Iur Mobility EnhancementsSupport for I-HSPA Sharing and Iur Mobility Enhancements feature supports I-HSPA

Sharing solution in the RNC and introduces enhancements to the DRNC and SRNC

anchoring functionality. I-HSPA Sharing shares NodeB resources between WCDMA

services and I-HSPA services.

The I-HSPA Sharing solution is introduced in RNC to support the IHSW-513: I-BTS

Sharing feature in the I-HSPA. The I-HSPA Sharing solution makes it possible to install

the I-HSPA Adapter card to an existing BTS and route the HSPA traffic directly from core

network to the BTS. With the I-HSPA Sharing solution in the RNC, the I-HSPA Adapter

supports circuit-switched (CS) services for all the users within the I-HSPA cell. Iur

Mobility Enhancements solution introduces enhancements to the existing DRNC and

anchoring functionality in RNC. The I-HSPA Sharing solution supports all services with

the following functional split: the RNC supports CS and CS+PS multiRAB services, while

the I-HSPA Adapter supports PS Rel99 and HSPA services. The feature shares auto-

matically all resources of the BTS.

I-HSPA Sharing feature switches the serving RNC functionality between the RNC and

I-HSPA Adapter based on the services. Iu-CS services are supported in the RNC. When

a user makes a CS call within the I-HSPA Adapter, I-HSPA Adapter triggers a relocation

request to the RNC with which it has an Iur connection by sending a relocation request

to the CN. The RNC reserves the radio resources of the I-HSPA Adapter during reloca-

tion over Iur interface. After relocation is completed the call continues in SRNC anchor-

ing mode. Then, the RNC is serving as the SRNC and the I-HSPA Adapter, which

triggered the relocation, as DRNC. The UE is still connected to the same I-HSPA cellafter relocation. When the CS call is released, relocation is triggered back to the I-HSPA

Adapter.

The I-HSPA Sharing feature enables full connected mode mobility between the RNC

and I-HSPA cells thus improving the end-user experience by avoiding hard handovers.

Both intra-frequency and inter-frequency handovers are supported over the Iur interface

between the RNC and I-HSPA Adapter.

Iur Mobility Enhancements introduces the following enhancements to the existing DRNC

and SRNC anchoring functionalities in an RNC:

1. The DRNC reports the GSM and/or GAN neighbour cells (in addition to the

intra/inter-frequency neighbour cells) to the SRNC over Iur whenever a radio link isestablished in the DRNC.



DN0495772

Issue 14C

19


Id:0900d8058074cfa9

2. The SRNC takes into use the GSM/GAN neighbour cells received from the DRNC

during inter-RAT handover procedures.

3. Support for inter-system handover to a GSM cell during SRNC anchoring.

4. No restriction on the NRT DCH bit rate during anchoring. All multi-RAB combinationsand bit rates supported in non-anchoring scenarios are supported during anchoring

scenarios as well.

5. Support of NRT DCH Scheduling over Iur allowing DCH bit rate modifications (bit

rate upgrade/downgrade) during anchoring.

6. Congestion Control in the DRNC: Priority Based Scheduling, Pre-emption, RT over

NRT, RT over RT, and overload control in the DRNC for DCH services during con-

gestion/overload situations.

7. Support for Power Balancing and Dynamic Link Optimisation during anchoring.

8. The SRNC supports Throughput based Optimisation during anchoring.

9. Support for Dynamic Link Optimisation of the DRNC radio links by the DRNC.

10. Support for Location Services during anchoring with I-BTS.11. Support for ISHO Cancellation during anchoring if ISHO Cancellation is enabled in

the SRNC.

12. Support of UTRAN-GAN handover during anchoring if handover to GAN is enabled

in SRNC.

With the above enhancements there is a very small difference between the end-user

service experience during SRNC anchoring and non-anchoring scenarios.

The DCH scheduling Over Iur is enabled in the SRNC when the Support for I-HSPA

Sharing and Iur Mobility Enhancement feature is enabled in the SRNC and the RNC

parameter DCHScheOverIur is set to 1.

The UE-specific RRM of the SRNC must read the license key value andDCHScheOverIur parameter to enable or disable the DCH Scheduling Over Iur in the

SRNC during anchoring . If the I-BTS Sharing license key is 'On' and the parameter

DCHScheOverIur is set to 1, the DCH Scheduling over Iur is enabled in the SRNC

during anchoring.

When the DCH Scheduling Over Iur is enabled, the following functionalities are sup-

ported in the SRNC during anchoring:

• Throughput based optimisation in the SRNC during anchoring.

• Support for bit rate allocation and modification for NRT DCH over Iur by the SRNC

during anchoring.

In the DRNC, DCH Scheduling Over Iur is considered enabled if the I-BTS Sharing

license key is 'On'. When the feature is enabled, the following packet scheduler function-

alities are supported:

• Dynamic link optimisation triggered for Iur Radio Links by a DRNC.

• Priority Based Scheduling, overload control, queuing of NRT capacity requests in

the DRNC.

1.3.11 CS voice over HSPA

CS Voice over HSPA uses HSPA transport channels to carry CS voice traffic. Mapping

the CS voice to HSPA takes place in RNC and is not visible to core network. Thus the

R99 or R4 CS core network can be used as today. Used together with the Continuous



20 DN0495772

Issue 14C


Id:0900d8058074cfa9


Packet Connectivity, feature gives gain in the air interface capacity and increases the

battery life of the UE.

This feature also introduces NRT-over-NRT functionality for HSPA, but, from the option-

ality point of view, it is a part of the QoS awaer HSPA scheduling feature.CS voice over HSPA is an optional feature and its use is controlled in cell level by the

operator.



DN0495772

Issue 14C

21

WCDMA RAN RRM Packet Scheduler Radio resource management functions

Id:0900d8058074d062

2 Radio resource management functionsRadio resource management (RRM) consists of a set of algorithms that ensure the

optimal usage of the WCDMA radio interface resources. Admission control (AC), load

control (LC), the packet scheduler (PS) and the resource manager (RM) are network-

based functions, which means that these algorithms deal with the radio resources of one

cell at the same time. Connection-based functions, power control (PC) and handover

control (HC), deal with the radio resources of one connection.

Admission control decides whether a request to establish a signalling link or a radio

bearer (RB) into the RAN can be granted or not. Admission control is used to maintain

stability and to achieve high capacity. The admission control algorithm is executed when

a radio bearer is set up or reconfigured.

Load control guards the system from overload situations, thereby making sure that it

remains stable. Handover control decides the active set for the UE. The active set is

defined as the set of cells participating in soft handover. Power control maintains radiolink quality by adjusting the transmission powers used in the uplink and downlink. The

overall goal is to meet the quality requirements using the lowest possible transmission

powers, thereby achieving low interference and high capacity in the radio access

network. The resource manager is responsible for managing the RNC internal

resources, downlink spreading codes, BTS resources, as well as requesting Iub and Iur

transport resources. The packet scheduler schedules radio resources for non-real time

and PS streaming radio bearers for both the uplink and the downlink directions.

Figure 3 UMTS packet data user plane protocol stacks (the application is HTTP) shows

the UMTS packet data user plane protocol stacks, which illustrate the travel of HTTP

packets in the network, between peer entities. HTTP is just one example of TCP/IP

applications.

Figure 3 UMTS packet data user plane protocol stacks (the application is HTTP)

From the RRM point of view, the situation is not as complicated as depicted in Figure3 UMTS packet data user plane protocol stacks (the application is HTTP). For RRM pur-

WCDMAL1

AAL2

ATM

PHY

FP

PDCP

MAC

RLC

FP

MCD

AAL2

ATM

PHY

GTP-U

UDP

IP

AAL5

ATM

PHY

WCDMAL1

PDCPRLC

MAC

TCP

HTTP

AAL5

ATM

PHY

IP

GTP-U

UDP

GTP

UDP

IP

PHY

L2

PHY

IP

GTP

UDP

PHY

L2

L2

IP IP

Routing

PHY

L2

IP

TCP

HTTP

UE BTS RNC SGSN GGSN Server

IP





















22 DN0495772

Issue 14C


Id:0900d8058074d062

Radio resource management functions

poses, we can consider the HTTP/TCP/IP stack as being outside the RNC. IP packets

arrive to the PDCP/RLC buffers of RNC in the downlink direction. Figure 4 Simplified

model of UMTS packet data user plane protocol stack illustrates the simplified UMTS

packet data user plane protocol stack model. The position of RRM is also indicated in

the figure; especially the packet scheduling function is close to WCDMA L2 protocols.

Figure 4 Simplified model of UMTS packet data user plane protocol stack

WCDMAL1

PDCP

RLC

MAC

TCP

HTTP

IP

UE

WCDMAL1

PDCP

RLC

MAC

TCP

HTTP

IP

RAN

RRM









DN0495772

Issue 14C

23

WCDMA RAN RRM Packet Scheduler Packet data transfer states

Id:0900d8058074d0ee

3 Packet data transfer statesThe description of packet data transfer states given here is based on the 3GPP RRC

protocol specification. Figure 5 RRC states and state transitions shows the supported

RRC states and state transitions. For more information, see Transitions between packet

data transfer states in WCDMA RAN Packet Data Transfer States, functional area

description.

The radio resource control (RRC) handles the control plane signalling of layer 3 between

the UEs and RAN. RRC allows a dialog between the RAN and the UE and also between

the core network and the UE. An RRC connection is a logical connection between the

UE and the RAN used by two peer entities to support the upper layer exchange of infor-

mation flows. There can only be one RRC connection per UE. Several upper layer

entities use the same RRC connection.

Figure 5 RRC states and state transitions

When a signalling connection exists, there is an RRC connection and the UE is in

UTRAN connected mode. In UTRAN connected mode, the position of the UE is known

either on UTRAN registration area (URA) level or on the cell level. The UE leaves the

UTRAN connected mode and returns to idle mode when the RRC connection is released

or at RRC connection failure.

When the UE position is known on cell level, it is either in CELL_FACH, CELL_DCH or

CELL_PCH state. The RRC connection mobility is then handled by handover proce-

dures and cell updates.

CELL_DCH

The CELL_DCH state is characterised by the allocation of a dedicated transport channel

to the UE. The UE is transferred from idle mode to the CELL_DCH substate through the

setup of an RRC connection, or by establishing a dedicated channel (DCH) from the

CELL_FACH state. Transition from CELL_DCH state to idle mode is realised through

the release of the RRC connection. Transition from CELL_DCH substate to

CELL_FACH substate is performed when the last active NRT DCH is released and the

RT RABs do not exist.

UTRAN Connected Mode

Establish RCCConnection

Release RRCConnection

Release RRCConnection

CELL_PCH

CELL_DCH

Idle Mode

URA_PCH

CELL_FACH


http://wran_fad_packet_data_trsf_states.pdf/
















24 DN0495772

Issue 14C


Id:0900d8058074d0ee

Packet data transfer states

CELL_DCH state is also applicable to the High speed downlink shared channel (HS-

DSCH) when using the HSDPA and to the Enhanced dedicated channel (E-DCH) in the

case of HSUPA. For more information on HSDPA packet access, see Description of

WCDMA RAN radio resource management of HSDPA in "WCDMA RAN RRM HSDPA

and on HSUPA packet access, see Architecture of Radio Resource Management of

HSUPA in "WCDMA RAN RRM HSUPA".

CELL_FACH

In the CELL_FACH substate the UE monitors a forward access channel (FACH). In this

state, the UE can transmit uplink control signals and can transmit small data packets on

the random access channel (RACH). A transition from CELL_FACH to CELL_DCH state

occurs, when a dedicated transport channel or MAC-d flow in the case of high speed

downlink shared channel is established through explicit signalling. While in the

CELL_FACH substate, the UE monitors the FACH continuously and therefore it should

be moved to the CELL_PCH substate when the data service has been inactive for a

while, as defined by the elapse of an inactivity timer. When the timer expires, the UE istransferred to the CELL_PCH state to decrease UE power consumption. Also, when the

UE is moved from the CELL_PCH state to the CELL_FACH state to perform a cell

update procedure or from URA_PCH state to CELL_FACH state to perform URA update

procedure, the UE state is changed back to CELL_PCH or URA_PCH state if neither the

UE nor the network has any data to transmit after the procedure has been performed.

When the RRC connection is released, the UE is moved to idle mode.

CELL_PCH

In the CELL_PCH substate the UE listens to the PCH transport channel. The dedicated

control channel (DCCH) logical channel cannot be used in this substate. If the network

wants to initiate any activity, it needs to make a paging request on the PCCH logical

channel in the known cell to initiate any downlink activity. The UE initiates a cell update

procedure when it selects a new cell. The only overhead in keeping a UE in the PCH

substate is the potential possibility of cell updating, when the UE moves to other cells.

To reduce this overhead, the UE is moved to the URA_PCH state when low activity is

observed. This can be controlled with an inactivity timer, and optionally, with a counter

that counts the number of cell updates. When the number of cell updates has exceeded

certain limits, the UE changes to the URA_PCH state. The UE is transferred from

CELL_PCH to CELL_FACH state either by a packet paging command from RAN or

through any uplink access.

URA_PCH

In the URA_PCH state the location of the UE is known on the UTRAN registration area(URA) level. A URA consists of a pre-defined set of cells. In this state, the UE mobility

is handled by means of URA update procedures. The UE listens to the PCH transport

channel while in this state. It is not possible to use the DCCH logical channel in this state;

if the network wants to initiate any activity, it needs to make a paging request on the

paging control channel (PCCH) logical channel within the URA where the UE is located.

Any activity causes the UE to be transferred to the CELL_FACH state, where uplink

access is performed on the RACH.















DN0495772

Issue 14C

25

WCDMA RAN RRM Packet Scheduler Procedures for packet data handling

Id:0900d8058074d119

4 Procedures for packet data handlingThe packet access procedure in WCDMA keeps the interference caused to other users

as small as possible. Since there is no connection between the base station and the user

equipment before the access procedure, initial access is not closed loop power con-

trolled and thus the information transmitted during this period should be kept at

minimum.

There are three scenarios for WCDMA packet access:

• infrequent transmission of short packets

• frequent transmission of short packets

• transmission of long packets

Packet data transfer in WCDMA can be performed using common or dedicated transport

channels.

Packet data transfer on common transport channelsSince the establishment of a dedicated transport channel itself requires signalling and

thus consumes radio resources, it may be better to transmit small non-real time user

data packets on common transport channels without closed loop power control. In this

case, the random access channel (RACH) in uplink and the forward access channel

(FACH) in downlink are the transport channels used for packet access. When the packet

data is performed on common channels, the UE is in CELL_FACH state.

Packet data transfer on dedicated transport channels

Long and frequent user data blocks are transmitted using dedicated transport channels

(DCH). When the packet data is performed on dedicated channels, the UE is in

CELL_DCH state.

4.1 State transition from CELL_FACH state to CELL_DCH

state

The UE connection can be moved from common channel (CELL_FACH state) to dedi-

cated channel (CELL_DCH state) if the RNC has data waiting to be transmitted in the

downlink direction or if the UE requests dedicated uplink capacity. The transition occurs,

when a dedicated transport channel is established via explicit signalling. The figure

below is an example of the message flow that takes place when the UE is switched from

a common to a dedicated channel. This particular transition only occurs if

1. there are no dedicated resources allocated for UE2. there is one non-real time radio bearer that requests uplink and downlink capacity.

In the uplink direction the need for capacity is detected by the MAC of the UE. The UE

makes the decision regarding which type of channel (common or dedicated) it uses in

the uplink direction. The UE requests dedicated capacity by sending an RRC: MEA-

SUREMENT REPORT message on the random access channel (RACH) to the RRC

signalling entity of the RNC, which forwards the message (UL_capacity_request) to

radio resource management.

In the downlink direction, the capacity need is detected by the UE-specific MAC-d entity

of the RNC. It sends a downlink capacity request (DL_capacity request) directly to radio

resource management.









26 DN0495772

Issue 14C


Id:0900d8058074d119

Procedures for packet data handling

Switching can be triggered by NRT RABs or PS streaming RABs. Once uplink and

downlink packet scheduling has been carried out, the packet scheduler requests

resources from the resource manager. The resource manager provides the required

RNC internal resources and downlink spreading code(s). It also orders the NBAP-layer

of the RNC to execute a radio link setup procedure and the transport resource manager

(TRM) to execute AAL2 transmission setup over the Iub interface. After the NBAP-layer

and the transport resource manager have indicated to the resource manager that the

procedures have been successfully executed, the resource manager sends an acknowl-

edgment to the packet scheduler.

The packet scheduler requests the RRC signalling entity of RNC to start the radio bearer

reconfiguration procedure. The RRC signalling entity sends an RRC: RADIO BEARER

RECONFIGURATION message to the UE on the forward access channel (FACH),

which is acknowledged with an RRC: RADIO BEARER RECONFIGURATION

COMPLETE message on a dedicated channel (DCH) after synchronisation and L2 con-

figuration. After the procedure, the UE is in CELL_DCH state and data transmission on

dedicated channel can begin.

CELL_DCH state is also applicable to the High speed downlink shared channel (HS-

DSCH) when using the HSDPA and to the Enhanced dedicated channel (E-DCH) when

using the HSUPA. For more information on HSDPA packet access, see Description of

WCDMA RAN radio resource management of HSDPA in "WCDMA RAN RRM HSDPA"

and on HSUPA packet access, see Architecture of Radio Resource Management of

HSUPA in "WCDMA RAN RRM HSUPA".











DN0495772

Issue 14C

27


Id:0900d8058074d119

Figure 6 State transition from CELL_FACH state to CELL_DCH state

4.2 State transition from CELL_DCH state to CELL_FACH

state

The UE connection is moved from dedicated (CELL_DCH state) to common channel(s)

(CELL_FACH state) when the last DCH is released and also signalling radio bearers are

silent. An NRT DCH can be released because of:

BTS RNC-NBAP RNC-RRC RNC-RRMUE

IubUu

RNC-L2

[RACH] RRC: MEASUREMENT REPORT

NBAP: RADIORESOURCE INDICATION

UL_capacity_req

Capacity_allocation

NBAP: SYNCHRONIZATION INDICATION

BTS providesperiodical cell

load informationto RRM

RRC of UErequests

uplink capacityfrom RRM

Traffic volumemeasurement

triggers

UE has data tosend in uplink

RNC has data tosend in downlink

MAC requestsdownlinkcapacity

from RRM

DL_capacity_req

Channeltype selection

-> DCH

RR_ind

Radio link setup (NBAP) and AAL2 transmission setup

PS informs UE aboutthe granted capacity

UL & DLpacket scheduling

RLC-PDU transportation on DCH

[FACH] RRC: RADIO BEARER RECONFIGURATION

[DCH] RRC: RADIO BEARER RECONFIGURATION COMPLETE

Sync_ind

L2 configuration

L1:SYNC

UE in CELL_DCH state

NRT RB establishment for UE

UE in CELL_FACH state



28 DN0495772

Issue 14C


Id:0900d8058074d119


• expiration of the inactivity timer

• lowly used NRT DCH (release throughput measurement)

• pre-emption or RT over NRT procedure

• priority based scheduling• overload control

As with all state transitions, the transition takes place through explicit signalling. The

inactivity timers can be set independently for the uplink and downlink for each bit rate;

the RNC configuration parameters in question are Inactivity timer for uplink DCH (Inac-

tivityTimerUplinkDCH)and Inactivity timer for downlink DCH (InactivityTimerDown-

linkDCH) (bit rate-specific parameters are grouped under these two parameters). The

figure State transition from CELL_DCH state to CELL_FACH state is an example for a

message flow associated with switching from a dedicated to a common channel

because of the expiration of an inactivity timer.

When the UE is in the CELL_DCH state, both uplink and downlink data streams are

monitored by the UE-specific MAC-d entity of the RNC. After it detects inactivity, it indi-cates this to the radio resource management algorithms and RRC signalling entity of the

RNC (Inactivity_indication). When the RRC signalling entity receives an inactivity indi-

cation, it defines and starts an inactivity timer.

When the inactivity timer expires, the RRC radio bearer reconfiguration procedure is

launched. RRC sends an RRC: RADIO BEARER RECONFIGURATION message to the

UE, which acknowledges it by sending the RRC: RADIO BEARER RECONFIGURA-

TION COMPLETE message to the RRC signalling entity of the RNC, which in turn starts

L2 reconfiguration and forwards the message (Capacity_release) to the packet sched-

uler. Radio link and AAL2 resources are then released and the UE is transferred to the

CELL_FACH state.

The Inactivity timer for uplink DCH (InactivityTimerUplinkDCH) and Inactivity timer for

downlink DCH (InactivityTimerDownlinkDCH) RNC configuration parameters can also

be set so that the dedicated channel is released immediately once the RRC signalling

entity receives an inactivity indication. Likewise, it is possible to configure these param-

eters so that the dedicated channel is not released at all, despite inactivity detection.

Note that transition from CELL_DCH state to CELL_FACH state is also applicable when

MAC-d flow is released in the case of high speed downlink shared channel. HSDPA

packet access is described in detail in Description of WCDMA RAN radio resource man-

agement of HSDPA in "WCDMA RAN RRM HSDPA" in this documentation set.

As well, transition from CELL_DCH state to CELL_FACH state is applicable when the

uplink E-DCH NRT MAC-d flow is released due to low throughput. For more information

on HSUPA packet access, see Architecture of Radio Resource Management of HSUPA

in "WCDMA RAN RRM HSUPA".









DN0495772

Issue 14C

29


Id:0900d8058074d119

Figure 7 State transition from CELL_DCH state to CELL_FACH state

4.3 Packet data transmission on CELL_FACH state

The UE makes the decision regarding which channel type (common or dedicated) to use

in the uplink direction. If the UE chooses to use the random access channel (RACH), the

user data is included in a random access burst. In the downlink it is the packet scheduler

that decides which channel type to use. If the forward access channel (FACH) is

selected, L2 is configured and data transmission on RACH can begin. This procedure is

illustrated in Figure 8 Downlink packet data transmission on FACH .


IubUu

RNC-L2

Capacity_release

All data is sent andRLC-U buffer is empty

Inactivity_ind

Radio link release (NBAP) and AAL2 transmission release

[DCH] RRC: RADIO BEARER RECONFIGURATION

L2 configuration




Inactivity_ind

Define inactivity timer

Inactivity timer expires

[RACH] RRC: RADIO BEARER RECONFIGURATIONCOMPLETE



30 DN0495772

Issue 14C


Id:0900d8058074d119


Figure 8 Downlink packet data transmission on FACH

4.4 Transport format combination control procedure

Uplink transport format combination control (TFCC) procedure below is an example of

the message flow that is used for the uplink transport format combination control proce-

dure; this procedure is carried out because of load reasons. When the packet scheduler

has detected an overload situation in the uplink and scheduled a subset of the original

transport format combination set (TFCS), it requests the RRC signalling entity of RNC

to initiate the transport format combination control procedure. The RRC signalling entity

sends an RRC: TRANSPORT FORMAT COMBINATION CONTROL message to the

UE on a dedicated channel. Once the procedure is completed, it is possible to resume

data transmission using the transport format combination subset. Once the overload sit-

uation is over, the system automatically reverts to the original transport format combina-

tion set using the same procedure.


IubUu

RNC-L2

UE has data tosend in downlink

MAC requestsdownlinkcapacity

from RRM

DL_capacity_req

Channeltype selection

->FACH

PS indicates L2 aboutthe granted capacity

on FACH

RLC-PDU transportation on FACH

L2 configuration

NRT RB establishment for UE






DN0495772

Issue 14C

31


Id:0900d8058074d119

Figure 9 Uplink transport format combination control procedure

The downlink transport format combination control below is an example of the message

flow that is used in downlink dedicated channel modification, which is done for load

reasons, when using TFC subset method. When the packet scheduler has detected an

overload situation in downlink and scheduled a subset of the original transport format

combination set, it reconfigures the L2 by sending the transport format combination

subset to the UE-specific MAC-d entity of the RNC. Once the procedure is completed,it is possible to resume data transmission using the transport format combination

subset. Once the overload situation is over, the system automatically reverts to the

original transport format combination set using the same procedure.


IubUu

RNC-L2

Capacity_modify

RLC-PDU transportation on modified DCH

[DCH] RRC: TRANSPORT FORMAT COMBINATION CONTROL



NBAP: RADIO RESOURCE INDICATION



RR_ind

RRM detectsoverload

situation inuplink

packet scheduling

PS indicates UEabout the modified

capacity andselected UL TFC

subset



32 DN0495772

Issue 14C


Id:0900d8058074d119


Figure 10 Downlink transport format combination control

4.5 Downgrading of the non-real time dedicated channel bit

rate

The dedicated channel of a non-real time radio access bearer can be downgraded or

released to free up capacity needed for one or more real-time or non-real time radioaccess bearers that are about to be allocated for the same RRC connection.

Because of the Dynamic link optimisation for non-real time traffic coverage feature the

bit rate of an existing non-real time dedicated channel can be downgraded in case the

downlink transmission power exceeds a predefined threshold. This is done to guarantee

coverage for the RRC connection in question. For more information on this feature, see

Section Dynamic link optimisation for non-real time traffic coverage.

Because of the feature enhanced priority based scheduling and overload control the bit

rate of an existing non real-time dedicated channel can be downgraded for releasing

capacity for queuing NRT capacity requests in different congestion situations. For more

information on this feature, see Section Enhanced priority based scheduling.


IubUu

RNC-L2




NBAP: RADIO RESOURCE INDICATION



RR_ind

RRM detectsoverload

situation indownlink

packet scheduling

PS indicates L2about the modified

capacity andselected DL TFC

subset

L2 reconfiguration



DN0495772

Issue 14C

33


Id:0900d8058074d119

The bit rate of a non-real time dedicated channel can also be downgraded because of

the feature throughput-based optimisation of the packet scheduler algorithm. The

throughput-based optimisation adapts the dedicated channel (DCH) resource reserva-

tion to meet the actual usage, that is, the used bit rate of the DCH. This is done by down-

grading or releasing the NRT DCH. The throughput-based optimisation is based on

throughput measurements performed by the MAC-d entity of the RNC. The release and

downgrade of NRT DCHs is performed by the UE-specific PS and cell-specific PS based

on the throughput measurement indications from the MAC-d entity of the RNC.

The bit rate of the DCH of the NRT RAB is limited in particular multi-service cases. Thus

the DCH of the NRT RAB can be downgraded or released also due to the following

reasons:

• If the RAB assignment request for the PS streaming data RAB is admitted.

If there is (are) NRT radio bearer(s) with scheduled DCH(s) other than one 8/8 kbps

DCH, out of the scheduled NRT DCHs, the DCH of the radio bearer (RB) with the

highest logical channel priority is downgraded to 8/8 kbps. The DCH(s) of the other NRT RBs are released, that is, configured to 0/0 kbps. Note that this restriction

applies to DCH/DCH users and is not valid for HSDPA users and HSUPA users.

• If the RAB assignment request for the CS conversational data RAB is admitted.

If there is (are) NRT radio bearer(s) with scheduled DCH(s) other than one 8/8 kbps

DCH, out of the scheduled NRT DCHs, the DCH of the RB with the highest logical

channel priority is downgraded to 8/8 kbps. The DCH(s) of the other NRT RBs are

released, that is, configured to 0/0 kbps.

• If the RAB assignment request for the CS AMR speech RAB is admitted.

If there is an NRT RB mapped to the HS-DSCH in downlink with a scheduled DCH

higher than 64 kbps in uplink, the uplink DCH of the RB is downgraded to 64 kbps.

For more information, see RAB combinations for HSDPAin "WCDMA RAN RRM

HSDPA".

Restriction to have just one simultaneous NRT service with 8/8 bit rate with PS stream-

ing mapped to DCH is used only if PS streaming service have bit rate other than 0 (DCH

0/0). If DCH 0/0 is used for PS streaming RAB, then bit rates of NRT are defined as if

there are not PS streaming RAB at all.

Figure 11 Downlink Radio Bearer Reconfiguration shows an example of the message

flow of the downlink dedicated channel modification, which is done for load reasons

using Radio Bearer Reconfiguration RRC procedure.

When the packet scheduler has detected the overload situation in downlink and modifies

DCH bit rate and spreading factor, it reconfigures the L2 by sending the new transport

format combination set to the UE specific MAC-d entity of the RNC. Once the RadioBearer Reconfiguration procedure is completed, it is possible to resume data transmis-

sion using the new transport format combination set.

The original bit rate of the DCH(s) is not automatically returned back to the DCH(s) once

the overload situation is over.





34 DN0495772

Issue 14C


Id:0900d8058074d119


Figure 11 Downlink Radio Bearer Reconfiguration

RAB modification can also cause dedicated channel modification. If the Maximum Bit

Rate, which is one of the RAB parameters, is downgraded below the current bit rate of

the DCH allocation, DCH bit rate is decreased to the value of Maximum Bit Rate.

RAB reconfiguration for interactive and background classes is supported when the

reconfiguration is initiated by the PS core network.

RNC-NBAPUE BTS RNC-RRC RNC-L2 RNC-RRM



Uu Iub

BTS providesperiodicalcell load

informationto RRM

RR_ind

RRM detectsoverload

situation indownlink

Packetscheduling

PS indicatesUE, L2 and

AAL2 aboutmodified tran-sport channel

parameters

Capacity modify

Capacity modify

MODIFIED AAL2


NBAP: RADIO LINK

RECONFIGURATION PREPARE

NBAP: RADIO LINKRECONFIGURATION READY

RRC: RADIO BEARER RECONFIGURATION

NBAP: RADIO LINKRECONFIGURATION COMMIT

RRC: RADIO BEARER RECONFIGURATION COMPLETE

NBAP: RADIORESOURCE INDICATION



DN0495772

Issue 14C

35


Id:0900d8058074d119

4.6 Upgrading of the non-real time dedicated channel bit rate

The bit rate of the currently allocated dedicated channel can be upgraded in response

to downlink and uplink traffic volume measurements. The thresholds for these measure-

ments are defined by the Downlink traffic volume measurement high threshold (Traf-VolThresholdDLHigh) and Uplink traffic volume measurement high threshold

(TrafVolThresholdULHigh)parameters except when the bit rates are 8 kbps and 16 kbps

and the threshold is a fixed value (512 bytes) for both uplink and downlink directions..

Traffic volume measurements are described in Traffic volume measurements.

When the feature flexible upgrade of the NRT DCH data rate is activated (FlexUpgrUs-

age parameter is set ‘On’), the thresholds for these measurements are defined by the

TrafVolThresholdDLHighBitRate and TrafVolThresholdULHighBitRateRNC configura-

tion parameters (bit rate-specific parameters are grouped under these two parameters)

instead of TrafVolThresholdDLHigh and TrafVolThresholdULHigh.

It is possible to upgrade the NRT DCH bit rate from any bit rate up to the maximum

allowed bit rate as long as all the conditions related to upgrading are met.

When the upgrade of the NRT DCH bit rate is performed, packet scheduler uses the

average downlink radio link power in the estimation of the power increase instead of only

the last received measurement result. This is done to avoid a ping-pong effect as the

downlink radio link power varies a lot. For more information, see Estimation of power

change.

The dedicated channel upgrade can only be done if at least the initial bit rate has been

allocated to all queued capacity requests and there is spare capacity to schedule. The

dedicated channel upgrade procedure is performed in CELL_DCH state and it requires

the reconfiguration of radio link, transmission and RNC internal resources.

Figure 12 Upgrade of DL NRT DCH data rate when allocated bit rate is below themaximum allowed bit rate illustrates the upgrade of the DL NRT DCH data rate when

the allocated bit rate is below the maximum allowed bit rate.

Initial bit rate has been allocated as a response to the traffic volume measurement

report, that is, the uplink capacity request sent by the UE to the UE-specific PS of the

RNC. In this example the initial bit rate is 16 kbps, and therefore the reporting threshold

for the traffic volume measurement report is 512 bytes until the bit rate is upgraded.

When this threshold is exceeded, there is an attempt to upgrade the bit rate to the

maximum allowed bit rate defined by admission control; in this case 384 kbps. Conges-

tion occurs but 128 kbps can be allocated. The traffic volume measurement reporting

threshold 512 bytes is replaced with TrafVolThresholdDLHigh; in this example 1024

bytes. When this threshold is exceeded the MAC-d of the RNC sends an upgraderequest and there is an attempt to allocate the maximum bit rate. Now the allocation of

384 kbps succeeds and the traffic volume measurement is stopped.



36 DN0495772

Issue 14C


Id:0900d8058074d119


Figure 12 Upgrade of DL NRT DCH data rate when allocated bit rate is below the

maximum allowed bit rate

There is an attempt tomaximum data rate of NRT RAB (high data rate),congestion occurs but

upgrade to 128 kbpssucceeds. TVM is modified.

10 2 3 4 7 8 10 11 12 13 14 15

8

16

32

64

128

256

384

DL DCHdata rate

[kbps]

Time[RRind Period]

Reportedbuffer size

[bytes]

1024

512

8

Based on the UEmeasurement

report, initial datarate allocated

Upgrade to maximumdata rate of NRTRAB succeeds.TVM stopped.

Maximum data rateof the NRT RAB

UE sendsmeasurement

report

MAC-d of RNCsends DL capacity

requestRRind Period

Allocated data rateof the NRT RAB

MAC-d of RNCsends DL capacityrequest

5

InitialBitRate



DN0495772

Issue 14C

37

WCDMA RAN RRM Packet Scheduler Packet scheduling principles

Id:0900d8058074d123

5 Packet scheduling principlesPacket scheduling is done on cell basis. However, the packet scheduling processes for

different cells communicate due to the need for soft handover for packet data users on

dedicated channels.

Asymmetric packet traffic is supported and the load may vary a lot between the uplink

and the downlink. Because of this, capacity is allocated separately for the uplink and the

downlink, as illustrated in the figures Allocation example - DCH allocations due to

downlink user data and Allocation example - multiple bearers in uplink and downlink.

g The following DCH/DCH multi-services are supported:

• A maximum of three NRT (interactive/background) PS RABs

• AMR and a maximum of three NRT (interactive/background) PS RABs

• CS-T and a maximum of three NRT (interactive/background) PS RABs

• one RT PS (streaming) RAB and a maximum of three NRT (interactive/back-

ground) PS RABs

In the case of RT PS (streaming) RAB and CS-T RAB only one NRT DCH with 8/8

kbps is simultaneously allowed. If both UL and DL are using DCH, the total

maximum PS DCH data rate does not exceed 384 kbps.

The following PS HSDPA (DCH/HS-DSCH) multi-services are supported:

• AMR and one interactive/background PS RAB for HSDPA with 16, 64, 128, or

384 kbps UL DCH return channel

For more information, see WCDMA RAN RRM HSDPA.

• AMR, one RT (streaming) PS RAB for HSDPA, and a maximum of three NRT

(interactive/background) PS RABs for HSDPA with 16, 64, or 128 kbps UL DCH

return channel

In the UL return channel of HSDPA, the total maximum of PS DCH data rate with the

AMR service does not exceed 384 kbps.

Data rate in the HSDPA UL DCH return channel with AMR can be limited to 64 kbps

with the PRFILE (007:0285) parameter. The PRFILE parameter does not limit the

HSDPA UL DCH return channel to 64 kbps by default (see WCDMA RAN RRM

HSDPA).

For the information on supported PS HSPA (E-DCH/HS-DSCH) multi-services, see

WCDMA RAN RRM HSDPA.

When a dedicated channel (DCH) is allocated for one direction (be it uplink or downlink),

another dedicated channel is automatically set up for the opposite direction, even if thereis no user data to be sent. The packet scheduler allocates the initial bit rate for the ded-

icated channel in the 'idle' direction. The channel is needed for higher layer acknowl-

edgements (TCP acknowledgements), L2 acknowledgements, L2 control and power

control and is called 'return channel'. Examples of such allocations are shown in Alloca-

tion example, DCH allocations due to downlink user data and Allocation example,

multiple bearers in uplink and downlink . The Initial bit rate in uplink (InitialBitRateUL) and

Initial bit rate in downlink (InitialBitRateDL) RNC configuration parameters define the

initial bit rate.

The BitRateSetPSNRT RNC configuration parameter defines the used bit rate set and

the set also defines allowed bit rates. If the bit rate is not allowed, the next lower allowed

bit rate is used.

















38 DN0495772

Issue 14C


Id:0900d8058074d123

Packet scheduling principles

When using the HSDPA, that is, when RB is mapped to HS-DSCH in downlink, DCH is

scheduled or E-DCH is allocated as a return channel in uplink. Packet scheduling is not

applicable to the HS-DSCH MAC-d flow in downlink and E-DCH MAC-d flow in uplink.

For more information on HSDPA packet access, see Description of WCDMA RAN radio

resource management of HSDPA in "WCDMA RAN RRM HSDPA" and on HSUPA

packet access Architecture of Radio Resource Management of HSUPA in "WCDMA

RAN RRM HSUPA".

Figure 13 Allocation example - DCH allocations due to downlink user data

Figure 14 Allocation example - multiple bearers in uplink and downlink

Soft handover for packet data users on dedicated channels is supported in RAN. This

requires signalling between packet scheduling processes, since data has to be sched-

uled simultaneously for every cell of the active set (when the UE is in soft handover).

The load of each active set cell is known by the entity managing the soft handover.

CELL_FACH CELL_DCH CELL_FACH

Uplink DCH

Downlink DCH

Radio link & lub AAL2 setupNRT RB data transfer active

NRT RB inactivity timer running Radio link & lub AAL2 release

CELL_FACH CELL_DCH CELL_FACH

Uplink DCHs

Downlink DCHs

Radio link & lub AAL2 setup

NRT RB data transfer active

NRT RB inactivity timer running Radio link & lub AAL2 release

Radio link & lub AAL2 modification

RT RB









DN0495772

Issue 14C

39

WCDMA RAN RRM Packet Scheduler Packet scheduling principles

Id:0900d8058074d123

The packet scheduler consists of a UE-specific part and a cell-specific part, which are

explained in UE-specific part of packet scheduler and cell-specific part of packet sched-

uler respectively. Cell-specific part functionality is realized in DRNC if the RAN1759:

Support for I-HSPA Sharing and Iur Mobility Enhancements feature is enabled. Figure

15 Division of the packet scheduler illustrates how the packet scheduler is conceptually

divided into various entities.

Figure 15 Division of the packet scheduler

During soft handover, packet scheduling is done in every cell of the active set. The UE-

specific part of the packet scheduler is the controlling entity between the cell-specific

packet scheduling processes.

Packet scheduling prioritises RABs according to QoS parameters such as traffic class,

traffic handling priority, and allocation and retention priority. Furthermore, the configu-

rable RNP parameter QoSPriorityMapping is taken into account. For more information

see WCDMA RAN RRM HSDPA.

HC

PS cell #1

PS cell #2

PS cell #n

L2

MAC

Uplink TFCSDownlink TFCSDownlink spreading code

Uplink TFCSDownlink TFCS

Downlink capacity request

Uplink capacity request

Active set info

UEspecific

PS

L3 SignalingServices

RRCNBAP

Cells in the

active set

TFCS and downlinkspreading codenegotiation







40 DN0495772

Issue 14C


Id:0900d8058074c2f5

UE-specific part of the packet scheduler

6 UE-specific part of the packet scheduler

6.1 Traffic volume measurementsUplink traffic volume measurement reports

UE-specific part of the packet scheduler sets, modifies, and releases uplink traffic

volume measurements. It is also done during anchoring if DCH Scheduling over Iur is

enabled in the SRNC.

Uplink traffic volume measurement reports are included in RRC: MEASUREMENT

REPORT messages.

Traffic volume measurement reports from the UE are handled as uplink capacity

requests in the RNC. The actions that the RNC takes on the basis of these reports

depend on a number of factors:

The UE performs traffic volume measurements for each uplink non-real time radio

bearer when one of the following conditions is true:

• The UE is in CELL_FACH state.

• The UE is in CELL_DCH state but no dedicated channel is allocated for the non-real

time radio bearer in question.

• The UE is in CELL_DCH state and the allocated bit rate is lower than the maximum

bit rate for the radio bearer in question.

The UE performs traffic volume measurements for uplink PS streaming radio bearer

only if no dedicated channel is allocated to the streaming RB. This can happen for

example if inactivity detection for streaming RB is activated and the RB was released

due to inactivity. Inactivity detection for streaming RB is activated by the InactDetFor-StreamingRB RNP parameter. For more information see WCDMA RAN RRM HSDPA.

Current state Action taken by RNC

The UE is in CELL_FACH state and only RLC

buffers of NAS (SRB3 or SRB4) messages

carrying higher layer signalling has data to

send and sum load of RLC buffers of SRB3

and SRB4 exceed threshold defined by Uplink

NAS signalling volume threshold (NASsign-

VolThrUL) radio network planning parameter.

Request for state transition to CELL_DCH

state and signalling link only allocation.

The UE is in CELL_FACH state and any of the

user plane radio bearers has data to send.


state and dedicated channel allocation.

The UE is in CELL_DCH state and has zero bitrate dedicated channel. Request for dedicated channel allocation.

A low bit rate dedicated channel is allocated

and the RLC buffer load of the transport

channel in question has triggered a higher

threshold of transport channel traffic volume

measurement.

Dedicated channel bit rate upgrade request.

The UE is in CELL_FACH state and only

SRB0, SRB1 or SRB2 has data to send.

Capacity request is rejected. RRC messages

containing pure control signalling does not

cause state transition.

Table 1 Uplink traffic volume measurement reports

















DN0495772

Issue 14C

41

WCDMA RAN RRM Packet Scheduler UE-specific part of the packet scheduler

Id:0900d8058074c2f5

In the CELL_FACH state, the UE uses the random access channel (RACH) as an uplink

transport channel. When the UE is in CELL_FACH state, the transport channel traffic

volume measurement measures the total sum of buffer occupancies of radio bearers

multiplexed onto the RACH. The buffer levels of each RB is included in the measure-

ment report.

Corresponding to the three cases above, the UE sends traffic volume measurements as

follows:

1. When the total sum data amount of RLC transmission exceeds the lower threshold,

the UE sends a traffic volume measurement report including each 'RB identity' and

'RLC transmission buffer payload'. The lower threshold is defined by the Uplink

traffic volume measurement low threshold (TrafVolThresholdULLow) radio network

planning parameter, and is a traffic volume measurement reporting criterion.

2. When data of any amount arrives in the RLC transmission buffer, the UE sends a

traffic volume measurement report including 'RB identity' and 'RLC transmission

buffer payload'. The reporting threshold is set to 8 bytes.3. When the data amount in the RLC transmission buffer exceeds the higher threshold,

the UE sends a traffic volume measurement report including 'RB identity' and 'RLC

transmission buffer payload'. The higher threshold is defined by the Uplink traffic

volume measurement high threshold (TrafVolThresholdULHigh) radio network

planning parameter or with the Traffic volume threshold for uplink NRT DCH bit rates

(TrafVolThresholdULHighBitRate)RNP parameter when the FlexUpgrUsage

parameter is set 'On', and is a traffic volume measurement reporting criterion.

Bit rates of PS streaming RBs cannot be upgraded or downgraded. Thus the RB can be

only setup or released.

If the UE does not receive dedicated channel allocation nor bit rate upgrade (RRC mes-

sage), it resends the traffic volume measurement report to the network after a certaininterval known as the pending time after trigger . The Uplink traffic volume measurement

pending time after trigger (TrafVolPendingTimeUL) is one of the measurement reporting

criteria parameters and it is set by radio network planning.

The reporting criteria are signalled to the UE using an RRC: MEASUREMENT

CONTROL message when a radio bearer is set up or when parameters are modified.

The measurement is released using RRC: MEASUREMENT CONTROL message when

E-DCH is allocated for that RB.

When a bit rate higher than 16 kbps and lower than maximum allowed bit rate is allo-

cated for the radio bearer, the measurement procedure for that radio bearer is modified

so that Uplink traffic volume measurement high threshold (TrafVolThresholdULHigh) replaces Uplink traffic volume measurement low threshold (TrafVolThresholdULLow) as

a reporting threshold.

When a bit rate lower or equal to 16 kbps is allocated for the radio bearer, the measure-

ment procedure for that radio bearer is modified so that downlink traffic volume mea-

surement fixed threshold 512 bytes replaces Uplink traffic volume measurement low

threshold (TrafVolThresholdULLow) as a reporting threshold.

If FlexUpgrUsage is set ‘On’ and a bit rate lower than the maximum allowed bit rate is

allocated for the radio bearer, the measurement procedure for that radio bearer is

modified so that Traffic volume threshold for uplink NRT DCH bit rates (TrafVolThresh-

oldULHighBitRate) replaces Uplink traffic volume measurement low threshold (Traf-

VolThresholdULLow) as a reporting threshold.





42 DN0495772

Issue 14C


Id:0900d8058074c2f5


Downlink traffic volume measurement reports

Downlink traffic volume measurement reports are RNC internal messages.

Traffic volume measurement reports from the MAC-layer are handled as downlink

capacity requests in the RNC. The actions that the RNC takes on the basis of thesereports depend on a number of factors:

The MAC-layer performs traffic volume measurements for each downlink non-real time

radio bearer if one of the following condition is true:

• The UE is in CELL_FACH state.

• The UE is in CELL_DCH state but a dedicated channel is not allocated for the non-

real time radio bearer in question.

• The UE is in CELL_DCH state and the allocated bit rate is lower than the maximum

bit rate for the radio bearer in question.

For downlink PS streaming radio bearer, the MAC-layer performs traffic volume mea-

surements only if no DCH or HS-DSCH is allocated for the streaming RB. This canhappen for example if inactivity detection for streaming RB is activated and the RB was

released due to inactivity. Inactivity detection for streaming RB is activated by the Inact-

DetForStreamingRB RNP parameter. For more information see WCDMA RAN RRM

HSDPA.

In the CELL_FACH state, the UE has one downlink transport channel, the forward

access channel (FACH). When the UE is in CELL_FACH state, transport channel traffic

volume measurements of the RNC measures the sum of buffer occupancies of all user

plane radio bearers, SRB3 and SRB4 multiplexed onto a transport channel. The buffer

levels of each radio bearer is included in the measurement report.

Corresponding to the three cases above, the MAC layer sends traffic volume measure-

ments as follows:

Current state Action taken by RNC

The UE is in CELL_FACH state and only RLC

buffers of NAS (SRB3 or SRB4) messages

carrying higher layer signalling has data to

send and sum load of RLC buffers of SRB3

and SRB4 exceed threshold defined by

Downlink NAS signalling volume threshold

(NASsignVolThrDL) radio network planning

parameter.


state and signalling link only allocation.

The UE is in CELL_FACH state and any of the

user plane radio bearers has data to send.


state and dedicated channel allocation.

The UE is in CELL_DCH state and has zero bit

rate dedicated channel.

Request for dedicated channel allocation.

A low bit rate dedicated channel is allocated

and RLC buffer load of transport channel in

question has triggered higher threshold of

transport channel traffic volume measurement.

Request for non-real time dedicated channel

bit rate upgrade.

The UE is in CELL_FACH state and only

SRB0, SRB1 or SRB2 has data to send.

MAC does not send any capacity request.

RRC messages containing pure control signal-

ling does not cause state transition.

Table 2 Downlink traffic volume measurement reports









DN0495772

Issue 14C

43


Id:0900d8058074c2f5

1. When the total sum data amount of RLC transmission buffers of the user plane radio

bearers and signalling radio bearers SRB3 and SRB4 exceeds the lower threshold,

the cell-specific MAC-c entity sends a traffic volume measurement report including

'RB identity' and 'RLC transmission buffer payload'. The lower threshold is defined

by the Downlink traffic volume measurement low threshold (TrafVolThresholdDL-

Low) radio network planning parameter, and is a traffic volume measurement report-

ing criterion.

2. When data of any amount arrives to the RLC transmission buffer, the UE-specific

MAC-d entity sends a traffic volume measurement report including 'RB identity' and

'RLC transmission buffer payload'.

3. When the data amount in the RLC transmission buffer exceeds the higher threshold,

the UE-specific MAC-d entity sends a traffic volume measurement report including

'RB identity' and 'RLC transmission buffer payload'. The higher threshold is defined

by the Downlink traffic volume measurement high threshold (TrafVolThresholdDL-

High)radio network planning parameter or with the Traffic volume threshold for

downlink NRT DCH bit rates (TrafVolThresholdDLHighBitRate) RNP parameter

when the FlexUpgxrUsage parameter is set ‘On’, and there is a traffic volume mea-

surement reporting criterion.

Bit rates of PS streaming RBs cannot be upgraded or downgraded. Thus the RB is

released.

If the MAC-layer does not receive dedicated channel allocation or bit rate upgrade (RNC

internal message from L3 to MAC-layer), it resends the traffic volume measurement

report to the network after an interval known as 'pending time after trigger'. The Downlink

traffic volume measurement pending time after trigger (TrafVolPendingTimeDL) is one

of the measurement reporting criteria parameters and it is set by radio network planning.

The reporting criteria are sent from L3 to the MAC entities when the entity is initialisedor when the parameters are modified.

When a bit rate higher than 16 kbps and lower than a maximum allowed bit rate is allo-


so that Downlink traffic volume measurement high threshold (TrafVolThresholdDLHigh)

replaces Downlink traffic volume measurement low threshold (TrafVolThresholdDLLow)

as a reporting threshold.

When a bit rate lower or equal to 16 kbps is allocated for the radio bearer, the measure-

ment procedure for that radio bearer is modified so that downlink traffic volume mea-

surement fixed threshold 512 bytes replaces Downlink traffic volume measurement low

threshold (TrafVolThresholdDLLow) as a reporting threshold.

If FlexUpgrUsage is set ‘On’ and a bit rate lower than maximum allowed bit rate is allo-


so that Traffic volume threshold for downlink NRT DCH bit rates (TrafVolThresholdDL-

HighBitRate) replaces Downlink traffic volume measurement low threshold (Traf-

VolThresholdDLLow) as a reporting threshold.

UE-specific packet scheduler sends capacity request messages to cell-specific

packet scheduler

The UE-specific packet scheduler forwards uplink and downlink traffic volume measure-

ment reports, that is capacity requests, to the cell-specific packet scheduler for every cell

included in the active set. During anchoring the UE-specific packet scheduler forwards

uplink and downlink traffic volume measurement reports, that is capacity requests, to the



44 DN0495772

Issue 14C


Id:0900d8058074c2f5


cell-specific anchoring packet scheduler if DCH scheduling over Iur is enabled in the

SRNC. The requests fall into four categories:

1. Initial request for low bit rate when all of the following conditions are true:

• the non-real time radio bearer in question has no previous dedicated channelallocation

• the RLC buffer payload in the traffic volume measurement report is smaller than

Uplink traffic volume measurement high threshold (TrafVolThresholdULHigh) or

Downlink traffic volume measurement high threshold (TrafVolThresholdDL-

High), depending on whether the capacity was requested for uplink or downlink

respectively.

2. Initial request for high bit rate when all of the following conditions are true:

• the non-real time radio bearer in question has no previous dedicated channel

allocation

• the RLC buffer payload in the traffic volume measurement report is equal or

higher than Uplink traffic volume measurement high threshold (TrafVolThresh-oldULHigh) or Downlink traffic volume measurement high threshold (Traf-

VolThresholdDLHigh), depending on whether the capacity was requested for

uplink or downlink respectively.

3. Upgrade request for high bit rate when the following condition is true:

• the non-real time radio bearer in question has lower than radio bearer maximum

bit rate dedicated channel allocated.

The upgrade request for a high bit rate is rejected by the UE-specific PS in the event

of:

• the FlexUpgrUsage parameter is set to ‘On’, the high throughput measurement

is activated by the DCHutilHighAveWin RNP parameter and the MAC-d entity of

the RNC has not indicated that NRT DCH utilisation is high.• the high throughput measurement is not activated and the usage is not ‘normal’.

4. Initial request for guaranteed bit rate when the following condition is true:

• the PS streaming RB in question has no previous DCH allocation and traffic

volume measurement report is triggered.

The high bit rate requested in cases 2 and 3 above is defined by the maximum allocated

radio bearer bit rate derived by admission control. The uplink and downlink minimum

spreading factors for the dedicated physical channel are included in the capacity

requests; the minimum spreading factors are derived from the radio access capability of

the UE. The UE radio access capability parameters can also restrict the requested bit

rate.

If the SRNC is the anchoring RNC and the UE-specific packet scheduler receives uplink

or downlink traffic volume measurement reports, that is, capacity requests during

anchoring for NRT services, when any cell in the active set is not controled by the

SRNC, the capacity requests are deleted (not sent to the cell-specific packet scheduler).

In this scenario, the UE has only NRT RBs allocated and the RAN1759: Support for I-

HSPA Sharing and Iur Mobility Enhancements feature is disabled in the SRNC. If the

RAN1759: Support for I-HSPA Sharing and Iur Mobility Enhancements feature is

enabled, then these capacity requests is processed by the UE-specific packet scheduler

during anchoring. Capacity requests for PS streaming service (activation) are handled

normally during anchoring.

If UE-specific packet scheduler receives uplink or downlink traffic volume measurement

reports, that is capacity requests, when one or more cells in the active set is controled



DN0495772

Issue 14C

45


Id:0900d8058074c2f5

by the SRNC and the DRNC, and if capacity allocation fails due to the branch, that was

located in the DRNC by unspecified or any congestion reason, then the UE-specific

packet scheduler starts the capacity request rejection timer (time of the timer is fixed to

6s).

In the case of HSDPA, HS-DSCH transport channel can be chosen instead of dedicated

transport channel (DCH) due to UL or DL capacity request. For more information on

channel type selection algorithm between DCH and HS-DSCH, see Channel type

switching in WCDMA RAN RRM HSDPA.

When using the HSUPA, E-DCH transport channel can be chosen instead of dedicated

transport channel (DCH) due to UL or DL capacity request. For more information on

channel type selection algorithm between DCH and E-DCH, see HSUPA channel type

selection in WCDMA RAN RRM HSUPA.

UE-specific PS reattempts NRT DCH allocation with decreased bit rate when con-

gestion occurs

When the UE-specific packet scheduler receives requests for high bit rate allocations

but the DCH allocation or DCH upgrade with requested maximum radio bearer bit rate

is rejected because of the BTS, AAL2 transmission (Iub and Iur) or HW congestion, the

UE-specific packet scheduler downgrades the bit rate of the DCH allocation or upgrade

attempt with cell-specific packet schedulers from that bit rate to the next lower allowed

bit rate and repeats the DCH allocation or upgrade attempt procedure in the UE-specific

packet scheduler side (BTS, transmission, HW). This situation is illustrated in Figure

16 Reattempt of NRT DCH allocation with decreased bit rate.

The bit rate is downgraded only in the congested transmission direction. The counting

of the next lower allowed bit rate is started from the lowest bit rate that was given by the

cell-specific packet schedulers involved in the soft handover. If the congestion is still

faced, the bit rate of the DCH to be allocated or upgraded is downgraded similarly one

step more and the re-attempt is performed again. This procedure can be performed

several times if needed. The UE-specific packet scheduler does not, however, down-

grade the bit rate that is to be allocated in the DCH upgrade to or below the currently

used bit rate or in initial DCH allocation below the initial bit rate. The repeating procedure

is stopped and the maximum bit rate limitation is released when the DCH is allocated or

upgraded or the congestion is faced for the lowest possible bit rate. The cell-specific

packet scheduler accepts the downgrading request immediately without queuing in the

capacity request queue. The RRC RB reconfiguration procedure is performed finally

when the DCH allocation is successful or when the procedure ends.

The following retry procedure is followed in case of rejection of the capacity request by

the DRNC during anchoring:

1. Request for Initial Bitrate rejected.

If the request for Initial Bitrate was rejected by the DRNC with cause set as

"Requested Configuration not Supported", or ''Unspecified", or congestion related,

the SRNC does not perform a retry. It sends the capacity request only after receiving

a new capacity request from the UE or L2 layer.

2. Request for High Birate rejected.

If the request for High Bitrate was rejected by the DRNC with cause set as "Unspec-

ified", or "Requested Configuration not Supported", or congestion related cause, the

SRNC retries with initial bit rate immediately. If the request fails again, then no retry

is performed and the SRNC waits for the next UL/DL capacity request.











46 DN0495772

Issue 14C


Id:0900d8058074c2f5


3. Upgrade Request for High Bitrate rejected.

If the upgrade request for High Bitrate was rejected by the DRNC with cause set as

"Unspecified", or congestion related cause, the SRNC starts the capacity request

rejection timer and the value is fixed to 2 s.

If the capacity request is received and the capacity request rejection timer is running at

the same time, the capacity request shall be deleted.

The possible causes received from the DRNC are:

• "UL radio resources not available"

• "DL radio resources not available"

• "Radio network layer cause unspecified"

• "Transport resource unavailable"

• "Transport layer cause unspecified"

• "Control processing overload"

• "Hardware failure"• "Not enough user plane processing resources"

• "miscellaneous cause unspecified"

Figure 16 Reattempt of NRT DCH allocation with decreased bit rate

g In this example, the DCH bit rate is initially 0/0 kbps and the initial bit rate is 64 kbps.

384

256

128

64

Bit rate (kbps)

Time (s)

DCH allocationrejected

DCHallocated

CR TrafVolPending Time New capacity request



DN0495772

Issue 14C

47


Id:0900d805805dca27

6.2 UE radio access capability

The UE radio access capabilities that have an effect on packet scheduling are listed in

the tables below.

Transport channel parameters in downlink

Maximum sum of number of bits of all transport blocks being received at an arbitrary

time instant

Maximum sum of number of bits of all convolutionally coded transport blocks being

received at an arbitrary time instant

Maximum sum of number of bits of all turbo coded transport blocks being received at an

arbitrary time instant

Maximum number of simultaneous transport channels

Maximum total number of transport blocks received within TTIs that end within the same

10 ms intervalMaximum number of TFC

Table 3 Transport channel parameters in downlink

Transport channel parameters in uplink

Maximum sum of number of bits of all transport blocks being transmitted at an arbitrary

time instant

Maximum sum of number of bits of all convolutionally coded transport blocks being

transmitted at an arbitrary time instant

Maximum sum of number of bits of all turbo coded transport blocks being transmitted atan arbitrary time instant

Maximum number of simultaneous transport channels

Maximum total number of transport blocks transmitted within TTIs that start at the same

time

Maximum number of TFC

Table 4 Transport channel parameters in uplink

FDD Physical channel parameters in downlink

Maximum number of physical channel bits received in any 10 ms interval (dedicated

physical channel (DPCH), physical downlink shared channel (PDSCH), secondary

common control physical channel (SCCPCH))

Table 5 FDD Physical channel parameters in downlink

FDD Physical channel parameters in uplink

Maximum number of dedicated physical data channel (DPDCH) bits transmitted per 10

ms

Table 6 FDD Physical channel parameters in uplink





48 DN0495772

Issue 14C


Id:0900d805805dca27

The UE-specific packet scheduler checks the UE radio access capability parameters

before it sends capacity requests to the cell-specific packet scheduler. The UE radio

access capability parameters may for example, restrict the requested bit rate.



DN0495772

Issue 14C

49


Id:0900d805805dca2a

6.3 Final bit rate selection

A capacity request triggers a response from the cell-specific packet scheduler of each

cell in the active set. Each response includes a scheduled bit rate and downlink spread-

ing code.

During anchoring, the UE-specific packet scheduler receives the scheduled bit rate and

downlink spreading factor from the cell-specific anchoring packet scheduler in response

to the capacity request.

When the UE is in the CELL_DCH state and in soft handover, packet scheduling is done

by each cell-specific packet scheduler separately. Therefore, the responses (scheduled

bit rates) of the cell-specific packet schedulers can differ. The bit rate is set to match the

bit rate proposed for the most heavily loaded cell in the active set; in other words, the

lowest of all the scheduled bit rates. In case downlink spreading codes have to be real-

located in some cells in the active set, those are requested from the cell-specific packet

schedulers.

The RNC's internal constant values define the allowed non-real time dedicated channel

bit rates. The transmission time interval (TTI) of each allowed dedicated channel bit rate

is also an RNC internal constant value. This means that the operator cannot configure

the allowed bit rates and the corresponding transmission time intervals.

With the Bit rate set for PS NRT DCHs (BitRateSetPSNRT) RNC management param-

eter the operator can activate predefined set of bit rates for the PS NRT DCHs. The bit

rate in the set can be used if some other functionality does not restrict its use.

Bit rate (kbps) Uplink (ms) Downlink (ms)

8 40 40

16 40 40

32 20 20

64 20 20

128 10 20

256 10 10

384 10 10

Table 7 Constant TTI values for allowed dedicated channel bit rates









50 DN0495772

Issue 14C


Id:0900d80580750134

6.4 Transport format combination set construction

There are transport format sets (TFS) for each dedicated channel (DCH) allocated to the

UE. The UE-specific packet scheduler produces transport format set subsets based on

the scheduled bit rates provided by the cell-specific packet schedulers and selectedintermediate bit rates defined in Figure 18 TFS subsets for TFCS construction. On the

basis of these transport format subsets, the UE-specific packet scheduler produces a

transport format combination set (TFCS).

The uplink and downlink transport format sets and transport format combination sets

produced by the UE-specific packet scheduler are delivered to the MAC layer of the

RNC, the MAC layer of the UE and the BTS. The MAC selects the appropriate transport

format combination (TFC) to be used in L2 PDU transportation.

The following example depicts transport format combination set construction (TFCS) for

one signalling link (TrCh 1) and one non-real time radio bearer (TrCh 2). The transport

format combination set consists of transport format combinations, which are identified

with transport format indicators (TFI) for each corresponding transport channel (TrCH)

id and transport format combination indicator (TFCI). A transport format indicator is

assigned for each transport format in the transport format set constructed for a given

transport channel. The transport format combination includes one transport format from

each transport channel.

TFCI TFITrCH1 TFITrCH2

0 0 0

1 0 1

2 0 2

3 1 0

4 1 1

5 1 2

Table 8 Example of TFCS representation















DN0495772

Issue 14C

51


Id:0900d80580750134

Figure 17 Example of TFCS construction

On the signalling interfaces, the transport format combination sets are efficiently repre-

sented with the help of the so-called calculated transport format combination (CTFC)

concept. The calculated transport format combination value is derived from the format

for each combination. The calculated transport format combination concept is specified

in 3GPP RRC protocol specification.

Some intermediate rates should be selected for transport format set subsets of dedi-

cated channels allocated to non-real time radio bearers. This is done to decrease

padding on L2.

Transport format set subsets for transport format combination set construction are pre-

sented in the figures below. Transport format set subsets include certain selected inter-

mediate bit rates. The transmission time interval of the scheduled bit rate is an RNCinternal constant value.

256

128

64

32

16

8

0

Bit ratesfor NRT

Peak bit ratein bearer

parametersis requested

from PS

128

Scheduledbit rate

TFS for NRTDCH

TFS subsetfor TFCS

construction

TFCS (SL &NRT RB)

64

32

0

64

32

0 0

64

32

0

TFI2

TFI1

TFI0

TFI2

TFI1

TFI0

TFI1

TFI0

16

64

TFI1

TFI2

TFI0

TFCI5

TFCI2

TFCI4

TFCI1

TFCI3

TFCI0

TrCh1

TrCh2

384






52 DN0495772

Issue 14C


Id:0900d80580750134

Figure 18 TFS subsets for TFCS construction

The number of transport format combinations can be high. The maximum number of

transport format combinations that the RNC can handle is limited to 256. Thus effectiveTFC count capability is the minimum of TFC count capabilities supported by the UE and

the RNC. This limitation is done to avoid excessive signalling load.

Uplink and downlink transport format combination sets have to be signalled to the UE,

which means that the bigger the transport format combination set is, the more data there

is to be signalled. The UE capability parameters define the maximum number of trans-

port format combinations that UE can handle; the highest possible value is 1024.

When the number of transport format combinations has to be decreased, less interme-

diate bit rates for dedicated channels allocated to non-real time radio bearers are

selected. The number of intermediate bit rates is decreased by modifying the transport

format set subset so that only zero or one intermediate bit rate is included. For more

6432

-

-

00

8

16-

0

32-

-

0

128

6432

-

-

0

256128

6432

-

-

0

384256

128

6432

-

-

0

3216

-

0

16-

00

8

64

32

16

-

0

48

128

64

32

16

-

0

-

TFS subsets for TFCS constructionwhen TTI = 10 ms

TFS subsets for TFCS constructionwhen TTI = 20 ms

Scheduled bit rateTransport block sizeTransport block set size

8

961

161761

323361

64336

2

128336

4

256336

8

38433612


81761

163361

32336

2

64336

4

128336

8

TFS subsets for TFCS construction

when TTI = 40 ms


83361

16336

2

32336

4

0

8

168

0

3224

16

8

0



DN0495772

Issue 14C

53


Id:0900d80580750134

information on this functionality (TFS restriction class 2), see the UE radio access capa-

bility in transport channel configuration in WCDMA RAN RRM Admission Control.

Note that the following uplink non-real time dedicated channel bit rates are supported:

8, 16, 32, 64, 128, 256 and 384 kbps. The corresponding non-real time dedicatedchannel bit rates for the downlink are: 8, 16, 32, 64, 128, 256 and 384 kbps. When using

the HSDPA, the supported bit rates for the uplink return channel (DCH) are 16, 64, 128,

and 384 kbps. For more information on HSDPA UL return channel,see HSDPA mobility

handling with the Serving HS-DSCH Cell Change WCDMA RAN RRM HSDPA.











54 DN0495772

Issue 14C


Id:0900d805805dca30

6.5 Radio link and transmission resources

Whenever the maximum data rate of a DTCH mapped to a DCH is modified the AAL2

and BTS HW resources are reconfigured accordingly. However, TFCC procedure does

not modify the maximum data rate. It just restricts the use of certain transport formatcombinations.





DN0495772

Issue 14C

55


Id:0900d8058074c314

6.6 Throughput-based optimisation of the packet scheduler

algorithm

The throughput-based optimisation of the packet scheduler algorithm enables the

operator to control the lowly used PS DCH that is allocated for the RAB of the non-real

time traffic. Non-real time traffic is interactive or background traffic class that is con-

nected to the PS domain.

In a mobile communication system, the application server can be located behind the IP

network. A bottleneck in the IP network causes low throughput and poor usage of the

radio, transport, and HW resources. Incomplete usage occurs also, for example, when

laptops keep sending small packets in the background or an e-mail application is offline.

In these cases, it is better to downgrade or release those NRT DCHs for capacity

reasons.

The throughput-based optimisation adapts the DCH resource reservation to meet the

actual usage, that is, the used bit rate of the DCH. This is done by downgrading or

releasing the NRT DCH.

The throughput-based optimization of the packet scheduler algorithm is supported

during anchoring due to RAN1759: Support for I-HSPA Sharing and Iur Mobility

Enhancements feature if DCH scheduling over Iur is enabled. The principle is the same

as in non-anchoring scenario.

The usage is determined by specific throughput measurements: release throughput

measurement, lower throughput measurement, and upper throughput measurement.

These measurements indicate to the packet scheduler if the usage is below a specific

threshold but is not totally silent. The packet scheduler then initiates the release or

downgrade of the NRT DCH according to the principles defined by the throughput opti-

misation algorithm.The throughput-based optimisation of the packet scheduler algorithm reduces signifi-

cantly the capacity loss (mainly BTS HW, transmission and downlink spreading code

capacity loss), which is caused by too high bit rate allocation in the network.

The basic principle of throughput-based optimisation is shown in the following figure.

The average throughput is presented as a proportion of the maximum user bit rate of the

allocated DCH. The thresholds are calculated based on specific radio network planning

parameters as it is described in subsection 6.6.1 Throughput measurements.



56 DN0495772

Issue 14C


Id:0900d8058074c314

Figure 19 Initiation of a bit rate downgrade and channel release based on throughput

measurement

The throughput-based optimisation works in parallel with the inactivity timer. The NRT

DCH has to be totally silent during the inactivity period until it is released.

Both the inactivity timer and the throughput-based optimisation operate simultaneously

and independently from each other. The UE-specific PS reacts to the indication which

triggers first.

Inactivity supervision for PS streaming is used only if that functionality is activated with

the InactDetForStreamingRB RNP parameter. For more information see WCDMA RAN

RRM HSDPA. As bit rates of streaming RBs cannot be upgraded or downgraded, no

other throughput based measurements/functionalities are used for PS streaming RBs

mapped to DCH.

In practice, the release throughput measurement reacts first if the threshold bit rates for

uplink and downlink - defined with the DCHUtilRelThrUL and DCHUtilRelThrDL radio

network planning (RNP) parameters - are greater than 0 kbps. If the thresholds for uplink

and downlink are set to 0 kbps, the inactivity timer is used to indicate that the NRT DCH

has to be released because no data is transmitted on the DCH.

6.6.1 Throughput measurements

This section describes the throughput measurements related to the feature throughput-

based optimisation of the packet scheduler algorithm. For information on an additional

throughput measurement or on high throughput measurement, see Flexible upgrade of

the NRT DCH data rate.

The modification of an allocated NRT DCH bit rate to meet the actual usage of the DCH

is based on the throughput measurement of the DCH. The throughput is measured by

the MAC-d entity of the RNC for each transport channel by monitoring the used bit rate.

Modification of the NRT DCH bit rate is made for uplink and downlink directions inde-

pendently from each other.

100%

downgrade_upper threshold

downgrade_lower threshold

release_threshold

ave_throughput

send downgrade request to PS send release request to PS







DN0495772

Issue 14C

57


Id:0900d8058074c314

Release throughput, upper throughput and lower throughput measurements are also

applicable for the HSDPA uplink DCH return channel. For information about through-

put/usage measurements related to the HSDPA MAC-d flow, see Supported bit rates for

HSDPA in WCDMA RAN RRM HSDPA.

Activation and deactivation of the feature

In general, the throughput measurements are activated when a new or modified DCH is

established.

UE-specific packet scheduler selects the appropriate RNP parameters for throughput

based optimisation of the packet scheduler algorithm during anchoring. The principle is

similar to the non-anchoring situation.

During anchoring, all the RNC level parameters, that are used, refer to the SRNC

parameters, and the VCEL parameters refer to the reference cell object parameters.

The operator can, however, determine with the PSOpThroUsage parameter whether the

feature is active or not for a certain NRT traffic class or group of NRT traffic classes asshown in the following table.

If the feature is not activated for a traffic class, throughput measurements (release,

upper and lower) are not activated for the NRT DCHs of that traffic class.

The same procedures are used during anchoring.

Sliding measurement window is used in throughput measurements

The average throughput is calculated over a sliding measurement window.

The throughput is calculated in every transmission time interval (TTI) – thus the mea-

surement window is shifted with one sample in every TTI – and the collection of samples

starts immediately when the data is first transmitted on the allocated DCH. The mea-

surement window has to be full of samples before the throughput can be calculated.

Downlink throughput is calculated so that all the transmitted bits during the measure-

ment window are measured. Uplink throughput is calculated so that all the correctly

received bits during the measurement window are measured.

The measurement window sizes for the upper throughput measurement, lower through-

put measurement, and release throughput measurement are defined with the DCHUti-

lUpperAveWinBitRate, DCHUtilLowerAveWinBitRate and DCHUtilRelAveWin RNP

parameters.

The throughput measurements (release, upper, lower) can be activated or deactivated

separately. If the measurement window size is set to ‘off’ the throughput measurement

is not performed.

Usage of the throughput-based optimisation of the PS algorithm

feature activation/deactivation On or Off, interactive traffic class and traffic handling priority 1,

On or Off, interactive traffic class and traffic handling priority 2,

On or Off, interactive traffic class and traffic handling priority 3,

On or Off, background traffic class.Default, inactive for all NRT

traffic classes.

Table 9 Usage of throughput-based optimisation of the PS algorithm









58 DN0495772

Issue 14C


Id:0900d8058074c314

MAC-d entity of the RNC sends indication of NRT DCH usage level to UE-specific

PS

The NRT DCH usage is measured and the average throughput of the DCH is calculated

in every TTI as described above.Based on this calculation the MAC-d entity of the RNC detects when the average

throughput goes below or above the upper downgrade, lower downgrade or release

threshold.

When the throughput of the NRT DCH is detected to be below a threshold, the MAC-d

entity of the RNC sends a release or downgrade indication to the UE-specific PS.

However, even though there are three separate throughput measurements with specific

thresholds, there can be only one level of usage that triggers the release or downgrade

indication for a DCH at a time. Because of this, the usage level of the NRT DCH is eval-

uated with perspective to all three throughput measurements, each time a release or

downgrade indication is to be sent. The levels of usage are prioritised in the following

order: ‘below release threshold’, ‘below lower downgrade threshold’, ‘below upper

downgrade threshold’. If, for instance, a downgrade request to the UE-specific PS has

been sent with indication ‘below release threshold’, it cannot be followed by another

downgrade request with a different indication as long as the NRT DCH usage is below

the release threshold.

When a release or downgrade indication for an NRT DCH has been sent, further release

or downgrade indications for that DCH are denied for a period of time determined by the

TrafVolPendingTimeUL and TrafVolPendingTimeDLRNP parameters. During this

period no release or downgrade indications are sent from the MAC-d entity of the RNC

to the UE-specific PS.

When the timer expires the current usage of the NRT DCH is evaluated and the release

or downgrade indication is immediately sent if the usage level is not ‘normal’, that is, the

level of usage has gone below a threshold defined for throughput measurements and

does not correspond to the allocated DCH data rate.

The DCHutilMeasGuardTime RNP parameter defines the guard time during which the

MAC-d entity of the RNC cannot send release or downgrade indications to the UE-

specific PS. The guard timer is set when the throughput measurements are activated.

If the throughput of the NRT DCH after a downgrade request is detected to be above the

threshold, which caused the downgrade request, and the NRT DCH usage is normal,

the MAC-d entity of the RNC sends a ‘normal’ indication to the UE-specific PS. The

downgrade then is interrupted.

The NRT DCH data rate upgrade request triggered by traffic volume measurement (seeTraffic volume measurements and Flexible upgrade of the NRT data rate in UE-specific

part of the packet scheduler) is ignored, that is, the MAC-d entity of the RNC does not

send a downlink capacity request to the UE-specific PS if the NRT DCH usage is not on

‘normal’ level.

The indication to the UE-specific PS is not sent immediately in all throughput measure-

ments when the average throughput goes below a threshold. For each throughput mea-

surement there is a supervision period, defined by the RNP parameters, after which the

indication is sent if the usage level still requires it.



DN0495772

Issue 14C

59


Id:0900d8058074c314

Figure 20 Throughput measurement of NRT DCHs

Release throughput measurement

In release throughput measurement the average throughput is compared with the

uplink/downlink NRT DCH release threshold.

The release threshold for the uplink NRT DCH is defined with the DCHUtilRelThrUL

RNP parameter and the value of the parameter is valid for all NRT DCH bit rates except

0 bps.

The release threshold for the downlink NRT DCH is defined with the DCHUtilRelThrDL

RNP parameter and the value of the parameter is valid for all NRT DCH bit rates except

0 bps.

The supervision period for the release throughput measurement is defined with the

DCHUtilRelTimeToTrigger RNP parameter. The value of the parameter is valid for all

NRT DCH bit rates for both uplink and downlink directions.

The parameters are provided by the UE-specific PS to the MAC-d entity of the RNC

when a new NRT DCH is established or an existing one is modified.

When the throughput goes below the release threshold the supervision period for

release throughput measurement is started.

• The release indication is sent when the supervision period for release throughput

measurement expires and the usage is still below the release threshold.

• If the throughput goes above the release threshold after the release request has

been sent, a short internal supervision period is started and if the usage of the

NRT DCH is still above the release threshold when the period expires, the

release is tried to cancel by sending a ‘normal’ indication.

• If the throughput goes above the release threshold during the supervision period for

release throughput measurement, the supervision is stopped and the release is not

performed.

DCH bit rate/[bit/s]

Sliding measurement window

Throughput during the slidingmeasurement window

DCH "release, downgrade upper or downgrade lower" threshold

L2 inform L3: 'DCH utilisation isbelow threshold'

L2 inform L3: 'DCH utilisationnormal.

Below and aboveDCH "in case"

threshold detected

100%

t/[s]

TTI



60 DN0495772

Issue 14C


Id:0900d8058074c314

Lower throughput measurement

In lower throughput measurement the average throughput is compared with the

uplink/downlink NRT DCH lower threshold.

The target bit rate (RTargetLowerDnRate ) for lower downgrade is defined by the DCHUtilLow-erDowngradeThrBitRateparameter. The parameter defines the target bit rate for each

NRT DCH bit rate.

If the target bit rate is lower than the minimum allowed bit rate (MinAllowedBitRateUL/DL

or HSDPAMinAllowedBitrateUL in case of an uplink NRT DCH HSDPA return channel),

the lower throughput measurement is not activated.

The lower threshold for downgrade RThrLower is defined by the following equation:

R ThrLower =RTargetLowerDnRate*(1-DCHUtilLowerDowngradeThr )

where R TargetLowerDnRate is defined by the DCHUtilLowerDowngradeThrBitRate manage-

ment parameter as specified above.

DCHUtilBelowDowngradeThr is used to define the threshold for downgrade in lower throughput measurement. The value range for this parameter is 0…1 with a step size of

0.1.

The supervision period for lower throughput measurement is defined by the DCHUtil-

LowerTimeToTriggerBitRate parameter - a value is defined for each NRT DCH bit rate

except for bit rates lower than 32 kbps. The lower throughput measurement is not

allowed for bit rates lower than 32 kbps.



When the throughput goes below the lower threshold the supervision period for lower

throughput measurement is started.• The lower downgrade indication is sent when the supervision period for lower

throughput measurement expires and the usage is still below the lower threshold.

• If the throughput goes above the lower threshold after the downgrade request

has been sent a short internal supervision period is started and if the usage of

the NRT DCH is still above the lower threshold when the period expires, the

downgrade is tried to cancel by sending a ‘normal’ indication.

• If the throughput goes above the lower threshold during the supervision period for

lower throughput measurement, the supervision is stopped and downgrade is not

performed.

Upper throughput measurement

In upper throughput measurement the average throughput is compared with the

uplink/downlink NRT DCH upper threshold.

The target bit rate (R TargetUpperDnRate ) for upper downgrade is defined by the DCHUtilUp-

perDowngradeThrBitRate parameter. The parameter defines the target bit rate for each

NRT DCH bit rate.

If the target bit rate is lower than the minimum allowed bit rate (MinAllowedBitRateUL/DL

or HSDPAMinAllowedBitrateUL in case of an uplink NRT DCH HSDPA return channel),

the upper throughput measurement is not activated.

The upper threshold for downgrade R ThrUpper is defined by the following equation:

R ThrUpper

=R TargetUpperDnRate

*(1-DCHUtilUpperDowngradeThr )



DN0495772

Issue 14C

61


Id:0900d8058074c314

where R TargetUpperDnRate is defined with the DCHUtilUpperDowngradeThrBitRate man-

agement parameter as specified above.

DCHUtilBelowDowngradeThr is used to define the threshold for downgrade in upper

throughput measurement. The value range for this parameter is 0…1 with a step size of 0.1.

The supervision period for the upper throughput measurement is defined by the DCHUti-

lUpperTimeToTriggerBitRateparameter - a value is defined for each NRT DCH bit rate

except for bit rates lower than 32 kbps. The upper throughput measurement is not

allowed for bit rates lower than 32 kbps.



When the throughput goes below the upper threshold the supervision period for upper

throughput measurement is started.

• The upper downgrade indication is sent when the supervision period for upper throughput measurement expires and the usage is still below the upper threshold.

• If the throughput goes above the upper threshold after the downgrade request

has been sent a short internal supervision period is started and if the usage of

the NRT DCH is still above the upper threshold when the period expires, the

downgrade is tried to cancel by sending a ‘normal’ indication.

• If the throughput goes above the upper threshold during the supervision period for

upper throughput measurement, the supervision is stopped and downgrade is not

performed.

The following figure illustrates the evaluation of the NRT DCH usage based on through-

put measurements.



62 DN0495772

Issue 14C


Id:0900d8058074c314

Figure 21 NRT DCH throughput measurement and usage indication by the MAC-d

entity of the RNC

In this example, the upper throughput goes below the upper downgrade threshold and

the supervision period for upper throughput measurement is started (4 s). Then the

lower throughput goes below the lower downgrade threshold and the supervision period

for lower throughput measurement is started (1.5 s). When the supervision period for thelower throughput measurement is expired and the lower downgrade request is sent to

the UE-specific PS. When the supervision period for upper throughput measurement

expires the evaluated NRT DCH usage is still detected to be below the lower bit rate

threshold. (It is of course also below the upper threshold but only one result is valid and

because of prioritisation the result is ‘below lower threshold’). The NRT DCH bit rate is

thus downgraded to the lower target bit rate.

Throughput measurements are stopped during compressed mode and load

control actions

When the UE is in compressed mode and higher layer scheduling (HLS) is used as com-

pressed mode method for the allocated NRT DCH, the throughput measurements are

UpperAve-Win 2 s

LowerAve-Win 2 s

Lower-TimeTo-Trigger

1.5 s

384

240

61

bit rate/[kbps]

Release threshold

Throughput goesbelow downgrade_

upper_threshold

Throughput goesbelow downgrade_

lower_threshold

t/[s]

Downgrade_Lower threshold

NRT DCH bit rate modified as requested

Upper time to trigger expires. Evaluated NRTDCH utilisation is still below downgrade

lower threshold

Lower time to trigger expires. MAC-d sendsdowngrade lower request to L3

Allocated NRT DCH bit ratebefore NRT DCH modification

Downgrade_Upper threshold

Throughput in release throughputmeasurement

Data ThroughputThroughput in upper throughputmeasurement

Throughput in lower throughputmeasurement

Evaluated NRT DCH utilisation level: normal, below downgrade upper, below downgrade lower and below release

'normal' 'normal'lower

Allocated NRT DCH bit rate:

NRT DCH maximum bit rate 384 kbps Modified NRT DCH maximum bit rate: 64 kbps

ReleaseAveWin 1 s

UpperTimeToTrigger 4 s



DN0495772

Issue 14C

63


Id:0900d8058074c314

stopped. When the compressed mode is over the throughput measurements are started

again.

When a load control action is taken by using the TFC subset method the throughput

measurements for the allocated NRT DCH are stopped. When the bit rate is returned tothe original bit rate, the throughput measurements are started again.

Old measurement samples are reset and new collection of samples is started immedi-

ately after the throughput measurement interruption because of compressed mode or

load control being over.

6.6.2 Throughput-based optimisation of the NRT DCH data rate

Throughput-based optimisation of the NRT DCH data rate is based on the throughput

measurement indications sent by the MAC-d entity of the RNC to the UE-specific PS as

described in Throughput measurements.

MAC-d entity of the RNC sends a release request to the UE-specific PS

After the UE-specific PS has received a release request for an UL/DL NRT DCH,

possible capacity and upgrade requests are rejected.

Uplink and downlink NRT DCHs are released if the release is valid for both directions at

the same time and there is no other radio bearer with user plane DCHs allocated to the

UE.

If the release is valid for both directions but there is another user plane DCH allocated

to the UE, the UL/DL DCH is downgraded to 8/8 kbps instead of releasing the DCH. This

is done to avoid consecutive release and capacity requests.

If the release is not valid for both directions, the bit rate is downgraded to the minimum

allowed bit rate if the maximum bit rate of the DCH is higher than the minimum allowedbit rate. The minimum allowed bit rate is defined with the MinAllowedBitRateUL/DL

parameter or, in case of an HSDPA return channel, with the HSDPAMinAllowedBitRa-

teUL parameter.

MAC-d entity of the RNC sends a downgrade request to the UE-specific PS

After the UE-specific PS has received a downgrade request for an uplink/downlink NRT

DCH, possible capacity and upgrade requests are rejected.

When the usage of the NRT DCH is detected to be below the upper bit rate threshold,

the bit rate of the DCH is downgraded to the upper target bit rate R TargetUpperDnRate. The

upper target bit rates for different NRT DCH bit rates are defined with the DCHUtilUp-

perDowngradeThrBitRateparameter, see Table Lower and upper downgrade target bit rates for the NRT DCH .

The radio link reconfiguration procedure is applied when NRT DCHs are downgraded

because of throughput measurements.

Allocated UL/DL NRT DCH bit

rate [kbit/s]

Lower downgrade bit rate

for NRT DCH [kbit/s]

Upper downgrade bit rate for

NRT DCH [kbit/s]

32 8 16

64 16 32

128 16 64

Table 10 Lower and upper downgrade target bit rates for the NRT DCH.



64 DN0495772

Issue 14C


Id:0900d8058074c314

The throughput-based optimisation of the packet scheduler algorithm is illustrated in the

following figure.

Figure 22 Throughput-based optimisation of the packet scheduler algorithm sum-

marises the functionality of throughput-based optimisation of the NRT DCH data rate.

256 32 128

384 64 256

Allocated UL/DL NRT DCH bit

rate [kbit/s]

Lower downgrade bit rate

for NRT DCH [kbit/s]

Upper downgrade bit rate for

NRT DCH [kbit/s]

Table 10 Lower and upper downgrade target bit rates for the NRT DCH. (Cont.)



DN0495772

Issue 14C

65


Id:0900d8058074c314

Figure 22 Throughput-based optimisation of the packet scheduler algorithm

end

Throughput based optimi-sation of the PS algorithm

Utili-sation level of

the UL/DL NRT DCHdetected to be in below

the release bit ratethreshold?

UL/DL NRT DCH through-put measurement

TheUL/DL NRT DCHPending timer not

running?

Utili-sation level of

the UL/DL NRT DCHdetected to be in below

the lower bit ratethreshold?Utili-

sation level of the UL/DL NRT DCH

detected to be in belowthe upper bit rate

threshold?

Evalua-ted utilisation levelof the UL/DL NRT DCH

changed to nor-mal level?

UL/DL NRTDCH bit rate > minimum

allowed UL/DLbit rate


running?

UL andDL NRT DCH release

is valid

L3 discards not yethandled UL/DL NRT

DCH release/downgraderequest/indication due to

throughput measurements

The UL/DL NRT DCH'normal' indication to L3

end

end

end

end

The UL/DL NRTDCH 'release'

request/indicationto L3. L2 starts UL/DL

Pending timer

UE hasno other RB thatuser plane DCHs

exists

L3 downgradesUL & DL

NRT DCH to8/8 kbps

L3 downgradesUL/DL NRTDCH bit rateto minimum

allowedbit rate

end

end

The UL/DL NRT DCH'upper downgrade'

request/indication toL3. L2 starts Pending timer

end

L3 downgrades UL/DLNRT DCH bit rate

to target upper bit rate

L3 downgrades UL/DLNRT DCH bit rate totarget lower bit rate

end

The UL/DL NRT DCH'lower downgrade'

request/indication to L3.L2 startsPending timer

end


running?

L3 startsprocedure to

release UL & DLNRT DCH

end

No

Yes Yes

No

No

No

Yes

Yes

No

Yes

Yes

Yes

No

Yes

No

No

Yes

Yes



66 DN0495772

Issue 14C


Id:0900d805805dca36

6.7 Flexible upgrade of the NRT DCH data rate

The feature flexible upgrade of the NRT DCH data rate provides the means for upgrad-

ing the NRT DCH bit rate from any bit rate up to the maximum bit rate of the radio bearer

when certain predetermined conditions are met.

When the NRT DCH bit rate is upgraded, the packet scheduler uses the averaged

downlink radio link power to estimate the power increase instead of using only the last

received measurement result, which is used otherwise when estimating power increase.

This is done to avoid a ping-pong effect when the downlink radio link power varies a lot.

The usage of the feature is controlled with the Usage of the flexible upgrade of the NRT

DCH data rate (FlexUpgrUsage) RNW configuration parameter. The feature can be acti-

vated by setting the parameter value to ‘On’. In this case, the flexible upgrade of the NRT

data rate is applied allowing upgrades from any data rate to the maximum allowed bit

rate of the radio bearer in question according to the principles presented in the following

sections. If the parameter is set to ‘Off’, the flexible upgrade of the NRT data rate is not

used.

The feature is activated also for the uplink NRT DCH HSDPA return channel if both

DynUsageHSDPAReturnChannel and FlexUpgrUsageRNP parameters are set to ‘On’.

With the Support for I-HSPA Sharing and Iur Mobility Enhancements feature, Flexi

Upgrade of NRT DCH Data Rate feature is supported during anchoring if Flexi Upgrade

feature is activated in the SRNC.

Flexible upgrade of the NRT DCH data rate algorithm

The flexible upgrade of the NRT DCH data rate is based on traffic volume measure-

ments and high throughput measurements both in uplink and downlink.

Traffic volume measurement report in uplink and downlink

The flexible upgrade of the NRT DCH data rate is based on traffic volume measurement

reports sent by the UE in uplink and by the MAC-d entity of the RNC in downlink to the

UE-specific PS of the RNC.

For a description of the traffic volume measurement, see Traffic volume measurements.

The TrafVolThresholdULHighBitRateand TrafVolThresholdDLHighBitRateparameters

are used instead of TrafVolThresholdULHigh and TrafVolThresholdDLHigh parameters

when flexible upgrade is applied.

The following figure illustrates the situation when a traffic volume measurement report

is triggered using flexible upgrade of the NRT DCH data rate in downlink.



DN0495772

Issue 14C

67


Id:0900d805805dca36

Figure 23 Triggering of traffic volume measurement in downlink when bit rate depen-

dent high threshold is exceeded

Transport ChannelTraffic Volume

TrafVolThresholdDLHighBitRate

Reportingevent

Reportingevent

Time



68 DN0495772

Issue 14C


Id:0900d8058065d4e1

6.8 High throughput measurement

This functionality enables the operator to control the bit rate update algorithm when the

feature flexible upgrade of the NRT DCH data rate is used. This is done by activating

the high throughput measurement and setting the data rate threshold to a level wherebit rate upgrading is possible if requested by the UE or the UE-specific MAC-d entity of

the RNC. When the measured throughput of the NRT DCH is under the threshold, the

bit rate upgrading is denied.

The high throughput measurement is performed by the MAC-d entity of the RNC.

When the high throughput measurement is activated it is possible to avoid useless NRT

DCH upgrades when the already allocated NRT DCH is not used perfectly (low through-

put). It is a waste of HW and processing capacity if the NRT DCH shall be upgraded

although already used NRT DCH capacity is not high (unused available capacity).

Measurement attributes are managed by using the DCHutilHighAveWin, DCHutilHigh-

BelowNRTDataRateThr and DCHutilHighTimeToTrigger RNP parameters.

DCHutilHighAveWin defines the sliding measurement window size for the high through-

put measurement of the NRT dedicated channel for both uplink and downlink directions.

When the high throughput sliding measurement window size is set ‘off’ the high through-

put measurement is not activated.

The uplink and downlink NRT DCH high threshold attribute for the UL and DL NRT DCH

high throughput measurement is defined independently of each other if the used bit

rates are different in uplink and downlink directions.

The high threshold R ThrHigh value for the high throughput measurement is specified in the

following equation:

R ThrHigh = R DataRate*(1-DCHutilHighBelowNRTDataRateThr )where R DataRate is NRT DCH bit rate.

The supervision period for time to trigger high is defined with the DCHutilHighTime-

ToTrigger parameter and it is valid for both uplink and downlink DCHs.

The supervision period for time to trigger below threshold is a fixed value.

The measurement attributes are delivered to the MAC-d entity of the RNC when the

measurement is activated.

When the NRT DCH throughput exceeds the threshold R DataRate a supervision period for

the time to trigger high indication is started. If the NRT DCH time to trigger high super-

vision period expires, the NRT DCH is detected to be above the high threshold R DataRate

and the MAC-d entity of the RNC sends the high throughput indication to the UE-specificPS.

When the measurement is active, the flexible upgrade of the NRT DCH data rate is

allowed only if the high throughput measurement information received by the UE-

specific PS from the MAC-d entity of the RNC indicates high throughput, otherwise the

upgrade request for high bit rate is rejected by the UE-specific PS.

If the NRT DCH throughput goes below the threshold R DataRate and the NRT DCH time

to trigger high supervision period has not expired, the NRT DCH time to trigger high

supervision is stopped.

When the NRT DCH throughput goes below the threshold R DataRate a supervision period

for the time to trigger below the threshold is started.



DN0495772

Issue 14C

69


Id:0900d8058065d4e1

If the NRT DCH time to trigger below the threshold supervision period expires, the NRT

DCH is detected to be below the high threshold R DataRate and the MAC-d entity of the

RNC sends the normal throughput indication to the UE-specific PS.

If the NRT DCH throughput goes back to above the threshold R DataRate before the timeto trigger below threshold supervision period expires, the time to trigger below threshold

supervision is stopped.

The throughput indication related to high throughput measurement is not sent to the UE-

specific PS if release throughput measurement indicates low usage leading to release

of the NRT DCH.

High throughput measurement is valid also for the UL NRT DCH HSDPA return channel

if the DynUsageHSDPAReturnChannel and FlexUpgrUsage RNP parameters are set to

‘On’. For more information about throughput/usage measurements related to the

HSDPA MAC-d flow, see UE-specific resource handling in WCDMA RAN RRM HSDPA.

Capacity request to cell specific PS

When the UE-specific PS receives the traffic volume measurement report from UE as

uplink capacity request or from the MAC-d entity of the RNC as a downlink capacity

request indicating upgrade request for high bit rate, it verifies that the FlexUpgrUsage

parameter is set to ‘On’.

High throughput and release throughput indications are used when deciding whether

upgrade is allowed or not. For more information, see Section Traffic volume measure-

ments.

If the upgrade request for high bit rate is accepted by the UE-specific PS, it forwards the

uplink and downlink traffic volume measurement reports, that is, capacity requests to

every cell-specific PS included in the active set.

Power increase estimation in cell-specific PS

When the cell-specific PS has received the upgrade request for high bit rate from the

UE-specific PS it makes the power increase estimation using the averaged downlink

radio link power.

The calculation of the average downlink transmission power is presented in Estimation

of power change.

Modifying the high traffic volume threshold

When a high bit rate DCH lower than the radio bearer maximum bit rate has been allo-

cated for the radio bearer and the FlexUpgrUsageparameter is set to ‘On’, the traffic

volume measurement is modified and a new reporting threshold is set according to thefollowing things:

• If the allocated NRT DCH bit rate is greater than 0 kbps but lower than the radio

bearer maximum bit rate, the traffic volume measurement is set so that the bit rate

dependent high traffic volume threshold is used as a reporting threshold.

The bit rate dependent high traffic threshold is selected on the basis of the Traf-

VolThresholdULHighBitRate or TrafVolThresholdDLHighBitRate parameter,

respectively for uplink and downlink direction, by using the NRT DCH bit rate as a

reading parameter.

• If the value of the bit rate dependent high traffic threshold is the same as the already

used value in the existing traffic volume measurement, the traffic volume measure-

ment is not modified.







70 DN0495772

Issue 14C


Id:0900d8058065d4e1

• If the allocated NRT DCH bit rate is equal to the radio bearer maximum bit rate, the

traffic volume measurement is released for the radio bearer in question.

Interoperability

Compressed mode

When compressed mode is activated and HLS is used as compressed mode method,

the throughput measurement is stopped.

Load control actions

When load control actions are taken using the TFC subset method the throughput mea-

surement is stopped.

When high throughput measurement is temporarily stopped because of compressed

mode or load control actions, upgrade of the NRT DCH data rate is not possible.

The throughput measurement is started immediately when the compressed mode situ-

ation is over or when the allocated NRT DCH maximum bit rate restriction (by TFCsubset method) is over. The old measurement samples are ignored and the collection

of new samples starts immediately.

Dynamic link optimisation for NRT traffic coverage

The cell-specific packet scheduler uses the averaged DPDCH code power of radio link

(Ptx_average) in the case of radio link downlink transmission power comparison for the

dynamic link optimisation purpose. The calculation of the Ptx_average is presented in

Dynamic link optimisation for non-real time traffic coverage.

Example:

This example presents the process to upgrade the NRT DCH data rate in downlink from

the initial bit rate to the high bit rate and finally to the maximum allowed bit rate.When the data amount in the RLC buffer exceeds the threshold TrafVolThresholdDL-

Low the UE sends the traffic volume measurement report to the UE-specific PS in L3.

Based on the traffic volume measurement report, the UE-specific PS sends the capacity

request to the cell specific PS of RNC.

The cell-specific PS makes the required admission control actions including power

change estimation. Average value of downlink transmission power is used. The cell-

specific PS allocates the initial bit rate.

The UE-specific PS modifies the traffic volume measurement by replacing the Traf-

VolThresholdDLLow parameter with the TrafVolThresholdDLHighBitRate parameter.

When the MAC-d entity of the RNC detects the data amount in the RLC buffer exceedsthe threshold TrafVolThresholdDLHighBitRate it sends the traffic volume measurement

report to the UE-specific PS as an upgrade request.

The UE-specific PS forwards the upgrade request to the cell-specific PS which tries to

allocate the maximum allowed bit rate. In the example, congestion is met and a lower

than maximum allowed bit rate is allocated. The traffic volume measurement is modified.

Finally when the upgrade to the maximum allowed bit rate succeeds the UE-specific PS

stops the traffic volume measurement of the upgraded NRT DCH.



DN0495772

Issue 14C

71


Id:0900d8058065d4e1

Figure 24 Example 1: Flexible upgrade of the NRT DCH data rate in downlink.

10 2 3 4 6 7 8 10 11 12 13 14 15

8

16

32

64

128

256

384

DL DCHData Rate

[kbps]

Time[RRind Period]

Reportedbuffer size

[bytes]

2048

1024

128

8

ax mum ate rate o t eNRT RAB (High data rate)is tried but congestion metand upgrade to 128 kbps

succeeded. TVM modified

ase on t emeasurement report,

initial data rate allocated,TVM modified

pgra e to max mumdata rate of the NRT

RAB succeeded.TVM stopped

Maximum data rateof the NRT RAB

UE sendsMeasurement

report


requestRRind Period

Allocated data rateof the NRT RAB

InitialBitRate


request



72 DN0495772

Issue 14C


Id:0900d8058065d52e

6.9 DCH bit rate balancing

DCH bit rate balancing is applied to DL DCH, UL DCH, and HSDPA UL DCH return

channels.

The maximum supported total bit rate of the radio link, excluding AMR (AMR-wideband

or AMR-narrowband) and SRB, amounts to 384 kbit/s. For NB/RSxxx the bit rate might

be limited by the MaxDCHuserRateRLUL and MaxDCHuserRateRLDL parameters.

This limitation is effective regardless of the number of PS RABs. For multiple PS RABs,

the total bit rate of the radio link balances between radio bearers to guarantee DCH bit

rate to all established NRT PS RABs. Balancing is targeted at NRT PS RAB(s), not RT

PS RAB(s).

DCH bit rate balancing is applied when the received capacity request is scheduled and

a RB is mapped to the DCH. If the DCH cannot be allocated to the PS RAB without

exceeding the maximum bit rate of the radio link, the DCH(s) of the existing PS RAB(s)

is/are downgraded. The highest possible bit rate is allocated to the existing DCH(s) to

be downgraded.

Before the downgrade of the existing DCH, the cell-specific PS schedules new bit rates

to ensure that the resource allocation is successful in the RNC. The cell-specific PS

allows for the DCH(s) to be downgraded to acquire capacity when the new DCH is

scheduled. After the scheduling decision, the existing DCH is downgraded, and the new

DCH is allocated.

The bit rate of the existing DCH is not downgraded below the initial bit rate level. The

operator defines the initial bit rate using the existing RNW parameters:

HSDPAinitialBitrateUL and HSDPAInitialBRULStrNRT RNC parameters for

HSDPA UL DCH return channel, and InitialBitRateDL and InitialBitRateUL

WCEL parameters for R99 DCH. The RNW WCEL HSDPAMaxBitrateUL parameter

might limit an initial bit rate for HSDPA UL DCH return channel if the maximum set bit

rate is lower than the initial bit rate.

If there are two DCH channels that can be downgraded, and only one of them needs to

be downgraded, the following prioritization applies:

1. the highest DCH bit rate

2. the lowest priority defined by the RNC QoSPriorityMapping parameter

DCH bit rate balancing control

DCH bit rate balancing belongs to the basic software (BSW). DCH bit rate balancing is

controlled by the RNC DCHBitRateBalancingparameter. The parameter affects the

UL DCH if the radio bearer is mapped to HS-DSCH and UL DCH. The parameter affectsthe DL DCH and UL DCH if the radio bearer is mapped to DL DCH and UL DCH, respec-

tively.

The parameter is on-line modifiable. The parameter is read for the DCH allocation pur-

poses. DCH bit rate balancing is applied when the capacity request is scheduled and

the DCH is allocated. DCH bit rate balancing is not applied for purposes of the DCH bit

rate upgrade or downgrade.

Decrease of the re-tried DCH bit rate and the priority-based scheduling are applied

during the DCH bit rate balancing.

If the allocation of the new DCH fails due to the BTS, the AAL2 transmission (Iub and

Iur), or the RNC internal resouces, the NRT DCH bit rate is decreased, and the alloca-

tion is re-attempted according to the retry procedure described in section Traffic volume



DN0495772

Issue 14C

73


Id:0900d8058065d52e

measurements. The balanced (downgraded) DCH bit rate is used in re-attempts for the

existing DCH.

Even if the allocation of an initial bit rate for the new DCH fails, the priority-based sched-

uling is started for the new DCH according to the existing principles.

Use case 1: HSDPA UL DCH return channel

Preconditions:

• DCH bit rate balancing is On (DCHBitRateBalancing parameter enabled)

• RAB1 NRT (interactive) PS RAB established; RAB2 NRT (interactive) PS RAB

established

• HS-DSCH allocated in the downlink and DCH 384 kbit/s allocated in the UL for

RAB1

• RAB2 RB mapped to DCH 0/0 (inactive)

• initial bit rate equals 128 kbit/s (128 kbit/skbit/s set for the

HSDPAinitialBitrateUL parameter)

Actions:

1. RAB2 requests capacity.

2. RAB1 UL DCH is downgraded from 384 kbit/s to 128 kbit/s.

3. RAB2 128 kbit/s UL DCH is allocated.

Use case 2: HSDPA UL DCH return channel

Preconditions:


• RT PS Streaming RAB, two NRT (interactive) PS RABs and one NRT (background)

PS RAB established

• HS-DSCH allocated in the downlink (DL) and DCH 128 kbit/s allocated in the uplink

(UL) for Streaming RAB

• HS-DSCH allocated in the DL and DCH 128 kbit/s allocated in the UL for NRT (inter-

active) PS RAB1

• RAB2 (interactive) RB mapped to DCH 0/0 (inactive)

• HS-DSCH allocated in the DL and DCH 128 kbit/s allocated in the UL for NRT (back-

ground) PS RAB3

• initial bit rate equals 64 kbit/s (64 kbit/s set for the HSDPAInitialBRULStrNRT

parameter)

• synchronous physical interface (SPI) defined by the QoSPriorityMapping

parameter interactive > background

Actions:

Service DL HS-DSCH / UL DCH

Before After

RAB1 interactive HS-DSCH / 384 HS-DSCH / 128

RAB2 interactive 0 / 0 HS-DSCH / 128

Table 11 RABs bit rate for HSDPA UL DCH return channel before and after DCH bit

rate balancing activation



74 DN0495772

Issue 14C


Id:0900d8058065d52e

1. RAB2 requests capacity.

2. RAB3 UL DCH is downgraded from 128 kbit/s to 64 kbit/s.

3. RAB2 64 kbit/s UL DCH is allocated.

Use case 3: DL DCH / UL DCH

Preconditions:


• RAB1 NRT (interactive) PS RAB established; RAB2 NRT (interactive) PS RAB

established

• DCH 384 kbit/s allocated in the DL and UL for the RAB1

• RAB2 RB mapped to DCH 0/0 (inactive)

• initial bit rate equals 64 kbit/s (64 kbit/s set for the InitialBitRateDL and

InitialBitRateUL parameters)

Actions:

1. RAB2 requests a high bit rate.

2. RAB1 DL DCH and UL DCH are downgraded from 384 kbit/s to 256 kbit/s.

3. RAB2 128 kbit/s DL DCH and UL DCH are allocated.

Use case 4: DL DCH / UL DCH

Preconditions:

• DCH bit rate balancing is on (DCHBitRateBalancing parameter enabled)

• two NRT (interactive) PS RABs and one NRT (background) PS RAB established

• DCH 256 kbit/s allocated in the DL and UL for the RAB1 (interactive)

• RAB2 (interactive) RB mapped to DCH 0/0 (inactive)

Service DL HS-DSCH / UL DCH

Before After

Streaming PS RAB HS-DSCH / 128 HS-DSCH / 128

RAB1 interactive HS-DSCH / 128 HS-DSCH / 128

RAB2 interactive 0 / 0 HS-DSCH / 64

RAB3 background HS-DSCH / 128 HS-DSCH / 64

Table 12 RABs bit rate for HSDPA UL DCH return channel before and after DCH bitrate balancing activation

Service DL DCH / UL DCH

Before After

RAB1 interactive 384 / 384 256 / 256

RAB2 interactive 0 / 0 128 / 128


activation



DN0495772

Issue 14C

75


Id:0900d8058065d52e

• DCH 128 kbit/s allocated in the DL and DCH 64 kbit/s allocated in the UL for RAB3

(background)

• initial bit rate equals 64 kbit/s (64 kbit/s set for the InitialBitRateDL and

InitialBitRateUL parameters)• SPI defined by the QoSPriorityMapping parameter interactive > background

Actions:

1. RAB2 requests a high bit rate.

2. RAB1 DL DCH is downgraded from 256 to 128 kbit/s.

3. RAB2 128 kbit/s DL DCH and 64 kbit/s UL DCH are allocated.

4. RAB3 is not configured.

Service DL DCH/UL DCH

Before After

RAB1 interactive 256 / 256 128 / 256

RAB2 interactive 0 / 0 128 / 64

RAB3 background 128 / 64 128 / 64


activation



76 DN0495772

Issue 14C


Id:0900d8058074c31f

Cell-specific part of the packet scheduler

7 Cell-specific part of the packet scheduler

7.1 Cell- and radio link-specific load status informationThe RNC implements a hybrid throughput and interference-based algorithm for the

uplink DCH resource allocations. Benefit of this kind of algorithm is that it offers at least

the minimum uplink service for the DCH users in the cell which is suffering of the

received wide band interference spikes. Downlink DCH resource allocation is based

merely on the power estimations; any throughput based guarantees are not given for the

downlink DCH users. Detailed description of the principles of hybrid interference and

throughput based DCH resource allocation is introduced in the WCDMA RAN RRM

Admission Control; this document describes how they are applied in the DCH schedul-

ing for the PS interactive and background services.

The scheduling period of the cell-specific packet scheduler is independent of the mea-

surement characteristics of the NBAP common measurements. Periodical or immediatescheduling can be applied for the received PS NRT DCH resource. The scheduling

period is defined by the BTS-specific RNC configuration parameter Scheduling period

(SchedulingPeriod).

The moment of the scheduling for a PS NRT DCH resource request is determined in two

ways:

• Immediate scheduling

The cell-specific PS schedules the DCH resources for the PS NRT resource request

immediately upon the reception of the resource request. Immediate scheduling is

done if the cell has not any earlier PS resource request in the scheduling queue.

If the immediate scheduling fails due to the received wideband interference, limited

transmitted carrier power, or limited downlink spreading codes, the resource request

is queued for the next allowed periodic scheduling moment. The next allowed

moment for the periodic scheduling in this case is not earlier than a full scheduling

period after the moment of the immediate scheduling. The limitation applies to all PS

NRT DCH resource requests received during the period.

• Periodic scheduling

The received PS NRT DCH resource requests are scheduled in regular intervals.

The resource requests are queued for the next scheduling moment. The scheduling

period is specified by the management parameter SchedulingPeriod for uplink and

downlink resource allocations.

The channel type is selected for all PS NRT service resource requests immediately

without waiting for the next scheduling moment. If only HSPA channels are selected for

the resource request, the MAC-d flows are established immediately. All queued PS NRT

service resource requests and those PS NRT service resource requests, which result to

the allocation of a DCH in either of the two transfer directions, are processed as defined

above for the queued PS NRT DCH resource requests.

The operating principle of cell-specific packet scheduler in the DRNC is the same as in

the SRNC if the Support for I-HSPA Sharing and Iur Mobility Enhancements feature is

activated in the DRNC.











DN0495772

Issue 14C

77

WCDMA RAN RRM Packet Scheduler Cell-specific part of the packet scheduler

Id:0900d8058074c31f

Cell load

Cell-specific load control provides load information on cell basis to the cell-specific

packet scheduler upon each scheduling moment. This information includes BTS mea-

surements and estimates made by load control.For 3GPP NBAP interface reporting period is determined specifically for each measure-

ment, that is, Received Total Wide Band Power (PrxTotalReportPeriod), Transmitted

Carrier Power (PtxTotalReportPeriod), Acknowledged PRACH Preambles (RACH-

loadReportPeriod).

The BTS is able to measure and report the received interference power share of the E-

DCH users together with the received total wideband interference power of the cell,

which the HSUPA has configured. The received E-DCH power share (REPS) is included

as the E-DCH Load Factor in the HSUPA Measurement Information of the Radio

Resource Measurement Report which the BTS sends for the E-DCH cell with the

NBAP:Private Message.

Measurement period of the REPS measurement is equal to what one BTS uses for the

received total wide band power PrxTotal measurement.

The CRNC uses the measured REPS in producing the value of the total received non-

EDCH interference power. As REPS contains the scheduled and non-scheduled part of

the E-DCH load, the scheduled E-DCH load is separated as described in WCDMA RAN

RRM Admission Control. If PrxTotal is the value of the RTWP and LEDCH,CELL is the

scheduled transmission part of the REPS, both are received from BTS in the measure-

ment report, then the value PrxNonEDCHST of the received total non-EDPCH sched-

uled transmission interference is achieved from the equation (in the linear notation)

PrxNonEDCHST = (1 – LEDCH,CELL )·PrxTotal .

Power value PrxNonEDCHST represents the received non-EDPCH scheduled trans-mission interference power instead of the PrxTotal , which the RRM of the CRNC uses

for the power- based resource management of the uplink DCHs in the cell which the

HSUPA has configured.

Load control maintains the Uplink DCH own cell load factor LDCH,CELL . It represents the

received power share of all DPCH users in the cell. Uplink own- cell-load factor is used

both in the uplink DCH throughput and interference- power increase estimations.

Separate Uplink NRT DCH own cell load factor LnrtDCH,CELL of all NRT DCH users of the

cell is maintained for the throughput based NRT DCH resource allocation. Both inactive

and active NRT DCHs are included in it.

Own-cell-load factor LactiveDCH,NRT of the active uplink NRT DCH users is produced in

the similar way as LnrtDCH,CELL is done, but only the active NRT DCHs are included in it.

For more information of the uplink load factors, see the Change Δ L in the uplink load

factor and Adjusting uplink noise level (PrxNoise) in "WCDMA RAN RRM Admission

Control" and Architecture of Radio Resource Management of HSUPA in "WCDMA RAN

RRM HSUPA".

Cell-based load information includes the parameters presented in the table below.

Parameter Description

PrxTotal Total received wideband interference power in uplink measured by

BTS.

Table 15 Cell-based load information parameters

















78 DN0495772

Issue 14C


Id:0900d8058074c31f

Cell-specific part of the packet scheduler

Averaged PrxTotal and PtxTotal values are used in the power change estimations cal-

culated by the packet scheduler. Load control provides the averaged value PrxTotal

upon the scheduling moment. For more information on the averaged quantities of

PrxTotal and PtxTotal see Section Power budget for packet scheduling.

Note that when using HSDPA, if there is at least one HS-DSCH MAC-d flow allocated in

the cell, non-HSPA transmitted power (Transmitted carrier power of all codes not used

for HS-PDSCH, HS-SCCH, E-AGCH, E-RGCH or E-HICH transmission) is used instead

of total- transmitted power for downlink channel type selection between FACH and DCH,

DL packet scheduling, overload control and compressed-mode algorithms.

Downlink power estimation algorithm, however, uses PtxTotal even if there are one or

more HS-DSCH MAC-d flows in the cell.

Radio link load

Load control provides periodical information on radio link connection basis to the cell-

specific packet scheduler. The BTS periodically informs the CRNC about the current

radio link conditions using the Radio link measurement reporting procedure (private

NBAP) or Dedicated measurement reporting procedure (3GPP NBAP). The reporting

period is defined with the Radio link measurement reporting period (RLMeasRepPeriod,

private NBAP) BTS configuration parameter or Dedicated measurement reporting

period (DedicatedMeasReportPeriod, 3GPP NBAP).

For 3GPP NBAP interface PtxAverage corresponds with the Transmitted code power

measurement .The radio link based information includes the parameters presented in table below.

PtxTotal Total transmitted power in downlink measured by BTS.

RachLoad Averaged number of received RACH preambles per radio frame during

the reporting period (Note).

PrxNc Total received wideband interference power from non-controllable

users in uplink, calculated by load control.

PtxNc Total transmitted power to non-controllable users in downlink, calcu-

lated by load control.

PrcSc power caused by the semi controllable traffic of real-time users in

uplink direction

PtxSc power caused by the semi controllable traffic of real-time users in

downlink direction

PrxRtInactive Estimated received power of admitted real-time bearers, which are not

active yet (establishment phase is still ongoing).

PtxRtInactive Estimated transmitted power of admitted real-time bearers, which are

not active yet (establishment phase is still ongoing).

LDCH,CELL Uplink DCH own-cell-load factor.

LnrtDCH,CELL Uplink NRT DCH own-cell-load factor.

LactiveDCH,NRT Own-cell-load factor of the active uplink NRT DCH users.

LEDCH,CELL Received E-DCH power share.

PrxNonEDCHST Received non-EDPCH scheduled transmission interference power.


Table 15 Cell-based load information parameters (Cont.)



DN0495772

Issue 14C

79

WCDMA RAN RRM Packet Scheduler Cell-specific part of the packet scheduler

Id:0900d8058074c31f

g The BTS measures the transmitted code power from the pilot bits of the dedicated

physical channel (DPCH). The BTS also reports this value to the RNC. That is why

the packet scheduler has to subtract the effect of the power offset of the dedicated

physical control channel (DPCCH) pilot bits (PO3) from the reported PtxAverage to

get power of the dedicated physical data channel (DPDCH) bits. The power offset of

the pilot bits is defined by an RNC internal constant value.

Prioritisation of PS services

QoS priorities are defined on RNC level by the QoSPriorityMapping RNP parameter thatis read by the UE specific packet scheduler. Furthermore, this parameter provides the

QoS priority value for the cell specific packet scheduler during a capacity request. The

operator specifies priorities for each individual traffic class, traffic handling priority, and

allocation and retention priority combination. For more information see WCDMA RAN

RRM HSDPA.


PtxAverage Average radio link downlink transmission power measured in the

BTS (see the note below).

Table 16 Radio link based information parameters







80 DN0495772

Issue 14C


Id:0900d805806accc0

7.2 Target load level of the cell

Load control and admission control provide radio network planning parameters to the

cell-specific packet scheduler when the RNC is started, the cell is started or the param-

eters are changed by the operator. These parameters are stored in the radio networkconfiguration database. This information includes the parameters presented in the table

below:

Operator is provided with PrxLoadMarginDCH management parameter to define for the

uplink DCH resource allocation the minimum total uplink throughput of the cell to guar-

antee the minimum nominal data rate for the uplink DCH users though there was inter-

ference spiking in the cell. If the uplink DCH traffic level of the cell is low then the source

of the interference is considered to be outside of the cell and the uplink DCH resources

are allocated without any interference estimates. When the own cell throughput exceeds

a particular level, the interference estimations are initiated and the planned interference

target is applied in the uplink DCH resource allocations.

Overestimation of the noise power level of a cell may lead to the situation when too

much uplink DCH traffic is admitted in the cell. Interference thresholds, which are used


PrxTarget Target for total received power in uplink.

PtxTarget Target for total transmitted power in downlink.

PrxOffset Target for total received power can be exceeded by the value

of offset before load has to be decreased.

PtxOffset Target for total transmitted power can be exceeded by the

value of offset before load has to be decreased.Orthogonality The average downlink orthogonality factor of the cell (internal

constant value).

PrxNoise Noise level in the digital receiver of the cell when there is no

load (thermal noise + noise figure).

PrxLoadMarginDCH Interference margin for the minimum UL DCH load. Repre-

sents the minimum total uplink DCH throughput of the cell. The

CRNC is allowed to allocate the uplink DCH resources up to

this throughput limit without considering the received

wideband interference. The value of the corresponding load-

factor threshold is denoted with LminDCH . The parameter is

introduced in the WCDMA RAN RRM Admission Control .

Note that E-DCH streaming is added to DCH load here if it isallocated.

PrxLoadMarginMaxDCH Interference margin for the maximum UL DCH load. Repre-

sents the maximum allowed total uplink DCH throughput of the

cell. The CRNC is allowed to allocate the uplink DCH

resources up to this throughput limit without considering the

received wideband interference. The value of the correspond-

ing load- factor threshold is denoted with LmaxDCH . The param-

eter is introduced in the WCDMA RAN RRM Admission

Control .

Note that E-DCH streaming is added to DCH load here if it is

allocated.

Table 17 Radio network planning parameters





DN0495772

Issue 14C

81


Id:0900d805806accc0

in the uplink DCH resource allocation, are defined in the relation to the noise power level

and therefore may trigger too late. Excess interference is experienced in the own cell

and the adjacent cells. Uplink coverage and network stability may suffer. A cell- level

throughput- based upper limit is introduced – PrxLoadMarginMaxDCH management

parameter - for the uplink DCH traffic against the overestimation in the noise power

level. Limit value is possible to be set with a management parameter.

Note that E-DCH streaming uses non-scheduled transmission if it is allocated. Non-

scheduled transmission is calculated here as part of DCH traffic. The non-scheduled

traffic is controlled by RNC with the same principles described here for DCH traffic.

When using the dynamic sharing of the received interference between the HSPA and

DCH users, if there is at least one E-DCH MAC-d flow established in the cell, the Prx-

NonEDCHST measurement and dynamically adjusted target threshold PrxTargetPS are

applied in the uplink NRT DCH packet scheduling instead of PrxTotal and PrxTarget . For

more information, see Sharing interference between HSPA and NRT DCH users in

"WCDMA RAN RRM HSUPA".Note that when using the HSDPA Dynamic Resource Allocation, if there is at least one

HS-DSCH MAC-d flow allocated in the cell, dynamic target threshold for packet sched-

uling (PtxTargetPS), which is internally adjusted by the RNC, is used instead of PtxTar-

get for downlink channel type selection between FACH and DCH, DL packet scheduling,

overload control and compressed mode algorithms. When using the HSDPA Static

Resource Allocation PtxTargetHSDPA and PtxOffsetHSDPA target levels are used

instead of PtxTarget and PtxOffset .

In case of DL packet scheduling target threshold is also P max – P HSDPA_streaming (instead

of PtxTargetPS), where Pmax is cell maximum tx power and P HSDPA_streaming is power

needed by PS streaming HSDPA users. This is the case when PS streaming services

mapped to HSDPA uses so much power that PtxTargetPS can not go low enough(because of PtxTargetPSMin).





82 DN0495772

Issue 14C


Id:0900d805806accf5

7.3 Queuing of capacity requests

The UE-specific packet scheduler forwards uplink and downlink capacity requests to the

cell-specific packet scheduler of every cell in the active set. There is single queue for

uplink and downlink capacity request messages in the cell-specific packet scheduler.

During anchoring, if the RAN1759: Support for I-HSPA Sharing and Iur Mobility

Enhancements feature is enabled, also the capacity requests received from SRNC over

Iur interface are queued similarly in the cell-specific packet scheduler of DRNC as in

case of cell is controlled by a SRNC.

If the packet scheduler cannot allocate capacity to all the radio bearers requesting it,

unscheduled capacity requests remain in the queue. The number of scheduling periods

that a capacity request message can remain queued is limited. This limit can be sepa-

rately defined for the uplink and downlink with the Maximum uplink capacity request

queuing time (CrQueuingTimeUL) and Maximum downlink capacity request queuing

time (CrQueuingTimeDL) RNC configuration parameters respectively. When the limit is

reached for a certain capacity request, it is permanently removed from the queue. If the

bearer still needs the capacity, a new capacity request is required.

The Maximum uplink capacity request queuing time (CrQueuingTimeUL) and Maximum

downlink capacity request queuing time (CrQueuingTimeDL) parameters are related to

the Uplink traffic volume measurement pending time after trigger (TrafVolPending-

TimeUL) and Downlink traffic volume measurement pending time after trigger (TrafVol-

PendingTimeDL) parameters, which define the time between two consecutive capacity

requests.

When a capacity request arrives to the queue, it is first checked whether a capacity

request for the same non-real time radio bearer already exists in the queue. There are

three types of capacity requests: 'initial request for low bit rate', 'initial request for high

bit rate' and 'upgrade request for high bit rate'. If it turns out that there is already a

capacity request (original capacity request) for the same non-real time radio bearer in

the queue, the packet scheduler handles the new capacity request for the same non-

real time radio bearer as follows:

In the cell-specific packet scheduler of the DRNC the same principles as explained in

the table Handling capacity requests is followed also in case capacity request received

over Iur.

Condition Action

The original capacity request and the type of

the new capacity request are the same type.

The new capacity request is deleted.

If the type of the original capacity request is

'initial request for low bit rate' and the type of

the new capacity request is 'initial request for

high bit rate,

OR

if the type of the original capacity request is

'initial request for high bit rate' and the type of

the new capacity request is 'initial request for

low bit rate'.

The content (type) of the original, queued

capacity request is replaced with the content

(type) of the new capacity request (the position

of the original capacity request in the queueremains the same as before),

AND

delete new capacity request.

Table 18 Handling capacity requests





DN0495772

Issue 14C

83


Id:0900d805806accf5

The packet scheduler arranges the capacity requests for scheduling according to the fol-

lowing criteria:

• QoS priority of capacity request

• the arrival time of the capacity request

Primarily arranging is made according to the QoS priorities and secondary according to

the arrival time. If the arrival time of the capacity request is taken into account, the

capacity requests are handled in the same order as they arrived. Thus, the capacity

request that has been the longest time in the queue is handled first.

Capacity requests for PS streaming RABs trigger channel type selection and after that

they are handled in the same way as new RABs. If the resources are not available,

resources can be taken from NRT RBs. If not enough resources can be freed, an

existing RAB is not released and the reservation of resources is retried when the next

capacity request arrives. If a new PS streaming RAB requested the resources, the RAB

establishment is rejected when the resources are not available.In the cell-specific

packet scheduler of the DRNC, the capacity request for PS Streaming RAB is handledsimilarly.

When the RNC receives a capacity request during an ongoing PS NRT RAB modifica-

tion procedure, the RNC behaves as if the capacity allocation is already ongoing and

another capacity request is received. Such situation occurs when the RAB modification

procedure has started immediately after receiving the RAB assignment request due to

a capacity request, that is the actual RNC/BTS/UE modification procedure is ongoing.



84 DN0495772

Issue 14C


Id:0900d805807501ca

7.4 Channel type selection

In addition to the control plane signalling messages, small non-real time user data

blocks can be transmitted on the common transport channels. The common transport

channels are random access channel (RACH) in the uplink and the forward accesschannel (FACH) in the downlink. In most cases, dedicated/shared transport channel

(DCH/HS-DSCH/E-DCH) is allocated for non-real time radio bearers.

Figure 25 States of bearer allocations

The channel type (dedicated or common) selection for non-real time radio bearer

depends on current status of bearer allocations. Several radio bearers can be assigned

for one UE and they are multiplexed into one radio link on L1. The assigned bearers can

be real-time or non-real time radio bearers. Figure 25 States of bearer allocations illus-

trates the states of bearer allocations. If real-time bearers are assigned to the UE, then

dedicated transport channel (DCH) is always used. If only non-real time bearers are

assigned to the UE, using RACH and FACH channels is also a possibility. RAN has the

possibility , during an RRC connection, to dynamically switch between common and

dedicated transport channels. When the last real-time bearer is released and there are

no active non-real time bearers, dedicated transport channel resources are released

and the UE is moved from the CELL_DCH state to the CELL_FACH state. When there

are only non-real time bearers assigned to a certain UE and data arrives to the RLC

buffers in either the UE or the RNC side, the selection between common and dedicated

transport channels has to be made.

When using the HSDPA, high speed downlink shared channel (HS-DSCH) is applicable

in CELL_DCH state. For more information on HSDPA specific channel type selection

RTbearer setup

NRT bearer setup

RT or NRTbearer setup

RT bearer setup

NRTbearer setup

First NRTbearer setup

First RTbearer setup

RRC connectionestablished

RRC connectionreleased

Only DCH allocation possible

Both RACH/FACHand DCH possible

Last RTbearer released

Last NRTbearer released

Last RTbearer released

Last NRTbearer released

RRC connection(no bearers allocated)

Non-real timebearer(s) allocated

Real time and non-realtime bearers

allocated

Real time bearer(s)allocated















DN0495772

Issue 14C

85


Id:0900d805807501ca

algorithm between HS-DSCH and DCH, see HSDPA channel type selection in WCDMA

RAN RRM HSDPA.

When using the HSUPA, Enhanced dedicated channel (E-DCH) is applicable in

CELL_DCH state. For more information on HSUPA specific channel type selection algo-rithm between E-DCH and DCH, see Channel type switch between DCH and E-DCH in

WCDMA RAN RRM HSDPA.

Uplink

The UE decides which channel type to use in the uplink. The UE makes the decision on

the basis of the current status of bearer allocations, traffic volume measurements per-

formed by MAC and the RLC buffer levels. If the random access channel (RACH) is

selected, the user data to be transmitted is included into one or more RACH bursts.

When dedicated transport channel is selected, the UE requests capacity from RAN by

sending an RRC: MEASUREMENT REPORT message to the RNC. The RNC plays a

part in the uplink channel type selection procedure insofar as it sets the relevant param-

eters for traffic volume measurements and sends them to the UE in an RRC: MEA-

SUREMENT CONTROL message. The traffic volume measurement procedure works

as follows:

The UE supports traffic volume measuring for each non-real time radio bearer, as spec-

ified in the 3GPP RRC protocol specification. The measured quantity is RLC buffer

payload in number of bytes. Both new and retransmitted RLC payload units are included

in the payload measure.

The traffic volume can be reported in two different ways: periodical and event-triggered.

If periodical reporting is used, the UE measures the number of bytes for the transport

stated in the measurement control message and reports the traffic volume at the given

points in time. Event-triggered reporting is performed when a threshold is exceeded.

Only event-triggered traffic volume measurement reporting is used (Reporting event

4A). An event-triggered report when transport channel traffic volume exceeds a thresh-

old shows the principle of event-triggered traffic volume reporting. As shown by the

figure, a report is generated when transport channel traffic volume exceeds an absolute

threshold. Transport channel traffic volume is equal to the sum of buffer occupancies of

radio bearers multiplexed onto a transport channel. In the CELL_FACH state the UE has

one uplink transport channel, that is, RACH.

The traffic volume measurement quantities and reporting quantities which are included

in the report are stated in the RRC: MEASUREMENT CONTROL message. The traffic

volume measurement quantities are:

• RLC buffer payload• Average of RLC buffer payload

• Variance of RLC buffer payload

Of these, only RLC buffer payload is measured. All of the quantities listed above are

optional to include in the measurement report. RLC buffer payload is the only quantity

that is included in the measurement report. In addition to the RLC buffer payload, the

measured results also include the radio bearer identity to indicate which radio bearer

triggered the report.

















86 DN0495772

Issue 14C


Id:0900d805807501ca

Figure 26 Event-triggered report when transport channel traffic volume exceeds a

threshold

Traffic volume measurement triggering could be associated with a time-to-trigger and a

pending time after trigger. The time-to-trigger is used to get time domain hysteresis, that

is, the condition must be fulfilled during the time-to-trigger interval for a report to be sent.

Pending time after trigger is used to limit the number of reports with the same content.

This timer is started in the UE when a measurement report has been triggered. The UE

is then prohibited from sending a new measurement report related to the same traffic

volume event identity during the specified interval, even if the triggering condition is ful-

filled again. Instead the UE waits until the timer has elapsed. If the transport channel

traffic volume is still above the threshold when the timer has expired, the UE sends a

new measurement report, and the timer is restarted. Otherwise the UE waits for a new

triggering.

Figure 27 Pending time after trigger limits the amount of consecutive measurement

reports

The figure above shows that by increasing the pending time after trigger a second trig-

gered event does not result in a measurement report.

Uplink traffic volume measurement reporting criteria includes the following parameters,

which are set by radio network planning:

• Uplink traffic volume measurement low threshold (TrafVolThresholdULLow)

• Uplink traffic volume measurement time to trigger (TrafVolTimeToTriggerUL)

TransportChannel TrafficVolume

Time

TrafVolThresholdULLow

Reportingevent

Reportingevent

Short pending time after trigger


Time


Report 1 Report 2

TrafVolPendingTimeUL

Long pending time after trigger


Time


Report 1 No report

TrafVolPendingTimeUL



DN0495772

Issue 14C

87


Id:0900d805807501ca

• Uplink traffic volume measurement pending time after trigger (TrafVolPending-

TimeUL)

These parameters are sent from the RNC to the UE using a dedicated RRC: MEASURE-

MENT CONTROL message.The packet scheduler performs channel type selection in the CELL_FACH state accord-

ing to the following rules:

Downlink

When the UE is in CELL_DCH state and data arrives to the downlink RLC buffer in the

RNC, dedicated channel is always selected and a downlink capacity request is sent to

the packet scheduler by MAC-d, which is the MAC entity that handles the dedicated

channels of one UE.

When using the HSDPA, high speed downlink shared channel (HS-DSCH) is applicable

in CELL_DCH state. For more information on HSDPA specific channel type selection

algorithm between HS-DSCH and DCH , see Channel type switching in "WCDMA RAN

RRM HSDPA".

When the UE is in CELL_FACH state and data arrives to the downlink RLC buffer in the

RNC, RLC indicates the buffer status to MAC-c, which is the MAC entity that handles

the common channels of one cell. MAC-c selects the channel type on the basis of status

information regarding the RLC buffers of each radio bearer and signalling radio bearer

(SRB). After the channel type selection is performed, MAC-c initiates data transmission

on FACH or, when the dedicated channel is selected, it sends a downlink capacity

request (downlink traffic volume measurement report) to the packet scheduler. The

Downlink traffic volume measurement pending time after trigger (TrafVolPending-

TimeDL)RNC configuration parameter defines the time between two consecutive

capacity requests. If there is no response during the interval specific by this parameter,

a new capacity request is sent to the packet scheduler.

The channel type selection procedure on MAC-c is shown in Figure 28 Channel type

selection on MAC-c. In the procedure the following parameters are needed, which are

set by radio network planning:

• Downlink traffic volume measurement low threshold (TrafVolThresholdDLLow)

• Downlink traffic volume measurement time to trigger (TrafVolTimeToTriggerDL)

• Downlink traffic volume measurement pending time after trigger (TrafVolPending-TimeDL)

Condition Action

Only SRB0, SRB1, or SRB2 has data to send. The packet scheduler does not allocate a ded-

icated signalling channel for the UE, that is,

state transition is not performed.

Only SRB3 or SRB4 has data to send and the

sum load of RLC buffers of SRB3 and SRB4

exceed threshold defined by the Uplink NAS

signalling volume threshold (NASsign-VolThrUL) radio network planning parameter.

State transition to CELL_DCH is performed

and dedicated signalling channel is allocated.

Any of the user plane radio bearers has data to

send.


and dedicated signalling and data channels

are allocated.

Table 19 Rules for channel type selection in the CELL_FACH state, uplink





88 DN0495772

Issue 14C


Id:0900d805807501ca

• Threshold for RACH load (RachLoadThresholdCCH)

• Margin for RACH load (RachLoadMarginCCH)

• Threshold for FACH load (FachLoadThresholdCCH)

• Margin for FACH load (FachLoadMarginCCH)• Threshold for total downlink transmission power (PtxThresholdCCH)

• Margin for total downlink transmission power (PtxMarginCCH)

These parameters are described in detail in WCDMA Radio Network Configuration

Parameters.

Figure 28 Channel type selection on MAC-c

The channel type selection procedure on MAC-c is shown in the figure above. The

decision is based on the following information:

• Buffer status (payload of RLC buffers), indicated by RLCs

• FACH load, measured by MAC-c

• FACH load and total downlink transmitted power in the cell (PtxTotal ), measured by

theBTS

Dedicated channel is selected and a downlink capacity request is sent to the packetscheduler if:

Maximum allowed user data amount on FACH

exceeded

FACH in overload

FACH usage forbiddenby PS

Initiate datatransmission on

FACH

RequestDCH/HS-DSCH

from PS

End

Yes

Yes

Yes

No

No

No

Channel typeselection on MAC-c

http://prm_wcdma_rnw_conf_param.pdf/








DN0495772

Issue 14C

89


Id:0900d805807501ca

1. The sum load of RLC buffers of each radio bearer, SRB3 and SRB4 is greater than

the value set by Downlink traffic volume measurement low threshold (Traf-

VolThresholdDLLow)

2. FACH is in overload3. FACH usage is forbidden by the packet scheduler

In the case of HSDPA, high speed downlink shared channel (HS-DSCH) is applicable in

CELL_DCH state. For more information on HSDPA specific channel type selection algo-

rithm between HS-DSCH and DCH , see Channel type switching in "WCDMA RAN RRM

HSDPA".

Otherwise data transmission is initiated on FACH.

FACH is overloaded when the FACH load exceeds Threshold for FACH load for

downlink channel type selection (FachLoadThresholdCCH). FACH can be used again

when the FACH load has fallen below the threshold defined by Margin for FACH load

for downlink channel type selection (FachLoadMarginCCH). FACH load measurements

are performed by MAC-c.

FACH usage is forbidden by the packet scheduler when the RACH load exceeds

Threshold for RACH load for downlink channel type selection (RachLoadThreshold-

CCH) or when PtxTotal exceeds Threshold for total downlink transmission power for

downlink channel type selection (PtxThresholdCCH). When one or both of the condi-

tions are fulfilled, the packet scheduler indicates to MAC-c that the use of FACH is for-

bidden. FACH can be used again when the RACH load and PtxTotal fall below the

thresholds set by Margin for RACH load for downlink channel type selection (RachLoad-

MarginCCH) and Margin for total downlink transmission power for downlink channel

type selection (PtxMarginCCH). The thresholds and margins used in downlink channel

type selection are illustrated in Figure 29 Thresholds and margins in downlink channel

type selection.

Figure 29 Thresholds and margins in downlink channel type selection

The reason why the total transmission power is checked is that, from the interference

point of view, it is less efficient to use the FACH (no closed loop power control) than a

dedicated channel. From the signalling point of view the FACH is more efficient than a

dedicated channel, because it does not require L3 signalling. By using the FACH when

the cell is not heavily loaded it is possible to decrease the total signalling load of the

RNC.

RACH load /FACH load /PtxTotal

time

threshold

margin

FACH usageis forbidden

FACH usageis allowed





90 DN0495772

Issue 14C


Id:0900d805807501ca

The packet scheduler performs channel type selection in the CELL_FACH state accord-

ing to the following rules:

Condition ActionOnly SRB3 or SRB4 has data to send and the

sum load of RLC buffers of SRB3 and SRB4

exceed the threshold defined by the Downlink

NAS signalling volume threshold (NASsign-

VolThrDL) radio network planning parameter.


and dedicated signalling channel is allocated.

Any of the user plane radio bearers has data to

send.


and dedicated signalling and data channels

are allocated.

Table 20 Rules for channel type selection in the CELL_FACH state, downlink



DN0495772

Issue 14C

91


Id:0900d80580750246

7.5 Power budget for packet scheduling

The principle of load distribution in a WCDMA cell is illustrated in Figure 30 Load distri-

bution in a WCDMA cell. The basic idea is that radio network planning defines the load

targets for cell load for the uplink (PrxTarget ) and the downlink (PtxTarget ). Thesetargets define the optimal operating points in terms of system load and the current radio

resources of the system. The Uplink total received interference power (PrxTotal) and

Downlink total transmitted power (PtxTotal) are values measured by the BTS, and

should stay below the target values. The load can momentarily exceed these targets

because of changes to the interference and the propagation conditions. If the system

load does exceed the load threshold in uplink (PrxTarget + PrxOffset ) or downlink (Ptx-

Target + PtxOffset ), an overload situation is at hand and load control takes actions to

return the load below the threshold in question.

Note that when using the HSDPA dynamic resource allocation, if there is at least one

HS-DSCH MAC-d flow allocated in the cell, non-HSPA transmitted power (Transmitted

carrier power of all codes not used for HS-PDSCH, HS-SCCH,E-AGCH, E-RGCH or E-HICH transmission) is used instead of total transmitted power. Dynamic target threshold

for packet scheduling (PtxTargetPS), which is internally adjusted by the RNC, is used

instead of PtxTarget . When using the HSDPA Static Resource Allocation PtxTargetHS-

DPA and PtxOffsetHSDPA target levels are used instead of PtxTarget and PtxOffset .

Figure 30 Load distribution in a WCDMA cell

The packet scheduler can control the semi-controllable load and controllable load.

Therefore, the controllable power includes semi-controllable power in the figure below.

However, the semi-controllable load can be only released in overload situation because

downgrading from guaranteed bit rate is not possible. The specification of QoS priorities

for PS RBs guarantees that in overload situations needed power is taken first from the

controllable part and after that from the semi-controllable part.

Uplink

In the uplink direction the current total received interference power of a cell (PrxTotal )can be expressed as the sum of the non-controllable power (PrxNc ), the semi-control-

power

time

non-controllable load

controllable load

PrxNc / PtxNc

PrxTotal / PtxTotal

PrxNrt / PtxNrt

PrxTarget / PtxTargetPrxOffset / PtxOffset







92 DN0495772

Issue 14C


Id:0900d80580750246

lable power (PrxSc ) of PS streaming services and the controllable power, which is

caused by non-real time traffic (PrxNrt ).

Figure 31 Total received interference power of a cell

The non-controllable power consists of the powers of real-time users excluding PS

streaming, other-cell users and noise.

The packet scheduler has to calculate the total allowed power for packet scheduling pur-

poses. The total allowed power for all purposes in the uplink direction is PrxTarget ,

which has to be shared between real-time and non-real time bearers. The allowed power

for packet scheduling in the uplink direction can be calculated as:

Figure 32 Allowed power for uplink packet scheduling

where

Load control provides the averaged value for PrxTotal upon the scheduling moment t .

Figure 33 Averaged received wideband interference power in uplink

where P rxTotaln-(N_2),..., P rxTotaln are the samples of the estimated received wide band

power PrxTotal at the previous periodical scheduling moments t n-(N-2),..., t n which load

control has drawn as described in WCDMA RAN RRM Admission Control. The averaged

value for PrxTotal is produced at the moment t > t n of the scheduling from the N samples

of the PrxTotal (mW). N equals to the Load measurement averaging window size for

packet scheduling (PSAveragingWindowSize).

P rxTotal is the sample of PrxTotal drawn at the moment t when the PS resource request

is scheduled. Scheduling moment t can represent one of the following events:

• The immediate scheduling moment, that is the moment the PS resource request is

received.

• The periodic scheduling moment, that is the moment t n+1 when the queued PS

resource request is scheduled. In addition, moments of the periodic scheduling are

applied in the over load control.

Variable Description

PrxTarget is a radio network planning parameter.

PrxTotal the averaged value for PrxTotal upon the scheduling moment t is

provided by load control.

PrxRtInactive is provided by load control and is the estimated received power of

admitted real-time bearers, which are not active yet because the estab-

lishment phase is still ongoing.

PrxNrtInactive is the estimation of the received power that inactive bearers would

cause when they are active. It has to be calculated by the packet

scheduler.

Table 21 Variables for allowed power for uplink packet scheduling

Prx,total = Pr x,nc + Prx,sc + Prx,nrt

Prx,allowed

= MAX(Pr x,target- P

r x,Total- P

rx,nrt,inactive- P

rx,rt,inactive, 0)

Prx,Total

=N

j=n-(N-2)

Prx,Total j

+ Prx,Total*

1n





DN0495772

Issue 14C

93


Id:0900d80580750246

For more information see Section Cell- and radio link-specific load status information. If

HSUPA is configured in the cell, the estimated and averaged interference power

quantity PrxNonEDCHST is used instead of PrxTotal . When the averaged value of the

estimated interference power PrxNonEDCHST is produced for DCH overload control

purposes, the averaging window size N is defined with the management parameter Win-

LCHSUPA instead of the parameter PSAveragingWindowSize.

PSAveragingWindowSize management parameter also defines the size of the averag-

ing window for the received non-EDPCH scheduled transmission interference power

PrxNonEDCHST in the HSUPA cell, when it is averaged for the uplink NRT DCH sched-

uling.

When the PrxNonEDCHST is averaged for the needs of the uplink NRT DCH overload

control in the RNC, Non-EDPCH interference averaging window size for LC (WinLCH-

SUPA) management parameter defines then the averaging window size N .

In the case of the dynamic sharing of the received interference between the HSPA and

DCH users, if there is at least one E-DCH MAC-d flow established in the cell, the Prx-NonEDCHST measurement and dynamically adjusted target threshold PrxTargetPS are

applied in the uplink NRT DCH packet scheduling instead of PrxTotal and PrxTarget . For

more information, see Section Sharing interference between HSPA and NRT DCH

users in WCDMA RAN RRM HSUPA.

Figure 34 Example of inactive NRT, one NRT RB shows examples of PrxNrtInactive

determination.

Figure 34 Example of inactive NRT, one NRT RB

Figure 34 Example of inactive NRT, one NRT RB shows an example of inactivity, when

there is one non-real time radio bearer allocated to the UE. There are two kinds of

inactive periods for non-real time radio bearer, which are taken into account in the esti-

mation of PrxNrtInactive:

• the time elapsed between the inactivity indication that triggered the inactivity timer

and the activity indication before inactivity timer expiration. Both of these indications

are received from MAC layer, and

• the time elapsed between the inactivity indication and inactivity timer expiration.

The operator can define bit rate-specific values for the inactivity timers for non-real timeradio bearers in the uplink and downlink.

load

Includes to thePrxTotal

measurement

Includes to thePrxNrtlnactive

estimation

Inactivityindicationfrom MAC

Activityindication

from MAC,timer stopped

Inactivity timer expires, RLis released

Inactivityindicationfrom MAC

Inactivitytimer

running

Inactivitytimer

running

time







94 DN0495772

Issue 14C


Id:0900d80580750246

PrxNrtInactive can be estimated using the uplink power estimation formula in estimation

of power change. ∆L in the formula is calculated as described in the definition of the

change ∆L in the uplink load factor.

In the following, two throughput- based quantities are produced for the uplink DCHscheduling.

Minimum available uplink load Lallowed_minDCH in the uplink DCH scheduling is

Lallowed_minDCH = MAX(LminDCH - LDCH,CELL - LncEDCH,CELL - LEDCH_Streaming,CELL, 0)

where

LDCH,CELL is the own-cell-load factor of the earlier DCH users as specified in Section Cell-

and radio link–specific load status information.

LEDCH_Streaming,CELL is the own cell load factor of the earlier E-DCH streaming users as

specified in the Radio Resource Management of HSUPA.

LminDCH is the minimum- uplink load threshold for the DCH allocation as specified in

Section Target load level of the cell.

LncEDCH,CELL is the own cell load factor of the non-controllable E-DCH load in the cell.

Quantity Lallowed_minDCH defines the uplink throughput, which is available in the uplink

DCH scheduling regardless of the value of the interference domain quantity P rx_allowed .

Maximum available UL load Lallowed_maxDCH in the UL DCH scheduling is:

Lallowed_maxDCH = MAX(LmaxDCH - LDCH,CELL - LncEDCH,CELL - LEDCH_Streaming,CELL, 0)

where

LDCH,CELL is the own-cell-load factor of the earlier DCH users as specified in Section Cell-

and radio link–specific load status information.

LEDCH_Streaming,CELL is the own cell load factor of the earlier E-DCH streaming users asspecified in the WCDMA RAN RRM of HSUPA.

LmaxDCH is the maximum uplink load threshold for the DCH allocation as specified in

Section Target load level of the cell.


Quantity Lallowed_maxDCH defines the maximum- uplink total DCH throughput, which is

allowed in the uplink DCH scheduling.

Downlink

In the downlink direction the current total transmitted power of a cell (PtxTotal ) can be

expressed as the sum of the non-controllable power (PtxNc ), the power caused by the

semi-controllable traffic of real-time users (PtxSCRT ) and the controllable power, which

is caused by non-real time traffic (PtxNrt ).

Figure 35 Total transmitted power

The controllable and semi-controllable power is used for non-real time and PS stream-

ing users on best effort basis by the packet scheduler. The power available for best effort

traffic is the load target subtracted by the non-controllable power.

The packet scheduler has to calculate the total allowed power for packet scheduling pur-

poses. The total allowed power for all purposes in the downlink direction is PtxTarget ,

which has to be shared between real-time and non-real time bearers. The allowed power

for downlink packet scheduling can be calculated as

Ptx,total = Ptx,nc + Ptx,scrt + Ptx,nrt







DN0495772

Issue 14C

95


Id:0900d80580750246

Figure 36 Allowed power for downlink packet scheduling

where

Load control provides the averaged value for PtxTotal upon the scheduling moment t .

Figure 37 Averaged transmitted carrier power in downlink

where P txTotaln-(N_2) , ..., P txTotaln are the samples of estimated transmitted carrier power

PtxTotal at the previous periodical scheduling moments t n-(N-2),..., t n which load control

has drawn as described in WCDMA RAN RRM Admission Control. The averaged value

for PtxTotal is produced at the moment t > t n of the scheduling from the N samples of PtxTotal (mW). N equals to the Load measurement averaging window size for packet

scheduling (PSAveragingWindowSize).

P txTotal is the sample of PtxTotal drawn at the moment t when the PS NRT DCH resource

request is scheduled.

Note that when using the HSDPA Dynamic Resource Allocation, if there is at least one

HS-DSCH MAC-d flow allocated in the cell, non-HSPA transmitted power (Transmitted

carrier power of all codes not used for HS-PDSCH, HS-SCCH,E-AGCH, E-RGCH or E-

HICH transmission) is used instead of the averaged total transmitted power. Dynamic

target threshold for packet scheduling (PtxTargetPS), which is internally adjusted by the

RNC, is used instead PtxTarget . When using the of HSDPA Static Resource Allocation

PtxTargetHSDPA and PtxOffsetHSDPA target levels are used instead of PtxTarget and

PtxOffset

Upon the scheduling moment t , the power estimation for the DCHs of the radio link RL

depends on the actions described in the following.

• RL(U): Power estimation is based on the establishment or upgrade of a downlink

NRT DCH. The power change ∆P tx,RL is positive:


PtxTarget is a radio network planning parameter.

PtxTotal the averaged value PtxTotal upon the scheduling moment t is provided

by load control.

PtxRtInactive is provided by load control and is the estimated transmitted power of

admitted real-time bearers, which are not active yet because the estab-

lishment phase is still ongoing.

PtxNrtInactive is the estimation of transmitted power that inactive bearers would cause

when they are active.

Table 22 Variables for allowed power for downlink packet scheduling

PtxAllowed = PtxTarget - PtxTotal - Ptx_nrt_inactive - Ptx_rt_inactive

PtxTotal

=N

j=n-(N-2)

PtxTotal j

+ PtxTotal*

1n





96 DN0495772

Issue 14C


Id:0900d80580750246

Figure 38 RL(U): Power estimation due to establishment or upgrade of a DL NRT

DCH

Old(CCTrCH) is the original set of all DCHs of the CCTrCH at the moment t .

U(CCTrCH) is the configuration of the CCTrCH including all earlier non-modified

DCHs, new scheduled NRT DCHs and the NRT DCHs upgraded due to the sched-

uling.

• RL(D): Power estimation is based on the release or downgrade of a downlink NRT

DCH, for example triggered by the priority based scheduling. The power change

∆P tx,RL is negative:

Figure 39 RL(D): Power estimation due to release or downgrade of a downlink

NRT DCH

Old(CCTrCH) is the original configuration of all DCHs of the CCTrCH at the moment

t . D(CCTrCH) is the DCH set of the CCTrCH which includes the NRT DCHs released

or downgraded due to the scheduling.

• RL(RN): Power estimation is based on the establishment or upgrade of a downlink

NRT DCH at a stage of the scheduling when the allocated DCH is still inactive or the

RRC entity has not informed yet the DCH modification procedure to be completed.

The power change∆

P tx,RL represents the P txNrtInactive power and is positive:

Figure 40 RL(RN): Power estimation at an early stage of the establishment or

upgrade of a DL NRT DCH


RN(CCTrCH) is the DCH set of the CCTrCH which includes the NRT DCHs sched-

uled earlier and the NRT DCHs upgraded due to the earlier scheduling but the new

configuration is not yet active at the scheduling moment t .

• RL(RT): Power estimation is based on the establishment or upgrade of a downlinkRT DCH at a stage of the scheduling when the allocated DCH is still inactive or the

RRC entity has not informed yet the DCH modification procedure to be completed.

The power change ∆P tx,RL represents the P txRtInactive power and is positive:

Figure 41 RL(RT): Power estimation at an early stage of the establishment or

upgrade of a DL RT DCH


RT(CCTrCH) is the DCH set of the CCTrCH, which includes the RT DCHs that were

Ptx,RL(U)

=DCH U(CCTrCH)

DCHRDCH

DCH OLD(CCTrCH)

DCHRDCH

Ptx,RL(D)

= DCH D(CCTrCH)

DCHR

DCH

DCH OLD(CCTrCH)

DCHR

DCH

Ptx,RL(RN)

=DCH RN(CCTrCH)

DCHR

DCH

DCH OLD(CCTrCH)

DCHR

DCH

Ptx,RL(RT)

=DCH RT(CCTrCH)

DCHR

DCH

DCH OLD(CCTrCH)

DCHR

DCH



DN0495772

Issue 14C

97


Id:0900d80580750246

established earlier but the new configuration is not yet active at the scheduling

moment t .

• RL(RI): Power estimation is based on the inactivity indication received for a downlink

NRT DCH. The power change ∆P tx,RL represents the P txNrtInactive and is positive:

Figure 42 RL(RI): Power estimation due to the inactivity indication received for a

DL NRT DCH


RI(CCTrCH) is the DCH set of the CCTrCH, which includes the NRT DCHs of the

original configuration, which are inactive at the scheduling moment t .

R DCH is the maximum downlink bit rate of a DCH and ρ DCH is the planned Eb/No of the

DCH in the equations introduced above.

Scheduling moment t can represent one of the following events:

• The immediate scheduling moment, that is the moment the PS resource request is

received.

• The periodic scheduling moment, that is the moment t n+1 when the queued PS

resource request is scheduled. In addition, moments of the periodic scheduling are

applied in the over load control.

For more information see Section Cell- and radio link-specific load status information.

Ptx,RL(RI) =DCH RI(CCTrCH)

DCHR

DCH

DCH OLD(CCTrCH)

DCHR

DCH



98 DN0495772

Issue 14C


Id:0900d8058074c368

7.6 Bit rate allocation method

There are two traditional approaches to bit rate allocation: the first is to allocate low bit

rates to the requesting bearers, which makes the allocations longer, and the second is

to allocate high bit rates for the requesting bearers, which makes the allocations shorter.

The method, which is specified here, is a compromise between these two methods. It is

based on the so-called minimum allowed bit rate. Initial bit rate in uplink (InitialBitRa-

teUL) and Initial bit rate in downlink (InitialBitRateDL) are cell-specific configuration

parameters that define the minimum transport format set that can be allocated to the

requesting bearer in the uplink and the downlink.

The bit rate allocation method described in this chapter is not applicable to HS-DSCH.

It is applicable to the HSDPA related UL return channel (DCH) with exceptions see Cell-

specific resource handling in WCDMA RAN RRM HSDPA.

The BitRateSetPSNRT RNC configuration parameter defines the used bit rate set and

the set also defines allowed bit rates. If the bit rate is not allowed, the next lower allowed

bit rate is used.

The basic idea of the proposed packet scheduling method is:

• When dedicated channel is not allocated for non-real time radio bearer and the

packet scheduler receives an uplink capacity request where low data amount is indi-

cated, it allocates low uplink bit rate and low downlink bit rate.


packet scheduler receives a downlink capacity request where low data amount is

indicated, it allocates low uplink bit rate and low downlink bit rate.


packet scheduler receives an uplink capacity request where high data amount is

indicated, it allocates highest possible uplink bit rate and low downlink bit rate.• When dedicated channel is not allocated for non-real time radio bearer and the

packet scheduler receives a downlink capacity request where high data amount is

indicated, it allocates low uplink bit rate and highest possible downlink bit rate.

• When low bit rate dedicated channel is allocated for non-real time radio bearer for a

certain direction and the packet scheduler receives a capacity request of that certain

direction and high data amount is indicated, it allocates highest possible bit rate for

that direction, that is, upgrades the bit rate.

• When PS streaming services are allocated, the packet scheduler allocates only ded-

icated channels with the same guaranteed bit rate or the next higher supported ded-

icated channel that fulfills requirements of the guaranteed bit rate.

Low uplink bit rate and low downlink bit rate are set by radio network planning parame-

ters. The Uplink initial bit rate (InitialBitRateUL) and Downlink initial bit rate (InitialBitRat-

eDL) parameters define low uplink bit rate and low downlink bit rate respectively.

When the UE is in soft handover, the smallest parameter values of the cell-based Uplink

initial bit rate (InitialBitRateUL) and Downlink initial bit rate (InitialBitRateDL) radio

network planning parameters are used.

When Maximum bit rate (uplink or downlink), which is received in RAB attributes (QoS

parameters) is lower than Minimum allowed bit rate in scheduling (Initial bit rate in uplink

(InitialBitRateUL) or Initial bit rate in downlink (InitialBitRateDL)), Maximum bit rate is

used as a new Minimum allowed bit rate in scheduling for this particular RAB.

The reason to allocate small initial uplink bit rate and upgrade the bit rate later if needed,is that if only small requests and acknowledgements are sent in uplink, the bit rate does















DN0495772

Issue 14C

99


Id:0900d8058074c368

not need to be that high. If a greater amount of data is to be transmitted, the bit rate is

upgraded.

It is probable that high bit rate allocation is not needed in most cases, because the

packet data traffic model for several applications is of the so-called 'request-response'type. This means that the UE acting as a client sends small requests and the server in

the network replies with higher data amount. However, it has to be possible to upgrade

the uplink bit rate, because there are also applications that need to transmit higher

amounts of data in the uplink. File upload to server (FTP) or E-mail sending with attach-

ment (SMTP) are examples of such applications.

Figure 43 Example of bit rate allocation method illustrates how the proposed bit rate allo-

cation method works when an initial high bit rate or a bit rate upgrade is requested, that

is, the types of capacity requests are either 'initial request for high bit rate' or 'upgrade

request for high bit rate'.

Figure 43 Example of bit rate allocation method

In this particular example, there are five capacity requests, and no bit rate is allocated

to the fifth request even if there was room for a 16 kbit/s dedicated channel, for example.

This decision is based on the assumption that the fifth capacity request within this

scheduling period gets an allocation during the next scheduling period with high proba-

bility.

Expression LmaxDCH OR (PrxTarget AND LminDCH ) represents the uplink DCH schedulingtargets both in the power and throughput domains. Basic conditions for the uplink NRT

DCH scheduling are:

Figure 44 Throughput and interference targets for UL DCH scheduling

where Δ L represents the scheduled new load. See Section Power budget for packet

scheduling.


128 (1)

LmaxDCH OR (PrxTarget AND LminDCH)

64 (1)

64 (2)

64 (1)

xamp e: Initial peak bit rate is 32 kbit/s

Allowed peak rates are32, 64, 128, 256, 320, 384 kbit/s

32 (2)

32 (3)

32 (1)32 (2)

32 (3)

32 (4)

32 (1)

32 (2)

32 (3)

32 (4)

Order of capacity request in queue is shown in brackets (1 = best)

Allocation if 1 DCH

requested

Allocation if 2 DCHs

requested


requested


requested


requested

Availablecapacity for scheduling

No allocation for this bearer,CR remainsin a queue

32 (5)

OR

LDCH,CELL+ L

ncEDCH,CELL+ L

EDCH_Streaming,CELL + L < LminDCH

PrxTotal + PrxTotal

< Prx_target

LDCH,CELL

+ LncEDCH,CELL

+ LEDCH_Streaming,CELL

+ L < LmaxDCH







100 DN0495772

Issue 14C


Id:0900d8058074c368

The same figure is valid also for the downlink DCH scheduling with the exceptions that

the power threshold PrxTarget is replaced with the PtxTarget and the throughput

domain thresholds are not used at all, that is, the expression 'LmaxDCH OR (PrxTarget

AND LminDCH )' is replaced with the expression 'PtxTarget '.

The DCH bit rate allocation algorithm includes load increase, load decrease and priority

scheduling algorithms, which are the same in both uplink and downlink directions. The

bit rate allocation algorithm in general level is presented in Figure 45 Packet scheduler

bit rate allocation algorithm in DL for the downlink DCH scheduling.

Figure 45 Packet scheduler bit rate allocation algorithm in DL

Bit rate allocation algorithm is presented in the general level in Figure 46 Packet sched-

uler bit rate allocation algorithm in UL for the uplink DCH scheduling.

PtxTotal < PtxTargetYes

Calculate PtxAllowed

Bit rate allocationalgorithm in DL

PtxTotal <PtxTarget + PtxOffset

Decrease loadingIncrease loading

No

No

Yes

Allocate bit rates

Priorityscheduling

end



DN0495772

Issue 14C

101


Id:0900d8058074c368

Figure 46 Packet scheduler bit rate allocation algorithm in UL

Quantities PrxAllowed, Lallowed_minDCH and Lallowed_maxDCH are introduced in the Chapter

Power budget for packet scheduling

The load increase algorithm is presented in the figure below. Examples of its operation

in relation to Example of bit rate allocation method are shown in figures Figure

51 Example of load increase algorithm, 1 capacity request in queue - Figure 55 Example

of load increase algorithm, 5 capacity requests in queue. In those figures, the initial bit

rate 128 kbit/s is assumed.

Bit rate allocation algorithm in UL

"Conditionsfor priority based

scheduling"

Calculate PrxAllowed,

Lallowed_minDCH and Lallowed_maxDCH

Lallowed_minDCH > L

Priority scheduling

PrxAllowed > PrxTotal

Allocate bit rates

Decrease loadingIncrease loading

end

Yes No

Yes

Yes

No

No

Yes

No

Lallowed_maxDCH> L



102 DN0495772

Issue 14C


Id:0900d8058074c368

Figure 47 Load increase algorithm

Expression LmaxDCH OR (PrxTarget AND LminDCH ) in Figure 47 Load increase algorithm

is denoting the condition:

Figure 48 Uplink condition for the estimated new load

Any NRT RABavailable which

DCH possible todowngrade or

release

Yes

Bit rate = InitialBitRate

Increaseloading

No

end

Start from CR # 1

Yes

Yes

No

Any CRs in queue

Estimate:PrxTotal+PrxTotalChange

LCell + L

[LmaxDCH or (PrxTarget AND L minDCH)]OR

DeltaPrxMaxUp

More CRs inqueue

Higher allowed bit

rates

Move to nexthigher bit rate

Move to nextCR in queue

No

No

No

Yes

Yes

PrxTotalChangeof scheduled

DCHs = 0

Estimate needed and availableUL interference capacity.

Downgrade bit rate or releaseexisting NRT DCH(s).

OR

[Prx_allowed (PrxTotal_new

) = 0] AND [ Lallowed_minDCH

(LCELL

+ L) = 0]

Lallowed_maxDCH

(LCELL

+ L) = 0



DN0495772

Issue 14C

103


Id:0900d8058074c368

Corresponding condition for the downlink is:

Figure 49 Downlink condition for the estimated new load. Symbols Lallowed_maxDCH,

Lallowed_minDCH, Prx_allowed and Ptx_allowed refer to the capacity conditions of

the chapter Power budget for packet scheduling

PrxTotalNew, PtxTotalNew and LCELL + Δ L are calculated using the following formulas:

Figure 50 Estimation of total received power after allocation

PrxTotalChange is calculated using the formula Uplink power change estimation. Ptx-

TotalChange is calculated using the formula Downlink power change estimation.

Quantity Δ L represents the increase in the uplink own cell DCH load factor.


Additional limiting condition for the scheduling in uplink direction is that the estimated

increase in PrxTotal shall not exceed the threshold value ΔPrxTotal Max , defined with the

management parameter DeltaPrxMaxUp:

PrxTotalChange < Δ PrxTotal Max

Condition is checked regardless of the value of load factor LCELL + Δ L.

Corresponding limitation for the downlink scheduling is that the estimated increase in

the PtxTotal shall not exceed the threshold value Δ PtxTotal Max , defined with the man-

agement parameter DeltaPtxMaxUp:

PtxTotalChange < Δ PtxTotal Max .

PrxNrtNew and PtxNrtNew are calculated using the formulas Estimated total controlla-

ble power with the current bit rates in the algorithm loop.

The following five figures illustrate the uplink load-increasing algorithm.

Figure 51 Example of load increase algorithm, 1 capacity request in queue

Figure 52 Example of load increase algorithm, 2 capacity requests in queue

Ptx_allowed

(PtxTotal_new

) = 0

PrxTotalNew

= PrxTotal

+ PrxTotalChange

LCELL

+ L = LDCH,CELL

+ LncEDCH,CELL

+ LEDCH_Streaming,CELL

+ L

PtxTotalNew

= PtxTotal

+ PtxTotalChange

No higher bit rateavailable, allocationaccording to step 3

128 (1)256 (1)

384 (1)

Step 3Step 2Step 1

max rx arget m n

256 (1)

128 (2)

128 (1)

128 (2)

Target exceeded,allocation accordingto step 4

128 (1)

Step 3Step 2Step 1


384 (1)256 (1)

256 (2)

256 (2)

Step 4 Step 5



104 DN0495772

Issue 14C


Id:0900d8058074c368




BTS capabilities also have an effect on the bit rate allocation insofar as it can be a

limiting factor.

The priority based scheduling algorithm used in marginal load area is presented in

Figure 56 Priority scheduling algorithm in marginal load area. PS ensures that total inter-

ference load is not increased because of swapping of the interference capacity.

The priority based scheduling algorithm is presented in Section Enhanced priority based

scheduling.

128 (1)

128 (2)

128 (1)

Step 3Step 2Step 1


Step 4 Step 5

128 (3)

128 (1)

128 (2)256 (1)

128 (3)

128 (2)

256 (1)

256 (2)

128 (3) Target exceeded,allocation accordingto step 4

128 (1)

128 (2)

128 (1)

Step 3Step 2Step 1

max rx arget m n

Step 4 Step 5

128 (3)

128 (1)

128 (2)

256 (1)

128 (3)

128 (2)

128 (4)

128 (3)

128 (1)

128 (2)

128 (4)

Target exceeded,allocation accordingto step 4

128 (1)

128 (2)

128 (1)

Step 3Step 2Step 1

max rx arget m n

Step 4 Step 5

128 (3)

128 (1)

128 (2)

128 (3)

128 (1)

128 (2)

128 (4)

128 (3)

128 (1)

128 (2)

128 (4)

128 (5)Target exceeded,allocation accordingto step 4, no allocationto CR #5



DN0495772

Issue 14C

105


Id:0900d8058074c368

Figure 56 Priority scheduling algorithm in marginal load area

gThe total supported DCH user bit rate of all DCHs for one UE amounts to AMR, 384

kbit/s, and signaling link 3.4 kbit/s in both uplink and downlink directions.

In the DCH/HS-DSCH configuration, the total supported DCH user bit rate of all

DCHs for one UE amounts to AMR, 384 kbit/s, and signaling link 3.4 kbit/s in the

uplink direction. Bit rate on the HSDPA UL DCH return channel with AMR can be

limited to 64 kbps (see WCDMA RAN RRM HSDPA).

In downlink packet scheduling the downlink power availability is also checked for each

UE. The packet scheduler allocates the highest possible bit rate.

• When the transmission power for the initial radio link (P tx ) is calculated according to

the formula initial power estimation at radio link setup, it is checked that P tx for initial

radio link does not exceed P tx,max -2 dB.

• When the change of transmission power for reconfigured radio link (∆Ptx ) is calcu-

lated according to the formula Power estimation at radio link reconfiguration (DCH

allocated to NRT RB), it is checked that the new transmission power

(P tx_average+∆Pt x ) does not exceed P tx,max -2 dB.

This 2 dB is subtracted from P tx,max because of dynamic link optimisation feature.

The offset, defined by the Power offset for dynamic link optimisation (DLOptimisation-

PwrOffset)management parameter, is subtracted from Ptx,max because of the Dynamic

link optimisation for NRT traffic coverage feature.

In downlink packet scheduling the checking of the DL spreading code availability is also

performed for each UE. If there is no suitable spreading code available, the bit rate is

not allocated for the UE. For more information on the calculation for an appropriatespreading factor for the different bit rates and service multiplexing options, see Section

Priority scheduling

Any NRT RABavailable which

DCH possible todowngrade or

release

Estimate needed and

available UL/DL interferencecapacity. Downgrade bit rate

or release existing NRTDCH(s). Ensure that total

interference is not increased.

end

YES NO






106 DN0495772

Issue 14C


Id:0900d8058074c368

Rate matching on dedicated transport channels in WCDMA RAN RRM Admission

Control. For more information on the downlink spreading code allocation algorithm, see

Section Allocation of spreading and scrambling codes in WCDMA RAN RRM Admission

Control.

Existing NRT DCH allocations are not modified when the NRT DCH is to be allocated

for the other NRT RAB of the same UE. This is valid also when the NRT DCH allocation

faces congestion. The same rule applies for the NRT DCH upgrade.













DN0495772

Issue 14C

107


Id:0900d8058074d1b1

7.7 Estimation of power change

To be able to calculate a power estimate, the packet scheduler must be able to calculate

a power of each radio bearer. This must be done for

• recently granted radio bearers

• continuing radio bearers, for which the bit rate either stay the same or changes

• ending radio bearers.

The combination of these individual power changes is used to calculate the total load

change.

7.7.1 Uplink power estimation

When the packet scheduler estimates the uplink load change in the cell caused by all

non-real time radio bearers, equation Uplink power increase estimation (PIE) and Uplink

power decrease estimation (PDE)are used. The load factor change

ΔL is calculated asa sum of all changes of individual bearer load factors.

Definition of the change L in the uplink load factor

The following formula is valid for the change in the uplink load factor of the RRC con-

nection when one or more uplink NRT DCHs are modified:

Figure 57 Load factor change


W is the chip rate (3840 kbps).

ρ new,DCH Are the planned E b /N 0 values of the DCH

for the new data rate. ρ old,DCH

R new,DCH Represents the new maximum data rate of

the NRT DCH; if it equals to 0 kbps the

whole term of the new load factor shall be

considered to equal 0: DCH is released.

R old,DCH Represents the earlier maximum data rate

of the NRT DCH; if it equals to 0 kbps thewhole term of the earlier load factor shall

be considered to equal 0: DCH is estab-

lished

ν new,DCH Represents the activity factor of the DCH,

defined with the management parameter

RRMULDCHActivityFactor .

ν old,DCH Represents the activity factor of the DCH,

defined with the management parameter

RRMULDCHActivityFactor

Table 23 Variables for load factor change

1-

1+ WR

new,DCHnew,DCH

1

1+W

Rold,DCH

LRL

=NRT(DCH) CCTrCH

new,DCH old,DCHold,DCH



108 DN0495772

Issue 14C


Id:0900d8058074d1b1

At the scheduling moment t , there are radio link sets in the cell whose radio links can be

objects of different kind of actions:

• Link set RL(U): Power estimation is based on the establishment or upgrade of an

uplink NRT DCH. The change Δ LRL in the load factor is positive.• Link set RL(D): Power estimation is based on the release or downgrade of an uplink

NRT DCH, trigger can be, for instance, the priority based scheduling. The change

Δ LRL in the load factor is negative.

• Link set RL(RN): Power estimation is based on the establishment or upgrade of an

uplink NRT DCH done at an earlier scheduling moment but the RRC entity has not

informed yet the procedure to be completed. The change Δ LRL in the load factor is

positive.

• Link set RL(RI): Power estimation is based on the inactivity indication received for

an uplink NRT DCH. the change Δ LRL in the load factor is positive.

• Link set RL(RT): Power estimation is based on the establishment or upgrade of an

uplink RT DCH done earlier but the RRC entity has not informed yet the procedure

to be completed or the DCH is still inactive. The change Δ LRL in the load factor is

positive for more information see WCDMA RAN RRM Admission Control.

Change Δ L in the uplink own cell DCH load factor is then achieved as the sum:

Figure 58 Sum of the uplink DCH load factor changes

Uplink power estimation method of PS

Uplink power increase estimation (PIE) is done using the following formula if the change

in the load factor is positive, Δ L>0:

Figure 59 Uplink power increase estimation (PIE)

Uplink power decrease estimation (PDE) is done using the following formula if the

change in the load factor is negative, Δ L< 0:

Figure 60 Uplink power decrease estimation (PDE)

Quantity RTWP is the value of the received interference power that is defined in the fol-

lowing way:

• If the cell has no E-DCH MAC-d flow established, the RTWP is set equal to the

maximum of the quantities P rxTotal and average of P rxTotal . P rxTotal is the value of the

estimated PrxTotal at the moment of the power estimation. The averaged P rxTotal is

the value of the average estimated received wide band power at the moment of the

estimation. The averaged P rxTotal is defined in Section Power budget for packet

scheduling.

L = LRL + LRL + LRL + LRL + LRLRL RL(U) R L R L( D) R L R L( RN ) RL RL(RI) RL RL(RT)

PrxTotal = k *

L

1- n(1 - )

L

1 - n - L* RTWP+

PrxTotal

= k * + (1 - )L

1 - n - 2 L* RTWP

L

1 - n - L





DN0495772

Issue 14C

109


Id:0900d8058074d1b1

• If the cell has an E-DCH MAC-d flow established at the moment of the power esti-

mation, the RTWP is set equal to the maximum of:

• the momentary value of the estimated P rxNonEDCHST

• the averaged value of the estimated P rxNonEDCHST

• the last value reported by the BTS for the received total wide band power in a

common measurement report

The averaged P rxNonEDCH is produced from the samples of the estimated P rx-

NonEDCHST similarly as defined for the averaged P rxTotal in Section Power budget for

packet scheduling.

Quantity η is the value of the fractional load which is defined by the equation

η =1-PrxNoise/MAX(RTWP,PrxNoise)

where PrxNoise is the current noise power level.

Quantity κ is set to the value 1 and quantity α is set to the value 0 in the PIE formula.

However, if (1- η - Δ L) < 0.05 then α is set to 1.

Note that the received total wideband power PrxTotal is used in the uplink power-change

estimation formulas also in the cell which has an E-DCH MAC-d flow established, not

the non-E-DCH power PrxNonEDCH .

7.7.2 Downlink power estimation

With regard to the total change in downlink load, which the packet scheduler estimates,

it can be expressed as the combined effect of the load increase caused by new radio

bearers and load change because of modifications to the maximum bit rates (modifica-

tion of transport format sets or transport format combination control). Load decrease

caused by released radio bearers is not taken into account in the estimation. The effectof the released radio bearers is visible in next PtxTotal measurement. At the scheduling

moment, the cell specific packet scheduler uses the power increase estimation (PIE)

and power decrease estimation (PDE) formulas under the following conditions (mW):

Figure 61 Downlink power change estimation

where P tx,RL is the average transmitted DPDCH code power of the radio link at the

moment derived from the DPCH code power of the radio link measured and reported by

the BTS. Quantities Δ Ptx,RL(U), Δ Ptx,RL(D), Δ Ptx,RL(RN), Δ Ptx,RL(RT) and Δ Ptx,RL(RI) areintroduced in the chapter Power budget for packet scheduling.

If the appropriate radio link code power measurement result has not been received from

the BTS at the moment of the resource request, the quantity P tx,RL is set equal to the

initial code power of the radio link defined with the following equation:

Figure 62 Initial power estimation at radio link setup

Ptx,Total =

RL CELL

Ptx,RL

Ptx,RL

= [ Ptx,RL(U)

+ Ptx,RL(D)

+ Ptx,RL(RN)

+ Ptx,RL(RT)

+ Ptx,RL(RI)

- 1] * Ptx,RL

Ptx Ptx_initialρR

W-------

1

ρc

-----Ptx_primaryCPICH αPtx_total–⎝ ⎠⎛ ⎞

= =



110 DN0495772

Issue 14C


Id:0900d8058074d1b1

where

In case that UE is moved to the CELL_FACH state because of inactivity and the packet

scheduler receives the downlink capacity request, it is possible that the packet sched-uler does not have the current chip energy-to-interference ratio of the primary common

pilot channel (CPICH) channel available. In that case the packet scheduler uses the

stored value from the latest measurement report that UE has been sent.

The cell-specific packet scheduler can use the averaged DPDCH code power of the

radio link (P tx_average) in the estimation of the power change in case of NRT DCH bit rate

upgrade and in case of NRT DCH bit rate downgrade due to overload. This is done to

avoid a ping-pong effect as the downlink radio link power varies a lot.

PSRLAveragingWindowSize is a WBTS-specific RNC configuration parameter that

defines how many radio link specific measurement results of the average transmission

power of the DPDCH bits (P tx_average) are included in the sliding window used in the aver-

aging of the cell-specific PS.

If the PSRLAveragingWindowSize RNP parameter is set ‘On’ the P tx_average is averaged

in the RNC by using the following formula:

where P tx_average(t) is the power ([W]) of the DPDCH bits from the latest reported PtxAv-

erage value and n equals PSRLAveragingWindowSize.

First dedicated measurement result of the code power received from BTS after the setup

of the first RLS for the RRC connection is ignored. Power estimations are based on the

code power calculated from the measured CPICH Ec/No until the next dedicated mea-

surement report is received from BTS. Sliding RL measurement window contains just


W is the chip rate (3840 kbps).

ρ c is the chip energy-to-interference ratio of

the primary CPICH channel, measured by

user equipment.

ρ is the E b /N 0 value used in estimation,

(internal constant values).

P tx-primaryCPICH is the value of radio power control Trans-

mission power of the primary CPICH

channel (PtxPrimaryCPICH) management

parameter to determine the transmission

power of the primary CPICH.

α is the orthogonality factor (internalconstant value).

R is the initial bit rate of the radio bearer (the

current bit rate in the load increase/

decrease algorithm loop).

Ptx_RL is the radio link specific average transmis-

sion power of the dedicated physical data

channel (DPDCH) bits.

Table 24 Variables for power estimation at radio link reconfiguration

Ptx_average

Pt x_a vera ge tx_ ave rag e

(t-1 ) + ... + Ptx_average

(t) + P (t-(n-1 ))

=n







DN0495772

Issue 14C

111


Id:0900d8058074d1b1

estimated value (once) and possible received measurement reports after that. Averag-

ing is done with values in the averaging window.

If the NRT DCH bit rate is upgraded, the sliding measurement window is filled by the

value of the latest calculated P tx_average + Δ P tx (estimated power change /increase).If the PSRLAveragingWindowSize RNP parameter is set ‘Off’ the n in the above

equation is defined in the following way:

• If DediMeasRepPeriodPSdata <= 500ms then n = 4.

• If DediMeasRepPeriodPSdata <= 1000ms then n = 2.

• If DediMeasRepPeriodPSdata > 1000ms then n = 1.

DediMeasRepPeriodPSdata is a WBTS-specific RNC configuration parameter. The

parameter defines the reporting period of the Radio link measurements.

If the NRT DCH bit rate is downgraded, the sliding measurement window is filled with

the value of the latest calculated P tx_average - Δ P tx (estimated power change/decrease).

P tx_average is averaged analogously because the reliability of the reported transmitted

code power is not known as the radio link power varies a lot.



112 DN0495772

Issue 14C


Id:0900d805806ace52

7.8 Output information to load control

The packet scheduler has to provide periodical non-real time traffic load information to

the load control algorithm. The packet scheduler estimates the interference power of the

allocated non-real time users. Uplink non-real time traffic load information includes theparameters presented in the table below:

Estimates can be calculated using the following formulas:

Figure 63 Estimated total controllable power

where

The packet scheduler provides periodical streaming traffic load information to the load

control. The packet scheduler estimates the interference power of the allocated stream-

ing users. Uplink and downlink streaming traffic load information includes the following

parameters:

• PrxStreaming

• PtxStreaming

Estimates are calculated using the following formulas:


PrxNrt Estimated total received controllable power in uplink.

PtxNrt Estimated total transmitted controllable power in downlink.

Table 25 Parameters for non-real time traffic load information

Variable DescriptionPrxTotal is the total received interference in the cell, which is maintained by the cell

specific LC of the CRNC.

LactiveNRT Is the own cell load factor of the active uplink NRT DCH users introduced in

Section Cell- and radio link –specific load status information.

LEDCH,CELL Is the received E-DCH power share measured and reported by BTS in the

cell which has HSUPA configured. Quantity is introduced in Section Cell-

and radio link –specific load status information.

Ptx,i is the transmitted power of one radio bearer, which can be calculated using

the formula Initial power estimation at radio link setup for new radio bearers

and formula Power estimation at radio link reconfiguration (DCH allocated

to NRT RB) for modified radio bearers. P tx,i = P tx_average for radio bearers

which continue allocation unchanged.

Ptx_rl is the radio link specific average transmission power of the DPDCH bits.

Table 26 Parameters for estimated total transmitted controllable power

Ptx,NRT,RL

= Ptx, RL

DCH NRT(CCTrCH)

DCHR

DCH

RL Cell

Ptx,nrt

= Ptx,NRT,RL

DCH CCTrCH

DCHR

DCH

rx,nrt=

activeNRT rx,total



DN0495772

Issue 14C

113


Id:0900d805806ace52

Figure 64 Estimated uplink interference power of the allocated streaming users (Prx-

Streaming )

Received total wideband interference PrxTotal is used in the equation above also in the

E-DCH cell.

Figure 65 Estimated downlink interference power of the allocated streaming users

(PtxStreaming )


PrxTotal is the estimated total uplink interference in the cell.

Lactive_streaming is the own cell load factor of active uplink streaming users.Ptx,i is the transmitted power of one RB, that is defined for streaming

user same way as to NRT user.

N_streaming_active_DL is the number of active downlink streaming RBs in a cell.

Table 27 Parameters for estimated interference power of the allocated streaming

users

Prx,Streaming = L

active_streaming* P

rxTotal

PtxStreaming

= Ptx, i

N_streaming_active_DL

i = 1



114 DN0495772

Issue 14C


Id:0900d805805dca57

7.9 Response to UE-specific packet scheduler

The cell-specific packet scheduler returns scheduled bit rate to the UE-specific packet

scheduler for transport format combination set construction.

The BitRateSetPSNRT RNC configuration parameter defines the used bit rate set that

defines also the allowed bit rates that the PS can allocate. If some bit rate is not allowed

then the next lower allowed bit rate is used.



DN0495772

Issue 14C

115


Id:0900d805806fc6b3

7.10 Load control actions for PS radio bearers

The packet scheduler performs load control actions for NRT and PS streaming radio

bearers. If the load is too high, the packet scheduler starts to decrease bit rates of the

non-real time bearers.

The bit rates cannot be decreased below the thresholds defined by Minimum allowed

bit rate in uplink (MinAllowedBitRateUL) or Minimum allowed bit rate in downlink (MinAl-

lowedBitRateDL) except when the bit rate is not allowed by the BitRateSetPSNRT RNC

configuration parameter. In that case the bit rate value is the next allowed lower value.

If the minimum bit rate is already allocated, the DCH is released.

Compressed mode is stopped if the DCH needs to be released or downgraded because

of overload control actions.

If the RAN1759: Support for I-HSPA Sharing and Iur Mobility Enhancements feature is

enabled in the DRNC, the load control actions are applied also for the RLs coming over

Iur.

Triggers of the uplink DCH overload control are:

Figure 66 Thresholds of the UL DCH overload control

For more information on the quantities, see Section Bit rate allocation method.

The conditions are valid in the cell which the HSUPA has not configured. This document

describes the uplink NRT DCH overload control for those cells only which the HSUPA

has not configured. Overload control actions in the HSUPA cell are introduced in Section

Sharing interference between HSPA and NRT DCH users in Radio Resource Manage-

ment of HSUPA.

Trigger of the downlink DCH overload control is

PtxTotal ≥ PtxTarget + PtxOffset

Threshold of the DL NRT DCH overload control

For more information on the quantities, see Section Bit rate allocation method.

For more information on HSDPA-specific overload control actions, see Overload control

in WCDMA RAN RRM HSDPA.

The packet scheduler has to select the bearers for which the bit rate is to be decreased.This selection is done according to the principles presented in the following:

Overload control for NRT radio bearers in uplink and downlink

The selection of the radio bearers, whose bit rates have to be decreased, is done in the

following order:

1. based on the QoS priority value received from the UE-specific packet scheduler

2. based on the connection allocation time

3. based on the bit rate

The radio bearers with the lowest priority according to the QoS priority value are

selected first. If many candidates have the same priority, among the radio bearers with

the same priority those are selected that have the longest allocation time. If still many

LDCH, CELL

+ LEDCH,Streaming, CELL> LmaxDCH

OR

Prx,Total

> Prx,target

+ Prx, offset

LDCH, CELL

+ LEDCH,Streaming, CELL

> LminDCH









116 DN0495772

Issue 14C


Id:0900d805806fc6b3

candidates have the same priority, the radio bearer are selected that have the highest

bit rate.

After the priority order is clear, the bit rates of all PS radio bearers are downgraded

starting with the radio bearer which has the lowest priority.The lowest possible bit rates are:

• NRT radio bearer: MinAllowedBitRateUL and MinAllowedBitRateDL

• Streaming radio bearer: guaranteed bit rate

If downgrading the bit rates as low as possible does not release enough resources, the

radio bearers are switched from dedicated channel to common channel or released in

the order specified for the bit rate downgrade.

In the DRNC, the prioritization order starts based on IurPriority parameter value.

Then, the next steps are as described above.

The following additional conditions are applied in the uplink DCH overload reduction:

If the maximum load threshold LmaxDCH is exceeded, then downgrading is done in one

overload period so that the sum of the current DCH load factor LDCH,CELL and the current

E-DCH streaming load factor LEDCH_Streaming is reduced with the value ∆L = MIN(LmaxDCH

– LDCH,CELL- LEDCH,Streaming,CELL, LnrtDCH,CELL). DeltaPrxMaxDown power - decrease limit

parameter is ignored.

If the interference domain overload threshold PrxTarget + PrxOffset is exceeded, then

downgrading is done so that the quantity Lallowed_minDCH (LDCH,CELL+LEDCH,Streaming,CELL·∆L)

does not exceed the value 0. DeltaPrxMaxDown power decrease limit parameter is

applied.

For more information on the quantities, see Section Bit rate allocation method

The load decrease algorithm is presented for the uplink in Figure 67 Load decreasealgorithm for UL NRT DCHs. Examples of its operation in relation to Example of bit rate

allocation method are shown in Figure 68 Example of load decrease algorithm, DCH

modification and Figure 69 Example of load decrease algorithm, DCH modification and

release. In those figures, a minimum allowed bit rate of 128 kbit/s is assumed.

In the uplink direction the transport format combination control RRC procedure is used

and in the downlink direction the TFC subset method. Physical resources are not mod-

ified.





DN0495772

Issue 14C

117


Id:0900d805806fc6b3

Figure 67 Load decrease algorithm for UL NRT DCHs

Expression LminDCH OR (PrxTarget AND LmaxDCH ) represents the uplink DCH scheduling

targets both in the power and throughput domains as defined with the condition

Throughput and interference targets for UL DCH scheduling in Section Bit rate allocation

method.

Quantity Δ L represents the decrease in the load factor of the NRT DCHs.

PrxTotalNew, LnewDCH,CELL, and PrxTotalChange are calculated as in the load increasealgorithm.

Yes

Decrease loading

EstimatePrxTotal - PrxTotalChange

LDCH,CELL + LEDCH_Streaming,CELL

- DL

end

More bearers

Lower allowedbit rates

Longest allocation time andhighest bit rate radio bearer

NOYES

(LminDCH

ORPrxTarget OR

DeltaPrxMaxDown) AND

LmaxDCH

Switch radiobearer to CCH

or release DCH

Move to nextlower bit rate

YES

No

NO

LDCH, CELL

+ LEDCH_Streaming, CELL

- L < LminDCH

OR

Prx,Total

- Prx,TotalChange

< Prx_target

LDCH, CELL

+ LEDCH,Streaming, CELL

- L < LmaxDCH



118 DN0495772

Issue 14C


Id:0900d805806fc6b3

Figure 68 Example of load decrease algorithm, DCH modification

Figure 69 Example of load decrease algorithm, DCH modification and release

Figure 70 Load decrease algorithm for DL NRT DCHs shows the load decrease algo-

rithm for the downlink NRT DCH resources.

256

384

LminDCH OR (PrxTarget AND LmaxDCH)

Step 1 Step 2 Step 3

384

256

384

256256

256

256

Step 1: 384 256Step 2: 384 256

Allocation according to step 3

256256

256

LminDCH OR (PrxTarget AND LmaxDCH)

Step 1 Step 2 Step 3 Step 4

128

128

128

128

128

128 128128

128

128

128

128

128

128128

128

128128

128

128

128

Step 1: 384 256Step 2: 384 256Step 3: 128 CCH




DN0495772

Issue 14C

119


Id:0900d805806fc6b3

Figure 70 Load decrease algorithm for DL NRT DCHs

PtxTotalNew and PtxTotalChange are calculated as in the load increase algorithm.

When an overload situation is detected and dedicated channels are modified, it takes

some time before the decrease in load (PrxTotal and PtxTotal ) is reflected in the NBAP:

RADIO RESOURCE INDICATION (private NBAP) / NBAP: COMMON MEASURE-

MENT REPORT (3GPP NBAP) messages sent to the RNC. This delay may be longer

than the scheduling period and therefore it is necessary to wait for the load control

actions to take effect, to prevent unnecessary additional load control actions in the next

scheduling period.

Enhanced overload control for NRT radio bearers in downlink

In downlink it is possible to use Radio Link Reconfiguration procedure as the method for

overload control, that is, to decrease the bit rate and in the same time change the SF of

the DCH for that bearer or even release DCH/switch to CCH.

No

No

end

Decrease loading

Enhanced overloadcontrol

Longest allocation time andhighest bit rate radio bearer


Estimate:PtxTotal - PtxTotalChange

LDCH,CELL

+ L EDCH_Streaming,CELL - DL

(LminDCHOR

PtxTarget ORDeltaPtxMaxDown) AND

LmaxDCH

More bearers

Switch radiobearer to CCH

or release DCH


Yes

Yes No

Yes



120 DN0495772

Issue 14C


Id:0900d805806fc6b3

In an overload situation PS starts modification or reconfiguration of DCH(s) of the inter-

active or background class radio bearers. The OCdlNrtDCHgrantedMinAllocT parame-

ter defines if it is possible to apply the RL reconfiguration method. If the DCH has been

allocated longer than OCdlNrtDCHgrantedMinAllocT , radio link reconfiguration is possi-

ble.

The selection of the radio bearers, whose bit rates have to be decreased, is done in the

following order (step 1 via RL reconfiguration and other steps using TFC subset

method):

1. DCH(s) of NRT bearers, whose allocation time is more than OCdlNrtDCHgranted-

MinAllocT , are modified or switched from DCH to CCH. The DCH of a multi RAB

combination is released. The procedure follows the order of the QoS priority values

starting with the lowest value. Within the same priority value, the bearers with the

longest allocation time are handled first. If the selected set includes more than one

bearer that has the same DCH allocation time, the selection is made from that set in

the order of highest bit rate. RL reconfiguration method is applied here. Note that PSstreaming RBs are not handled in this step.

In the DRNC, the prioritization order is as follows:

a) The selection is done in order of IurPriority values (lowest value first) and

within the same priority value in order of QosPriority values.

b) If there are more than one candidate available with same Qospriority value,

selection is done in order of the longest allocation time.

c) If the selected set includes more than one bearers which have the same DCH

allocation time, the selection is made from that set in the order of highest bit rate.

2. DCH bit rates of the NRT bearers are decreased. This is done in the order of the

QoS priority values starting with the lowest value. Within the same priority value, the

bearers with the longest allocation time are handled first. If the selected set includesmore than one bearer which has the same DCH allocation time, the bearer in that

set are ordered by the bit rate starting with the highest. The minimum available bit

rate is specified by the MinAllowedBitRateDL parameter.


a) The selection is done in the order of IurPriority values (lowest value first)

and within the same priority value in the order of QosPriority values.

b) If there are more than one candidate available with same QosPriority value

then selection is done in order of the longest allocation time.

c) If the selected set includes more than one bearers which have the same DCH

allocation time, the bearers in that set are ordered by the bit rate starting with the

highest (but not below MinAllowedBitRateDL ).3. Bearers are switched from DCH to CCH. The DCH of a multi RAB combination is

released. This is done in the order of the QoS priority values starting with the lowest

value. Within the same priority value, the bearers with the longest allocation time are

handled first. Note that also PS streaming RBs can be released here. They are

released after all NRT RBs have been released because streaming RBs have

always a higher priority than NRT RBs.


a) The selection is done in the order of IurPriority values (lowest value first)

and within the same priority value in the order of QosPriority values.

b) If there are more than one candidate available with same QosPriority value

then selection is done in order of the longest allocation time.



DN0495772

Issue 14C

121


Id:0900d805806fc6b3

In the DRNC, if the candidate selected is controlled by another RNC, then the RNP

RNSAPCongAndPreemption parameter stored in the Iur Item of the corresponding

RNC is checked to see if the neighbouring RNC supports RNSAP CONGESTION INDI-

CATION and RNSAP PREEMPTION messages, since the DCH release/bit rate modifi-

cation/rl deletion is indicated to the SRNC via the RNSAP messages. If the SRNC does

not support these RNSAP messages, the DRNC avoids sending these messages over

Iur. Hence, when the candidate selection is done as per the above steps, it must be

ensured, that if candidate belongs to another RNC, the corresponding RNC supports

mentioned RNSAP messages.

The DRNC monitors the effects on the RL(s) to decrease the bit rate of DCH(s), and the

RRC connection of the RL(s) is anchored by the SRNC. Monitoring time is determined

by the RNP internal timer CongWaitTimeDRNC . The value of this timer is fixed to 2 s.

After the timer expiry, if the resource is not released, or the DCH bit rate is not down-

graded for the corresponding UE, the DRNC repeats neither the DCH selection proce-

dure nor PS streaming RB selection procedure again.

The DRNC applies an internal 10 s penalty timer for the DRNC UE for which no

response is received from the SRNC causing the CongWaitTimeDRNC timer expiry.

While the penalty timer is active, the corresponding DRNC UE cannot be selected as a

candidate for the bit rate downgrade because of overload control.

If the candidate is selected in a DRNC candidate, then switch to CCH cannot be per-

formed; instead RL is released by Radio Link Pre-emption Required Indication

Message.

TFC subset method is used when the allocation time for the modified DCH is lower than

OCdlNrtDCHgrantedMinAllocT . Physical resources are not modified in this case. When

the allocation time for the modified DCH is higher than OCdlNrtDCHgrantedMinAllocT ,

the RRC radio link reconfiguration procedure is applied (TrCH bit rate and PhCh SF aremodified) and the physical resources are modified.

Note: TFC subset method is not supported in the DRNC. Hence, in the DRNC, if the

selected candidate was an DRNC candidate, TrCH bit rate and PhCh SF are modified,

RNSAP: RADIO LINK RECONFIGURATION PROCEDURE is always used, even when

the modified DCH allocation time is lower than OCdlNrtDCHgrantedMinAllocT

parameter value.

When the overload is detected and dedicated channel is modified using TFC subset

method or Transport Channel Reconfiguration procedure, it takes some time before the

decrease in load (PtxTotal ) can be seen in RNC from the NBAP: RADIO RESOURCE

INDICATION [private NBAP]/COMMON MEASUREMENT REPORT [3GPP NBAP]

messages. This delay can be longer than the scheduling period and, therefore, it is nec-essary to wait that the load control actions have effected, to prevent new unnecessary

load control actions in the next scheduling period.

Examples of Enhanced Overload Control are illustrated in figures Figure 71 Enhanced

overload control for the DL NRT DCH radio bearer, OCdlNrtDCHgrantedMinAllocT and

LoadControlPeriodPS interactions and Figure 73 Example of enhanced over load

decrease algorithm, physical channel release and reconfiguration. The Enhanced

Overload Control algorithm is illustrated in Figure 72 Enhanced overload decrease algo-

rithm.



122 DN0495772

Issue 14C


Id:0900d805806fc6b3

Figure 71 Enhanced overload control for the DL NRT DCH radio bearer, OCdlNrtD-

CHgrantedMinAllocT and LoadControlPeriodPS interactions

The DCH modification is not alloweddue to LoadControlPeriodPS timer Bit rate upgraded

DL DCH Allocationfor NRT RB

Time

OverLoadLnrtDCHgrantedMinAllocT

Overload detection

LoadControlPeriodPS

Bit rate

MinimumallowedBit rate

Scheduling andRRing Period

Bit rate decreased due to overload.TFC subset method is used. RLreconfiguration is not allowed

Bit rate decreased and spreadingfactor increased, RL

reconfiguration is used(or switched to CCH)

Inactivity time



DN0495772

Issue 14C

123


Id:0900d805806fc6b3

Figure 72 Enhanced overload decrease algorithm

PtxTotalNew , PtxNrtNew and PtxTotalChange are calculated as in load increase algo-

rithm.

(Ptx-TotalNew >

PtxTarget||

PtxTotalNew > PtxTarget)&&

PtxTotalChange<DeltaPrxMax-

Down

NO

Enhanced overloadcontrol


YES

Candidate selection basedon the value of

CRHandlingPolicyDL

NRT DCHallocation time <=

OCdlNrtDCHgranted-MinAllocT

Decrease loading

NO

Estimate PtxTotalNewand PtxNrtNew

endNO

YES

More bearers


Estimate PtxTotalNewand PtxNrtNew

Switch bearer to CCH

NO

(Ptx-TotalNew >PtxTarget

||PtxTotalNew > PtxTarget)

&&PtxTotalChange<

DeltaPrxMax-Down

YES

YES NO

YES



124 DN0495772

Issue 14C


Id:0900d805806fc6b3

Figure 73 Example of enhanced over load decrease algorithm, physical channel

release and reconfiguration

g When the maximum bit rates of the NRT radio bearers are decreased using DL/UL

TFCC method and the overload situation is over, original bit rates are given back to

those bearers whose bit rates were decreased before new allocations are made.

When RRC Radio Link Reconfiguration procedure is applied for decreasing the

maximum bit rate(s), the original bit rate(s) is not automatically returned to the DCH(s).

The PS load control period (LoadControlPeriodPS) parameter determines how fre-

quently the packet scheduler can perform load control actions in the cell in question.

Uplink NRT DCH overload control in the E-DCH cell

The conventional uplink overload control of the NRT DCH resources applies the RRC

TFC-control procedure in the reduction of the uplink data rates. It leaves the uplink DCH

resources in the BTS untouched. If the cell has the E-DCH MAC-d flows established,

part of the BTS HW resources is not available for the E-DCH traffic. BTS can also use

too big uplink own-cell DCH load factor in its throughput-based E-DCH scheduling.Because the NBAP signalling does not provide with means for the TFCS subset defini-

tions, the only way to update the BTS with new uplink DCH parameters is the use of the

NBAP radio link reconfiguration procedures. Therefore, an overload control algorithm,

similar to the Enhanced overload control for NRT radio bearers in downlink in its logic,

is employed for the uplink NRT DCH resources when the HSUPA has been configured

in the cell. For more information on the algorithm, see the Section Sharing interference

between HSPA and NRT DCH users in WCDMA RAN RRM HSUPA.

128128128

128

128128128128

128128128128128

256256

256

PtxTarget

Step 1: 256 -> CCHStep 2: 256 -> 128


Step 1 Step 2 Step 3







DN0495772

Issue 14C

125


Id:0900d805806fd30e

7.11 Enhanced priority based scheduling

The feature Enhanced priority based scheduling allows the operator to select alternative

methods for the packet scheduling. These alternative methods, which can be enabled

by the RNC configuration parameters, are based on the radio bearer reconfigurationprocedures.

Cell-specific packet scheduler in the DRNC performs priority based scheduling of non-

real time DCH capacity requests from the SRNC if the RAN1759: Support for I-HSPA

Sharing and Iur Mobility Enhancements feature is enabled. In the DRNC priority based

scheduling is done whenever the requested bit rate over Iur for the NRT DCH is initial

bit rate. Priority based scheduling is done in the DRNC for NRT DCH during radio link

setup, addition, or reconfiguration.

PS streaming RBs cannot be target for actions done by priority based scheduling. Also

capacity requests for PS streaming RB do not trigger priority based scheduling.

With the standard functionality of the packet scheduling algorithm, traffic handling

priority can be taken into account when allocating dedicated resources for NRT traffic

within one scheduling period, which is configured by the operator. A DCH allocation for

NRT is released when the RLC buffer is empty and the inactivity timer expires. Because

of the bursty nature of NRT traffic with most common applications (for example

web/WAP browsing), the allocations for NRT users are typically very short. However, in

some cases the large data amount or nature of application (for example FTP) allocation

times can be relatively long. The enhanced priority based scheduling algorithm by the

Radio Bearer Reconfigurations brings more powerful differentiation capabilities to the

operator’s network. Better QoS by enhanced bit rate allocation algorithm and priority

handling is achieved. Existing NRT allocations can be downgraded or released if there

are ‘higher’/’higher or equal’/’any’ (enhanced priority based scheduling policy can be

controlled with the RNC configuration parameter) priority users requesting capacity inthe congested situation.

Congestion of the following resources can trigger the enhanced priority based schedul-

ing function: downlink power, uplink interference, downlink spreading code, BTS HW

(WSP), and Iub AAL2 transmission.

In case of BTS HW or Iub AAL2 transmission congestion, the bit rate of the NRT DCH

that is tried to allocate is decreased, step by step, down to the initial level. Priority based

scheduling procedure is triggered if DCH allocation even with the initial bit rate faces

BTS or Iub AAL2 transmission congestion.

The QoSPriorityMapping RNP parameter defines queuing policy for NRT capacity

requests. It is possible to favour, for example, capacity requests of higher priority RABsso that those are scheduled first.

Priority based scheduling operation is performed only for one capacity request in each

scheduling period.

The priority based scheduling operation is performed if otherwise no NRT DCH alloca-

tion can be performed during this scheduling period. This ensures the initial bit rate to

be allocated.

The priority based scheduling has no effect on the bit rate upgrades. That means a RAB

requesting capacity is not allowed to have existing NRT DCH allocation for the same

radio bearer. Also, the enhanced priority based scheduling function is not performed

during the compressed mode.



126 DN0495772

Issue 14C


Id:0900d805806fd30e

Figure 74 Example of PBS functionality in uplink interference congestion shows as an

example the principles of the priority based scheduling in uplink interference congestion:

Figure 74 Example of PBS functionality in uplink interference congestion

In this example, priority 1 is the highest priority of the non-real time radio bearers and

the priorities are mapped from radio bearer traffic class parameters in the following way:

Priority 1 is the radio bearer whose traffic class is interactive and traffic handling priority

is 1,


is 2,


is 3 and

Priority 4 is the radio bearer whose traffic class is background.

1. Capacity request for RB 4 is put to queue.

2. P1: First scheduling moment after capacity request RB 4

• DL power and UL interference estimations are made -> UL interference conges-

tion detected

• PBS is applied:

• PBS policy is selected according to PBS Policy parameter as defined in

Defining priority based scheduling policy. In this case, the policy is set to 2

(priority of incoming RB must be ‘higher’).

2:P1 4:P2 6:P3 8:Px 9:T1 10:P(x+1)

Time

1. capa req RB 43. capa req RB 5

5. capa req RB 67. capa req RB 5

Bit

Rate

RT DCH 1 RT DCH 1 RT DCH 1 RT DCH 1 RT DCH 1 RT DCH 1

NRT DCH 2(priority 3) NRT DCH 2

NRT DCH 2 NRT DCH 2 NRT DCH 2 NRT DCH 2

NRT DCH 3(priority 4)


NRT DCH 3 NRT DCH 3 NRT DCH 3 NRT DCH 3 NRT DCH 3


NRT DCH 5 NRT DCH 5 NRT DCH 5


NRT DCH 4






DN0495772

Issue 14C

127


Id:0900d805806fd30e

• Target for downgrade or release is selected according to Selection of the

radio bearer(s) to be released or downgraded in priority based scheduling.

In this case, it is assumed that the allocation times for both NRT DCH 3 and

NRT DCH 2 are longer than the granted minimum allocation time. DCH 3 is

selected in the example because of lower priority than DCH 2.

• DCH 3 is downgraded and capacity is allocated to incoming dedicated

channel according to the first table in Capacity allocation in priority based

scheduling.


4. P2: First scheduling moment after capacity request RB 5

• PBS is applied:

• PBS policy is set to 2 (priority of incoming RB must be ‘higher’)

• Target for downgrade or release is selected according to Selection of the

radio bearer(s) to be released or downgraded in priority based scheduling.

• It is assumed that the granted minimum allocation time for DCH 4 is deter-mined by the PBSgrantedMinDCHallocTlowerP parameter because the

priority of the incoming capacity request is higher than the priority of DCH 4.

The PBSgrantedMinDCHallocTlowerP parameter defines the minimum allo-

cation time granted for an NRT DCH in priority based scheduling, when the

priority of the RAB of this NRT DCH is lower than the priority of the RAB of

the incoming capacity request (for reference, see Defining the minimum time

between two consecutive PBS operations for a radio bearer ).

• PBS operations are not allowed for DCH 4, because it is assumed that the allo-

cation time for DCH 4 is shorter than the granted minimum allocation time.

• The granted minimum allocation time for DCH 3 after downgrade of DCH 3

because of PBS follows the rule of minimum time between two consecutivepriority based scheduling operations related to certain DCH (for reference, see

Defining the minimum time between two consecutive PBS operations for a radio

bearer in this chapter) and thus the granted minimum time is determined by the

FactorMinPBSinterval and PBSgrantedMinDCHallocTlowerP parameters. PBS

operations are not allowed for DCH 3, because it is assumed that the allocation

time for DCH 3 is shorter than the granted minimum allocation time.

It is also assumed that allocation time for NRT DCH 2 is longer than the granted

minimum allocation time.

DCH 2 is downgraded and capacity is allocated to incoming dedicated channel

according to the first table in Capacity allocation in priority based scheduling.


6. P3: First scheduling moment after capacity request for RB 6

• Interference congestion detected, PBS not possible. The following actions are

made:

• PBS policy is set to 2 (priority of incoming RB must be ‘higher’).

• PBS operations are not allowed for DCH 5 because the priority of NRT DCH

5 priority is the same as the priority of the RAB of the incoming capacity

request.

• The minimum allocation time for DCH 4 is determined with the PBSgranted-

MinDCHallocTlowerP parameter because the priority of the incoming

capacity request is higher than the priority of DCH 4 and the allocation time

of DCH 4 is shorter than the granted minimum allocation time.



128 DN0495772

Issue 14C


Id:0900d805806fd30e

• The granted minimum allocation times for DCH 2 and DCH 3 after down-

graded operations because of PBS follows the rule of minimum time

between two consecutive priority based scheduling operations related to

certain DCH. PBS operations are not allowed for DCH 2 and DCH 3,

because it is assumed that the allocation time for them is shorter than the

granted minimum allocation time.

Capacity request for RB 6 stays in queue.

7. New capacity request for RB 6, previous requests have been rejected by PBS algo-

rithm because of congestion. The capacity request is put to queue.

8. Px: Scheduling moment with the same assumptions as between the scheduling

moments P3 and Px

Capacity request for RB 6 stays in queue.

9. T1: Time instant when DCH 4 has been allocated the granted minimum allocation

time

10. P(x+1): First scheduling moment after Px

• PBS applied: DCH 4 downgraded, capacity allocated to RB 6.

• At this scheduling moment, the situation of DCH 4 is changed from previous

moments (Px and earlier). Allocation time for DCH 4 has exceeded the granted

minimum allocation time and DCH 4 is downgraded and capacity is allocated to

incoming dedicated channel according to the first table in Capacity allocation in

priority based scheduling.

Defining priority based scheduling policy

The alternative methods for priority based scheduling are defined by PBSpolicy RNW

configuration parameter.

The following alternatives can be used:

1. Priority based scheduling is not active

Priority based scheduling functionality is not active.

2. Higher traffic handling priority

RAB of the incoming capacity request must have higher traffic handling priority than

the RAB of the DCH to be downgraded or released.

3. Higher or equal traffic handling priority

RAB of the incoming capacity request must have higher or equal traffic handling

priority than the RAB of the DCH to be downgraded or released.

4. Higher or equal traffic handling priority (not the highest NRT priority)

RAB of the incoming capacity request must have higher or equal traffic handling

priority than the RAB of the DCH to be downgraded or released. However, DCHs of the RABs are excluded that have the highest NRT priority specified by the QoSPri-

orityMapping parameter.

5. Any traffic handling priority

RAB of the incoming capacity request can have even lower (or equal/higher) traffic

handling priority than the RAB of the DCH to be downgraded or released.

6. Any traffic handling priority (not the highest NRT priority)

RAB of the incoming capacity request can have even lower (or equal/higher) traffic

handling priority than the RAB of the DCH to be downgraded or released. However

DCHs of RABs are excluded that have the highest NRT priority specified by the

QoSPriorityMapping parameter.



DN0495772

Issue 14C

129


Id:0900d805806fd30e

Selection of the radio bearer(s) to be released or downgraded in priority based

scheduling

The packet scheduler compares the QoS priority of the incoming capacity request, that

is the first capacity request in queue, to the priorities of the existing DCH radio bearers.If the bearer class and the traffic handling comparison do not give an explicit result, that

is, there are more radio bearers suitable to be selected than needed, an additional com-

parison is made in the following order:

Cell uplink interference and downlink transmission power congestion:

1. RAB whose QoS priority value received from UE specific packet scheduler has the

lowest priority.

2. RAB whose radio link specific power in downlink is closest to the link maximum has

the lowest priority.

3. RAB whose DCH maximum bit rate is highest has the lowest priority.

4. RAB whose DCH allocation time is longest has the lowest priority.

In the DRNC the following prioritization is used for interference and uplink transmission

power congestion between RLs over Iur and RLs cotrolled by RNC:

1. RAB whose RNP IurPriority parameter value has the lowest priority.


lowest priority.

3. RAB whose radio link specific power in downlink is closest to the link maximum has

the lowest priority.



Downlink spreading code, BTS HW or Iub AAL2 transmission congestion:


lowest priority.

2. RAB which DCH maximum bit rate is highest has the lowest priority.


In DL spreading code congestion, the code to be released can be the whole spreading

code or a part of it.

If release or downgrade procedure of DCH(s) cannot be triggered during BTS HW or Iub

AAL2 transmission congestion, RNC interrupts the allocation of the new NRT DCH and

the capacity request is rejected.

In the DRNC for downlink spreading code, BTS HW or Iub AAL2 transmission conges-

tion:

1. RAB whose RNP IurPriority parameter value has the lowest priority.


lowest priority.



If the candidate selected is controlled by another RNC, the

RNSAPCongAndPreemption parameter stored in the Iur item of the corresponding

RNC is checked to see if the neighbouring RNC supports RNSAP: CONGESTION INDI-

CATION and RNSAP: PREEMPTION REQUIRED messages, since the DCH release or bit rate modification is indicated to the SRNC via the RNSAP messages. If the SRNC



130 DN0495772

Issue 14C


Id:0900d805806fd30e

does not support these RNSAP messages, the DRNC must avoid sending these

messages over Iur. Hence, when the candidate selection is done according to the steps

above, it must be ensured that if the candidate belongs to another RNC then the corre-

sponding, an RNC must support the RNSAP congestion/preemption messages.

Capacity allocation in priority based scheduling

The capacity allocation is based on uplink interference and downlink power estimations

as presented in Estimation of power change in Figures Uplink power estimation, integral

method , Fractional load , Load factor change, load increase algorithm, Load factor

change, load decrease algorithm, Uplink power estimation, derivative method and

Uplink power change estimation for uplink and in Figures Downlink power change esti-

mation, Initial power estimation at radio link setup and Power estimation at radio link

reconfiguration (DCH allocated to NRT RB) for downlink in Section Estimation of power

change. The PS estimates the scheduled, downgraded and released air interface

capacity when performing the priority based scheduling.

Table 28 Capacity allocation in priority based scheduling presents the actions to release

capacity for the incoming capacity request in priority based scheduling.

Steps from 1 onwards are taken until capacity for the incoming request can be allocated.

RB to lose

resources

RB to have

resources

Air Interface Initial request for low

bit rate1. Downgrade as

much as needed,

so that the initial

low bit rate DCH

fits in

2. Downgrade toinitial bit rate

3. Downgrade to

minimum bit rate

4. Release DCH

5. Take the second

DCH into proce-

dure

1. Allocate initial bit

rate


rate


rate


rate


rate

High bit rate

requested1. Downgrade to

initial bit rate

2. Downgrade to

initial bit rate

3. Downgrade tominimum bit rate

4. Release DCH

5. Take the second

DCH into proce-

dure

1. Allocate the

highest possible

DCH that fits in

after the down-

grade2. Allocate initial bit

rate


rate


rate


rate

Table 28 Capacity allocation in priority based scheduling



DN0495772

Issue 14C

131


Id:0900d805806fd30e

After sending the DCH downgrade or release request due to congestion to the SRNC

via RNSAP: CONGESTION INDICATION or PREEMPTION REQUIRED message (in

case the selected candidate is controlled by the SRNC), the UE-specific packet sched-

uler in the DRNC waits for the period indicated by the internal timer CongWaitTime-

DRNC (fixed to a value of 2 seconds). Even after the timer has expired, the resourcehave been released, or DCH downgrade request is not received from SRNC, the UE-

specific packet scheduler informs the cell-specific packet scheduler about the failure.

Upon receiving the failure notification, cell-specific packet scheduler in the DRNC does

not repeat the selection procedure again. The capacity request that triggers the PBS is

retained in the queue if the congestion of uplink interference, downlink power, or

downlink spreading code occurs. However, if the congestion of the BTS HW or Iub AAL2

transmission occurs, the capacity request is discarded from the queue, and the sched-

uling is resumed. If the release or downgrade procedure of DCH(s) is successful, in case

of uplink or downlink interference congestion, originally-scheduled DCH setup is started

without an interference estimation. In case of downlink spreading code congestion, DCH

setup is started without exceptions. Also scheduling is resumed for other capacityrequests in this cell in the next scheduling period.

Spreading code con-

gestion

1. Downgrade to

initial bit rate2. Downgrade to

minimum bit rate

3. Release DCH


rate2. Allocate initial bit

rate


rate

BTS HW congestion 1. Downgrade DCH

to initial bit rate or

if initial bit rate is

already in use,

release DCH from

same local cell

group or same

BTS if cell group

info not available


rate

AAL congestion 1. If BTS aal2 multi-

plexing is dis-

abled,

downgrade DCH

to initial bit rate or

if initial bit rate is

in use, release

DCH from same

traffic termination

point (TTP) . If

BTS aal2 multi-

plexing isenabled, down-

grade or release

DCH from any

TTP belonging to

the BTS.


rate

RB to lose

resources

RB to have

resources

Table 28 Capacity allocation in priority based scheduling (Cont.)



132 DN0495772

Issue 14C


Id:0900d805806fd30e

In uplink interference and downlink power congestion, the released capacity is dedi-

cated for NRT capacity request that has triggered the release or downgrade of this DCH

over other NRT capacity requests by processing this capacity request first in the next

possible scheduling moment. However, RT capacity requests have higher priority than

NRT ones in any case and those can reserve released capacity.

Note that in case the capacity request is for bit rate higher than initial bit rate, the PBS

scheduling is not performed by the cell-specific packet scheduler of the DRNC if the

requested resources are not available.

In DL spreading code, BTS HW and Iub AAL2 transmission congestion the reconfigura-

tion procedure of the radio bearer of the downgraded or released DCH is started imme-

diately.

DCH downgrade and release

The non-real time DCH downgrade or release due to priority based scheduling is done

by the DRNC by sending RNSAP: RADIO LINK CONGESTION INDICATION to the

SRNC.

The Allowed UL Rate IE and Allowed DL Rate IE contains the DCH downgraded rate,

selected during the previous procedure.

The Allowed Rate indicates the new maximum bit rate for the corresponding NRT DCH

in the uplink and/or downlink direction. When the SRNC downgrades the bit rate of the

NRT DCH upon receving the congestion indication message it may downgrade the DCH

to a bit rate lower or equal to the indicated allowed bitrate.

Restrictions

Because the BTS does not send the direction of the congestion to the RNC, the RNC

needs to hunt resources from both direction to incoming initial capacity request. ThusRNC needs to downgrade both direction immediately to avoid unnecessary signalling

over Iub.

Defining the minimum time between two consecutive PBS operations for a radio

bearer

The operator can prevent reconfigurations for very short allocations and thus decrease

signalling by defining a minimum time between two consecutive priority based schedul-

ing operations for a certain radio bearer. The minimum time is calculated depending on

the priority of the radio bearer to be released or downgraded and the priority of the

incoming radio bearer as follows:

The priority of the radio bearer to be released or downgraded is higher than the priority

of the incoming radio bearer:

MinPBSintervalHigherP = FactorMinPBSinterval *

PBSgrantedMinDCHallocThigherP

The priority of the radio bearer to be released or downgraded is equal to the priority of

the incoming radio bearer:

MinPBSintervalEqualP = FactorMinPBSinterval *

PBSgrantedMinDCHallocTequalP



DN0495772

Issue 14C

133


Id:0900d805806fd30e

The priority of the radio bearer to be released or downgraded is lower than the priority

of the incoming radio bearer:

MinPBSintervalLowerP = FactorMinPBSinterval *

PBSgrantedMinDCHallocTlowerP

where

PBSgrantedMinDCHallocThigherP

PBSgrantedMinDCHallocTequalP

PBSgrantedMinDCHallocTlowerP

are RNW configuration parameters for granted minimum allocation times for NRT radio

bearer when the priority of the radio bearer to be released or downgraded is

higher/equal/lower than the priority of the incoming radio bearer.

FactorMinPBSinterval is an RNW configuration parameter with range (0&1.0).

Returning the bit rate of downgraded radio bearers

The packet scheduler does not return the bit rate automatically even though there would

later exist available capacity. However, the bit rates which have been downgraded to

initial bit rate or under initial bit rate are possible to upgrade based on capacity request

sent by the UE or L2 layer of the RNC.

Soft handover

Each cell specific packet scheduler performs functions related to priority based sched-

uling independently.

Bitrate selection in the SRNC during anchoringCell-specific anchoring packet scheduler is responsible for selecting the bit rate based

on the capacity request received from the UE-specific packet scheduler during anchor-

ing. The principle followed is the same as during non-anchoring scenario. The only dif-

ference is that there is no load increase check algorithm or resource allocation (dowlink

power, spreading factor) in the cell-specific anchoring packet scheduler.

The RNC NRTPSdataTTIAMRLC configuration parameter defines the allowed bit rates

that PS can use. The RNC BitRateSetPSNRT configuration parameter defines the

used bit rate set and the set defines also allowed bit rates.

The basic idea of packet scheduling method is the following:

• It allocates low uplink bit rate and low downlink bit rate when DCH is not allocatedfor NRT RB and PS receives uplink capacity request where low amount of data is

indicated.

• It allocates low uplink bit rate and low downlink bit rate when DCH is not allocated

for NRT RB and PS receives downlink capacity request where low data amount is

indicated.

• It allocates highest possible uplink bit rate and low downlink bit rate when DCH is

not allocated for NRT RB and PS receives uplink capacity request where high data

amount is indicated

• It allocates low uplink bit rate and highest possible downlink bit rate when DCH is

not allocated for NRT RB and PS receives downlink capacity request where high

data amount is indicated.



134 DN0495772

Issue 14C


Id:0900d805806fd30e

• It allocates highest possible bit rate for that direction, that is, upgrades the bit rate,

when low bit rate DCH is allocated for NRT RB for certain direction and PS receives

capacity request of that certain direction and high data amount is indicated.

• Initial uplink bit rate and initial downlink bit rate are set by radio network planningparameters. Parameters: "Uplink initial bit rate" (InitialBitRateUL ) and "Down-

link initial bit rate" (InitialBitRateDL) define initial uplink bit rate and initial

downlink bit rate respectively.

• When bit rate requested by UE-specific PS is lower than initial bit rate

(InitialBitRateUL or InitialBitRateDL), bit rate requested by UE-specific

PS is used as a new initial bit rate for this particular RAB.

Iur-users and own-users prioritisation in the DRNC

The RNC level IurPriority parameter defines the DRNC priorities between the Iur-

users and the own-users for the following traffic types:

1. CS2. RT PS

3. NRT PS.

Regardless of the IurPriority parameter, the DRNC selects the candidate for RT-over-

RT or RT-over-NRT actions from the candidates of the lowest possible traffic type (CS,

RT PS, or NRT PS).

The IurPriority parameter is used as one of the selection criteria of the candidates during

the priority-based scheduling (PBS), overload control, pre-emption, RT-over-RT, and

RT-over-NRT procedures. The candidates with the lowest IurPriority are always

selected first. Then the candidates with the next lowest value of the IurPriority parameter

are selected.

IurPriority value user's priority in the DRNC candidate for the RT-over-RT

or RT-over-NRT actions

Equal Priority equal priority -

Higher Priority over Iur Iur-users have higher priority own-users

Lower Priority over Iur Iur-users have lower priority Iur-users

Table 29 Iur-users and own-users prioritisation in the DRNC



DN0495772

Issue 14C

135

WCDMA RAN RRM Packet Scheduler UE- and cell-specific parts of the packet scheduler

Id:0900d8058074ca64

8 UE- and cell-specific parts of the packet

scheduler

8.1 RT-over-RT and RT-over-NRT functionality

The packet scheduler decreases the proportion of PS allocations (interactive, back-

ground and streaming class bearers) when CS allocations are requesting capacity,

provided that one of the following conditions is fulfilled:

• The cell is highly loaded so that admission is not otherwise possible.

• The UE capability prevents the admission and the decrease of the bit rate of its non-

real time bearers makes the admission possible.

• The BTS capability prevents the admission and the decrease of the bit rates of the

UE´s non-real time bearers makes the admission possible.

Furthermore, the packet scheduler decreases the proportion of non-real time allocations

(interactive and background class bearers) when PS streaming allocations are request-

ing capacity. Only those NRT RBs can be downgraded that have lower priority than PS

streaming RAB, where priorities are defined with the RNP parameter QoSPriorityMap-

ping.. PS streaming priority versus NRT priority is defined with the following rules:

• new PS streaming RAB: The NRT RAB has a lower priority than the PS streaming

RAB if its priority is lower than the threshold specified by the

RTOverNRTPriThresholdARP1,2,3 RNP parameter.

• existing PS streaming RAB: all NRT RABs have a lower priority.

In either case (RT-over-RT or RT-over-NRT), the reconfiguration is done immediately as

a part of the admission control phase. In other words, the algorithm does not have towait until the next scheduling period.

The original DCH bit rates are not automatically returned in any case.

RT-over-NRT actions are not targeted to HS-DSCH and E-DCH MAC-d flows. Note that

the RT-over-NRT actions can be targeted to the HSDPA related UL return channel

(DCH), causing also the release of HS-DSCH MAC-d flow. For more information, see

UE-specific resource handling in WCDMA RAN RRM HSDPA and Basic packet sched-

uling and admission control for HSUPA in WCDMA RAN RRM HSUPA.

















136 DN0495772

Issue 14C


Id:0900d805806a1ac3

8.2 PS streaming over NRT functionality

The packet scheduler decreases the proportion of non-real time allocations (interactive

and background class bearers) when PS streaming allocations are requesting capacity.

Only those NRT RBs can be downgraded that have lower priority than PS streamingRAB. PS streaming priority versus NRT priority is defined with the following rules:

• new PS RAB: The NRT RAB has a lower priority than the PS streaming RAB if its

priority is lower than the threshold specified by the

RTOverNRTPriThresholdARP1,2,3 RNP parameter.

• existing PS RAB: all NRT RABs have a lower priority.

Priorities are defined with the RNP parameter QoSPriorityMapping.

For more information, see UE-specific resource handling in WCDMA RAN RRM HSDPA

and Admission decision for PS streaming over E-DCH in WCDMA RAN RRM HSUPA.i











DN0495772

Issue 14C

137


Id:0900d805807505ad

8.3 Dynamic link optimisation for non-real time traffic

coverage

The downlink power allocation algorithm, which defines the UE-specific maximum trans-

mission power for non-real time traffic, is based on the Planned maximum downlink

transmission power of a radio link (PtxDLabsmax) and DPCH downlink transmission

power maximum value (PtxDPCHmax) radio network planning (RNP) parameters.

These parameters define the planned maximum transmission power of a radio link

including non-real time radio access bearer and the maximum allowed dedicated

physical channel (DPCH) transmission power respectively.

In the case of a real-time PS (streaming) and a non-real time PS multi service, the

Maximum transmitted code power of PS streaming RAB (PtxPSstreamAbsMax) param-

eter can limit the maximum allowed downlink transmission power. For more information,

see WCDMA RAN RRM Admission Control.

However, it may not be possible to use the maximum bit rate throughout a given cell,

because power constraints limit the bit rate allocation at the border area of a cell. In other

words, when the highest possible transmission power is used, the UE-specific downlink

transmission power cannot be further increased, thereby hindering the UE to receive

data with sufficient quality.

The solution to this problem is to drop the bit rate of the non-real time radio bearer (and

the radio link) when the RNC detects that the BTS is transmitting with the maximum

power allowed for the radio link. By allowing the bit rate to be adjusted according to this

criterion, the coverage of the non-real time user is improved, as illustrated in Figure

75 The principle of dynamic link optimisation.

Dynamic link optimisation for non-real time traffic coverage (DyLO) is a generic feature.

The packet scheduler applies it to all non-real time packet-switched data services. Thefeature can be activated/deactivated with the Dynamic link optimisation usage (DLOpti-

misationUsage) management parameter.

Figure 75 The principle of dynamic link optimisation

In the uplink direction, the UE reconfigures the radio link independently of the network.

Therefore there is no need for a corresponding link optimisation in the uplink direction.

Dynamic link optimisation for non-real time traffic coverage increases the coverage area

of the UE by ensuring sufficient quality of the radio link. The UE located at the border

UE

128kbps

384kbps

Radio link is modified to uselower bit rate when Tx power is getting close to maximum

BTS











138 DN0495772

Issue 14C


Id:0900d805807505ad

area of a cell and having a high bit rate non-real time packet-switched data service allo-

cated, can suffer from limited coverage and even from radio link failure in the case of

inadequate downlink transmission power. By decreasing the downlink bit rate, the

dynamic link optimisation feature ensures sufficient transmission quality for the radio

link, for example, until a handover is triggered.

Example:

The UE has a multi-service AMR 12.2 speech and non-real time packet-switched data

128 kbps active, and it is moving towards the boundary area of two cells.

The BTS is already transmitting the radio link with the maximum allowed downlink trans-

mission power. Typically, soft or softer handover is activated in this situation, which

improves the quality of the downlink direction. However, if neither soft, softer handover

nor hard handover improves the link budget, the quality of the radio link deteriorates

further. In such a scenario, it is feasible to initiate dynamic link optimisation and to

decrease the bit rate of a non-real time packet-switched radio access bearer from 128

kbps down to, for example, 64 kbps. This procedure ensures that the radio link quality

meets the requirements. Thus, the AMR 12.2 speech service can be continued without

interruption and possible radio link failure is avoided.

8.3.1 Dynamic link optimisation

Decision algorithm

The BTS periodically produces reports on the radio link conditions using an appropriate

NBAP procedure. The measurement report includes information on the average

downlink transmission code power of a radio link (Ptx, average).

The offset, defined by the Power offset for dynamic link optimisation (DLOptimisation-PwrOffset) management parameter, and the maximum downlink transmission code

power of a radio link (Ptx, max) together define the transmission power level, which

triggers dynamic link optimisation. The calculation of the maximum downlink transmis-

sion power of a radio link ( P tx, max) is performed using standard algorithms specified in

the WCDMA RAN RRM Admission Control.

The measured power (Ptx, average) added with the value of the offset is compared to the

maximum downlink transmission power (Ptx, max ). If Ptx, average and the offset (2 dB)

together exceed Ptx, max, as in the following inequality, dynamic link optimisation is trig-

gered.

(Ptx, ave + Offset) > Ptx, max

Averaged Ptx_average value can be used in the power usage estimation of the cell-specificPS for the dynamic link optimisation purpose. The averaged value is used to avoid a

ping-pong effect when downlink radio link power varies a lot.

DLORLAveragingWindowSize is a WBTS-specific RNC configuration parameter that

defines how many radio link-specific measurement results of the average transmission

power of the DPDCH bits (Ptx_average ) are included in the sliding window used in the

averaging of the cell-specific PS.

If the DLORLAveragingWindowSize RNP parameter is set to ‘On’, the Ptx_average is

averaged in the RNC by using the following formula:

Ptx_average =

Ptx_average (t) + Ptx_average (t - 1) +...+ Ptx_average (t - (n - 1))

n







DN0495772

Issue 14C

139


Id:0900d805807505ad

where P tx_average(t)is the power ([W]) of the DPDCH bits from the latest reported

P tx_average value and n equals to DLORLAveragingWindowSize.

If NRT DCH bit rate is upgraded, the sliding measurement window is filled by the value

of latest calculated P tx_average + ∆Ptx (estimated power change/increase).If NRT DCH bit rate is downgraded, the sliding measurement window is filled by the

value of latest calculated P tx_average - ∆Ptx (estimated power change/decrease).

If DLORLAveragingWindowSize RNP parameter is set to ‘Off’, only one sample, that is,

the last available downlink radio link power measurement result is used in estimation.



140 DN0495772

Issue 14C


Id:0900d805807505ad

Figure 76 Decision algorithm

Requirements for spreading factor (SF) and puncturing limit (PL)

The bit rates of non-real time dedicated transport channels (DCH) of the UE are reduced

by the amount required to increase the physical channel spreading factor (SF). The

Dynamic link optimisation usage (DLOptimisationUsage) management parameter

defines the required amount of increase of the spreading factor. For example, if the non-

real time bit rate 384 kbps is allocated to a user with the physical channel spreading

factor 8, and if the value of the Dynamic link optimisation usage (DLOptimisationUsage) management parameter is set to 1 (Feature is activated with SF step 1), a bit rate for

End

Downgrade not possible

No

Yes

No

Yes

No

Yes

No

Yes

No

Yes

Downgrade DCH bitrate(s)

Requirements OK(SF, puncturing)

Select DCH(s) to bedowngraded

MeasurementReportPtx,ave

(Ptx,ave + Offset)>Ptx,max

Compressed Modeactive

Guard timer active

DPCH bitrate >HHoMaxAllowedBitRate





DN0495772

Issue 14C

141


Id:0900d805807505ad

which a spreading factor of 16 or higher is suitable must be found to make dynamic link

optimisation possible. However, additional puncturing is not allowed when the radio link

is reconfigured, that is, puncturing must remain at least on the same level as before the

reconfiguration. Otherwise dynamic link optimisation is not allowed.

Dedicated channel selection

When the dynamic link optimisation has been triggered, the non-real time dedicated

channels to be downgraded are selected according to the QoS priority order (lowest

value first). In the case of several DCHs with the same priority, the owner of the highest

bit rate is reconfigured.

In case the priority order of the dedicated channels cannot be determined, the channels

to be reconfigured are selected randomly.

If downgrading of the NRT DCH bit rates to the minimum level, determined by the MinAl-

lowedBitRateDL parameter, is not enough to fulfil the spreading factor (SF) requirement,

a part or all of the DCHs can be downgraded to 0 kbps.

Functionality depends on the types of allocated DCHs. The radio link, which contains

only NRT RAB(s), is handled differently from the RL having also RT RAB(s) - either CS

or PS domain data - allocated.

The DCHs to be released are selected according to the following principles:

RT + NRT multi-RAB

• When the NRT DCH(s) in addition to the RT DCH(s) are allocated, all the NRT

DCH(s) can be downgraded to 0 kbps if it is needed to fulfil the SF requirement.

NRT RAB(s) only

• When only the NRT DCH(s) are allocated, at least one NRT DCH is left allocated. In

other words all the NRT DCH(s) must not be downgraded to 0 kbps.

If the priority order of the DCHs cannot be determined, the ones to be released are

randomly selected.

After the bit rate of the DCH has been downgraded because of dynamic link optimisa-

tion, an upgrade of the bit rate is based on downlink traffic volume measurements

(capacity requests), as explained in Packet Scheduler. Changes in the radio link power

conditions do not trigger an upgrade.

Dedicated channel bit rate upgrade

If a request to increase the non-real time dedicated channel bit rate or to set up a new

non-real time dedicated channel is received, the triggering of the dynamic link optimis-

ation is checked with the new requested bit rate before radio link modification and trans-

port format combination set (TFCS) reconfiguration procedures are performed, that is,

prior to the actual scheduling.

First, a new maximum downlink transmission power of the radio link P tx, max is calculated

for the new requested bit rate. Secondly, an initial downlink transmission power P tx, init is

calculated for the new requested bit rate. The determination of P tx, max and P tx, init is per-

formed by using standard algorithms specified in the WCDMA RAN RRM Admission

Control.

When P tx, max and P tx, init have been calculated, the following comparison is made and

the inequality must be valid:

P tx, init < (P tx, max — DLOptimisationPwrOffset) or









142 DN0495772

Issue 14C


Id:0900d805807505ad

P tx, init < (P tx, max — (DLOptimisationPwrOffset + Hysteresis)))

The quantity DLOptimisationPwrOffset is defined by the Power offset for dynamic link

optimisation (DLOptimisationPwrOffset ) management parameter. The variable

Hysteresis is defined by the PRFILE parameter 007:0291 RN40_MAINT_021 asfollows:

The latter comparison is made if the used radio link bit rate is decreased because of

dynamic link optimisation in that specific cell previously.

Note that the latter comparison is not used if the radio link is previously reconfigured

because of other features than dynamic link optimisation.If inequality is valid, that is, the calculated initial downlink transmission power is below

the triggering level of the dynamic link optimisation, the radio link can be modified.

If the inequality is not valid, the radio link cannot be modified with the requested bit rate,

but the next lower bit rate is tried. The similar comparison, described above, is per-

formed for the lower bit rate. The loop is repeated until the bit rate that satisfies the

inequality is found. In case there is no bit rate above the currently allocated bit rate that

satisfies the inequality, the non-real time dedicated channel bit rate is not increased but

radio link reconfiguration is rejected.

Guard time after dedicated channel bit rate allocation

After the bit rate of a non-real time dedicated channel has been increased or a new non-real time dedicated channel with greater than 0 kbps bit rate has been allocated, the

dynamic link optimisation cannot immediately be initiated. This is to avoid a back and

forth (ping-pong) modification of a dedicated channel user bit rate. The guard timer also

prevents consecutive downgrades because of dynamic link optimisation. The guard time

period during which the dynamic link optimisation is not initiated is defined by the

Dynamic Link Optimisation prohibit time (DLOptimisationProhibitTime ) manage-

ment parameter.

Power thresholds

The following figure illustrates the determination of the triggering level of dynamic link

optimisation. The service in the example is non-real time packet-switched 128 kbps

radio bearer.

PRFILE parameter 007:0291

RN40_MAINT_021value

Hysteresis [dB]

0 (default) 1.5 (fixed offset in use)

1 0.1

2 0.2

3 0.3

... ...

120 12

121 0 (offset not in use)

Table 30 The PRFILE parameter defines an additional offset (Hysteresis) to prevent

immediate upgrade if the radio link (DL DCH bit rate) has been down-

graded due to dynamic link optimisation in the cell.



DN0495772

Issue 14C

143


Id:0900d805807505ad

Figure 77 Example of triggering of dynamic link optimisation

The upper limit of the dynamic range of the radio link power control is determined by the

lowest of the Planned maximum downlink transmission power of a radio link (PtxDLab-

sMax) and DPCH downlink transmission power maximum value (PtxDPCHmax)param-

eters. In the example, admission control has calculated the maximum allowed radio link

power of a user as 41 dBm. The value is obtained by adding the power required by the

non-real time packet-switched 128 kbps service to the power planned to the reference

service, which is an AMR 12.2 speech call in the example. Note that the figure only

presents a simplified procedure. The maximum allowed radio link code power is deter-mined using standard algorithms, which are specified in detail in the WCDMA RAN RRM

Admission Control.

The triggering level of the dynamic link optimisation (39 dBm) is obtained by subtracting

the value of the offset (2 dB assumed in this example) from the maximum allowed power

of a radio link (41 dBm).

8.3.2 Interoperability

Compressed mode measurements

Dynamic link optimisation is not initiated if the current user bit rate of the radio link is

lower than or equal to the highest allowed bit rate to trigger compressed mode measure-ments because of high downlink dedicated physical channel (DPCH) power level. The

Maximum Allowed DL User Bitrate in HHO (HHoMaxAllowedBitrateDL) parameter

defines the threshold which the maximum allocated user bit rate on the downlink dedi-

cated physical channel (DPCH) cannot exceed in order for the inter-frequency or inter-

RAT handover to be possible because of high downlink dedicated physical channel

(DPCH) power. The following comparison is made and the inequality must be valid:

user_bitrate > HHoMaxAllowedBitrateDL

If the inequality is valid, dynamic link optimisation can be initiated. If the inequality is not

valid, dynamic link optimisation is not initiated.

Absolute max RL power (PtxDLabsMax, PtxDPCHmax)

Calculated max RL power for PS128 = 41 dBm

DyLO triggering level (Calculated max RL pwr - Offset = 39 dBm)

PtxPrimaryCPICH = 33dBm

PtxPrimaryCPICH – CPICHtoRefRABoffset= 31 dBm

+ 10 log (128/12.2)

DL power (dBm)







144 DN0495772

Issue 14C


Id:0900d805807505ad

Maximum radio link power

An initial power and a maximum allowed transmission power of a radio link are calcu-

lated in the admission phase (see WCDMA RAN RRM Admission Control). The radio

network planning parameters affecting the maximum allowed downlink transmissionpower of a radio link are PtxDLabsMax and PtxDPCHmax .

There is a risk that a high bit rate non-real time packet-switched service, for example, a

UE with a 384 kbps dedicated channel moving to the edge of a macro cell, allocates all

the BTS output transmission power. Therefore, the Planned maximum downlink trans-

mission power of a radio link (PtxDLabsMax) WCEL parameter, which determines the

planned maximum downlink transmission power of a radio link for non-real t ime packet-

switched service, has been introduced. The parameter is used in the DL power alloca-

tion of non-real time traffic class radio access bearers. The allocated power of a radio

link cannot exceed the value of this parameter. Using the parameter together with the

dynamic link optimisation feature enables the non-real time dedicated channel bit rate

to be reduced when high transmission power situation occurs. In the case of a real-timePS (streaming) and a non-real time PS multi service, the Maximum transmitted code

power of PS streaming RAB (PtxPSstreamAbsMax) parameter can limit the maximum

allowed downlink transmission power. For more information, see WCDMA RAN RRM

Admission Control.

The maximum value of the dedicated physical channel (DPCH) downlink transmission

power is determined by the DPCH downlink transmission power maximum value (PtxD-

PCHmax) parameter. It defines the maximum code channel output power for the BTS

power control dynamic range.

8.3.3 Restrictions

Radio link under control of DRNC

The SRNC controls triggering of the dynamic link optimisation. In practice, this means

that radio links under the control of the DRNC cannot trigger dynamic link optimisation.

Note that the soft handover mode does not prevent triggering of the dynamic link opti-

misation, only the radio link in the SRNC can trigger. Transport format combination set

reconfiguration is performed in every radio link of the UE, after SRNC has decided to

initiate dynamic link optimisation.

Compressed mode measurements

Dynamic link optimisation is not allowed during the compressed mode measurements.

8.3.4 Enhanced dynamic link optimisation for non-real time traffic

coverage

Enhanced dynamic link optimisation for non-real time traffic is supported in the DRNC if

RAN1759: Support for I-HSPA Sharing and Iur Mobility Enhancements feature is

enabled. The SRNC controls the triggering of the dynamic link optimisation. In practice,

it means that only RLs under the SRNC control can trigger dynamic link optimisation.

With enhanced dynamic link optimisation, the DRNC controls the triggering of dynamic

link optimisation for the RLs under DRNC.

Cell-specific packet scheduler in the DRNC must check if the guard timer is active before

enhanced dynamic link optimisation procedure is started. If the guard timer is active, the

DyLO checking is stopped.











DN0495772

Issue 14C

145


Id:0900d805807505ad

Activation of DL power optimization in the DRNC is the same as is SRNC. TFCS Recon-

figuration is started in the DRNC due to DL power optimisation.

Transmitted Code Power measurements in the DRNC are initiated by the SRNC via

RNSAP: DEDICATED MEASUREMENT INITIATION REQUEST message duringanchoring whenever a radio link is added in the DRNC. The following VBTS parameters

are used to initiate these measurements:

• DedicatedMeasReportPeriod

• DediMeasRepPeriodPSdata

• MeasFiltCoeff

Cell-specific packet scheduler in the DRNC uses averaged DPDCH code power of radio

link (Ptx_average), in case of radio link downlink transmission power comparison, for the

dynamic link optimisation purpose similarly as in the SRNC.

TFCS reconfiguration in a DRNC due to enhanced dynamic link optimisation

TFCS reconfiguration procedure in a DRNC follows the same principles as in a SRNC.The SRNC is informed aboute TFCS reconfiguration via RNSAP: CONGESTION INDI-

CATION message. The SRNC upon receiving the RNSAP: CONGESTION INDICA-

TION message informs the UE via RRC: Radio bearer reconfiguration or RRC:

Transport channel reconfiguration and DRNC via RNSAP: RADIO LINK RECONFIGU-

RATION.

TFCS reconfiguration is not allowed when the CM is ongoing. Downgrade is allowed to

be initiated if DPCH bit rate is above the CM triggering level.

Selection of the DCH to be downgraded due to dynamic link optimisation in a

DRNC

DCH selection principle followed in the SRNC is also followed in the DRNC. If the SRNCdoes not support RNSAP: CONGESTION PROCEDURE, then dynamic link optimisa-

tion is stopped or not performed for the corresponding radio link.

In case a request to increase NRT DCH bit rate or to setup a new NRT DCH is received,

the triggering of the dynamic link optimisation (DyLO) is checked with the new requested

bit rate before RL modification and TFCS reconfiguration procedures are performed,

that is, prior to the actual scheduling. If the new requested NRT DCH bit rate triggers

dynamic link optimisation, the DRNC rejects the RL reconfiguration procedure.



146 DN0495772

Issue 14C


Id:0900d8058074ca9a

8.4 Reduction of NRT signalling load with NRT DCH maximum

bit rate modification

The packet scheduler algorithm schedules packet data DCHs based on estimations of

free uplink and downlink interference capacity. When the packet scheduler allocates a

low or a high bit rate, or upgrades a low bit rate to a high bit rate, it can happen that the

capacity is allocated successfully by the cell-specific PS, but congestion of the HW or

transmission resources occurs. This leads to a situation where unnecessary signalling

between the RNC and the BTS significantly increases the load of the ICSU. Unneces-

sary signalling between the RNC and the BTS can also lead to a situation where the BTS

buffers messaging inside the BTS and the response to these messages from the BTS

is delayed.

Unnecessary signalling and thus the ICSU load can be decreased by limiting the

maximum bit rate of the BTS when congestion occurs. The maximum bit rate is

increased to the normal level when the congestion situation is over.

The ICSU load is decreased by the UE-specific and the cell-specific packet schedulers

as follows:

• The UE-specific PS rejects the capacity requests from the UE and the MAC-d entity

of the RNC if the capacity allocation has failed in the DRNC or due to lack of SRNC

HW resources. For more information, see UE-specific packet scheduler rejects the

capacity request reattempts sent by the UE .

• The maximum bit rate of the BTS is decreased/increased by the cell-specific packet

scheduler. The decrease/increase is based on the number of rejected capacity

requests during a predefined time. For more information, see Cell-specific packet

scheduler modifies the temporary maximum bit rate.

UE-specific packet scheduler rejects capacity request reattempts sent by the UE

or the MAC-d entity of the RNC

When BTS HW or transmission congestion occurs, the UE-specific packet scheduler

triggers reattempts to allocate NRT DCHs with decreased bit rate. For more information,

see Traffic volume measurements and Figure Reattempt of NRT DCH allocation with

decreased bit rate.

The number of successive reattempts of capacity requests is restricted in the UE with

the TrafVolPendingTime timer. This means that the capacity request can be repeated

by the UE when the timer expires.

Upon reception of an uplink or downlink capacity request, the UE-specific PS starts the

Capacity Request Rejection timer if the capacity allocation fails due to:• an unspecified error or congestion in a branch that is located in the DRNC

Such situation may occur if one or more cells in the active set are located in the

SRNC and DRNC.

• HW (DSP) of SRNC.

The Capacity Request Rejection timer has the fixed value 6 s. While the timer is

running, capacity requests are rejected by the UE-specific PS. However, if the number

of rejected capacity requests during the time interval defined with Capacity Request

Rejection timer reaches two, the timer is stopped and the capacity requests are

accepted again by the UE-specific PS.



DN0495772

Issue 14C

147


Id:0900d8058074ca9a

Cell-specific packet scheduler modifies the temporary maximum bit rate

The BTS-specific temporary maximum bit rate is modified by the cell-specific PS based

on the number of rejected capacity requests because of congestion. The three different

values for temporary maximum bit rates are:• temporary maximum bit rate of the BTS for both UL and DL directions

This bit rate is determined by calculating the number of rejected capacity requests

because of BTS HW congestion during a predefined time interval.

• temporary maximum bit rate of the BTS for DL


because of uplink transmission congestion during a predefined time interval.

• temporary maximum bit rate of the BTS for UL


because of downlink transmission congestion during a predefined time interval.

In the uplink NRT DCH allocation, the temporary maximum bit rate is MIN(MaxBitRa-

teULPSNRT , temporary maximum bit rate of the BTS for both directions and temporary

maximum bit rate of the BTS for the uplink direction). This minimum value is used as a

temporary maximum bit rate at the scheduling moment.

In the downlink NRT DCH allocation, the temporary maximum bit rate is defined as

MIN(MaxBitRateDLPSNRT , temporary maximum bit rate of the BTS for both directions

and temporary maximum bit rate of the BTS for the downlink direction). This minimum

value is used as a temporary maximum bit rate at the scheduling moment.

If the maximum allowed bit rate in the cell at the scheduling moment is lower than the

initial bit rate set for uplink and downlink respectively by the RNC configuration param-

eters Initial bit rate in uplink (InitialBitRateUL) and Initial bit rate in downlink (InitialBitRat-

eDL), the cell-specific PS rejects the received capacity requests.

The numbers in parenthesis in the following description of the temporary maximum bit

rate of the BTS refer to the example in Figure 78 Modification of the maximum temporary

bit rate of a BTS.

The number of PS NRT DCH setups rejected due to BTS HW congestion during a

sample period (2.) is calculated and the sum represents a sample (1.) of the rejected

capacity requests. The sample includes all retried PS NRT DCH setups that were

rejected due to BTS HW congestion during this sample period except those caused by

the temporary maximum bit rate of the BTS. The length of the sample period is fixed and

set to be equal to 200 ms.

The sliding window measurement is used when calculating the rejected capacity

requests. The size of the measurement window, that is the number of samples in onesample period is set to the fixed value 5 (3.). When the measurement window is full of

samples, the measurement window is shifted in each sample period so that the samples

of the oldest sample period are removed from the last location and the ones of the new

sample period are placed to the first location of the window (4.).

Initially, the temporary maximum bit rate of the BTS (5.) in question is the highest

maximum supported bit rate.

The temporary maximum bit rate of the BTS is decreased by one step if the sum of

samples is equal to or higher than the step down threshold (6.). The step down threshold

is a fixed value, 10 rejected capacity requests.



148 DN0495772

Issue 14C


Id:0900d8058074ca9a

The temporary maximum bit rate of the BTS in question is increased by one step if the

sum of samples is lower than or equal to the step up threshold (7.) The step up threshold

is a fixed value, 2 rejected capacity requests.

One step up or down is the next lower or higher supported downlink maximum bit rate.Supported maximum bit rates are fixed values, see WCDMA RAN RRM Admission

Control.

Figure 78 Modification of the maximum temporary bit rate of a BTS

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

8

16

32

64

128

384

2

4

6

8

10

12

14

Bit Rate[kbps]

Time[Sample period]

Amount of

rejected CRrequest

0

(4.) Measurement window sizeand sliding of the measurementwindow at every sample period

(1.) Sum of the rejected NRTDCH capacity request

in one sample period

(7.) Maximum bit rateof the BTS stepup threshold

(3.) Sum of the rejected NRTDCH capacity requests during

the last five sample periods

(6.) Maximum bit rate of theBTS step down threshold

(5.) Temporary maximum bitrate of the BTS due

to HW congestion

(2.)

Sampleperiod







DN0495772

Issue 14C

149


Id:0900d805805dca74

8.5 PS NRT RAB reconfiguration

With the PS NRT RAB reconfiguration feature, the SGSN or the UE can request to

modify the characteristics of a RAB service by using the RAB reconfiguration procedure.

In the RAN, the core network triggers the reconfiguration of an existing RAB with aRANAP: RAB ASSIGNMENT REQUEST message. The following QoS parameters can

be changed for interactive and background traffic class RABs:

• Allocation and Retention Priority (ARP)

• Traffic Class (TC) interactive or background

• Traffic Handling Priority (THP) of an interactive RAB

• Maximum Bit Rate (MBR) for UL and DL

The RAB to be modified is identified by the RAB Id. Multiple RAB Ids can be sent in a

RANAP: RAB ASSIGNMENT REQUEST message. If the PS core network requests any

parameter modification other than the above specified parameters, the RNC responses

with a RANAP: RAB ASSIGNMENT RESPONSE message including the cause code“Invalid RAB Parameters Combination”.

The handling of the RAB modification request within the RNC depends on:

• state of the UE: URA/Cell_PCH, Cell_FACH, or Cell_DCH

• direction of the QoS parameter change: downgrade or upgrade

• UE services: DCH or HSPA services

These criteria result in the following actions:

1. In URA/Cell_PCH state, the RANAP: RAB ASSIGNMENT REQUEST message

does not initiate the paging procedure when it requests to modify NRT RAB param-

eters. The RNC only stores the RAB parameters.

2. In Cell_FACH state, the new RAB parameters are taken into use when the statetransition is made from Cell_FACH to Cell_DCH state.

3. When the UE has an active DCH service, the handling depends on the requested

RAB modification:

• For the QoS priority parameters traffic handling priority, allocation and retention

priority, and traffic class, the new parameters are taken into use immediately. In

that case the UE specific packet scheduler maps these parameters to the

related QoSPriorityMapping management parameter and sends it to the cell

specific packet scheduler. This new QoS priority value is used to prioritise the

PS NRT RAB.

• When the QoS parameters traffic class and/or traffic handling priority are

changed, a new Frame Handling Priority (FHP) is calculated by the UE specificpacket scheduler and sent to the cell specific packet scheduler which calculates

the UL DCH load factor. In the next scheduling period, the UE specific packet

scheduler sends the new FHP to the WBTS.

• If the maximum bit rate is increased, the new maximum bit rate is taken into use

when the new capacity request is received from the UE or the MAC-d of the

RNC. The traffic volume measurement is started as described in Section Traffic

volume measurements if it is not yet existing.

• If the new maximum bit rate is lower than the currently used bit rate, the DCH is

downgraded to new RAB maximum bit rate. If the new RAB maximum bit rate is

not supported, the next supported bit rate is used which is lower than the new

maximum bit rate.



150 DN0495772

Issue 14C


Id:0900d805805dca74

4. Furthermore, the new RAB parameters are taken into use immediately in the follow-

ing cases:

• The RAB transfers in an HSPA configuration and the upgrade/downgrade of the

maximum bit rate and/or the modification of other RAB parameters is requested.• The RAB transfers in the DCH configuration and the downgrade of the maximum

bit rate and/or the modification of other RAB parameters is requested.

For more information on PS NRT RAB modification handling for DCH/HS-DSCH

services see WCDMA RAN RRM HSDPA.





DN0495772

Issue 14C

151

WCDMA RAN RRM Packet Scheduler Features per release

Id:0900d805805dca79

9 Features per releaseFor an overview of features related to radio resource management see Features per

release in WCDMA RAN Radio Resource Management Overview . The features are

arranged according to the release in which they were introduced. Note that a feature

may belong to more than one functional area.

http://wran_fad_rrm_overview.pdf/






152 DN0495772

Issue 14C


Id:0900d8058065d474

Management data for packet scheduler

10 Management data for packet scheduler

10.1 AlarmsThere are no alarms named for packet scheduler features but the active faults in the

system can affect different quality indicators indirectly. Please keep in mind that all faults

in the system indicated by alarms should be analyzed. An alarm that indicates that a

WBTS, WCEL or RNC functional unit is instable/unavailable can affect indirectly admis-

sion control functionality.

For alarm descriptions, see Alarms and BTS Faults in the Nokia Siemens Networks

WCDMA RAN System Documentation sets.

All RAN alarms are categorised so that each alarm has an alarm number belonging to

one of the following categories:

Alarms triggered by the RNC:• 1-999 Notices

• 1000-1999 Disturbances

• 2000-3999 Failure Printouts (*,**,*** alarms)

Alarms triggered by Base Station and RNC:

• 7000-7999 Base Station Alarms

• 7401-7699 Base Station Alarms triggered by Base Stations

• 7700-7799 Base Station Alarms triggered by RNC

10.2 Counters

This section lists the counters per feature. See also RNC counters - RNW part.

There are no counters related to the following features:

• RAN866: Dynamic link optimisation for NRT traffic coverage

• RAN919: Decrease of the retried NRT DCH bit rate

• RAN1039: Lightweight flexible upgrade of NRT DCH data rate

• RAN920: Selective NRT DCH data rate set

• RAN2.0107: RRC connection re-establishment

• RAN242: Flexible upgrade of NRT DCH data rate

• RAN1759: Support for I-HSPA Sharing and Iur Mobility Enhancements

The following measurement types are relevant to the packet scheduler:

Cell resource

Packet scheduler-related measuring: channel selection (counters: Measuring the RACH

channel, measuring the SCCPCH channel).

The counters for cell resource measurement are found in Using RNW Measurement

Presentation in RNC Measurement Presentation in RN3.0 .

Traffic

Packet scheduler-related measuring: cell-specific part of PS; capacity requests, bit rate

allocation, reducing bit rates (counters: requests for DCHs, RT/NRT DCH allocations).

http://count_rnc_count_rnw_part.pdf/

http://onm_mnm_mang_rnc_meas.pdf/






http://count_rnc_count_rnw_part.pdf/



DN0495772

Issue 14C

153

WCDMA RAN RRM Packet Scheduler Management data for packet scheduler

Id:0900d8058065d474

The counters for traffic measurement are found in Using RNW Measurement Presenta-

tion in RNC Measurement Presentation in RN3.0 .

RRC signalling

Packet scheduler-related measuring: UE-specific part of PS; traffic volume measure-

ment reports, uplink, downlink (counters: measurement report control, packet data

transfer states).

The counters for RRC signalling measurement are found in Using RNW Measurement

Presentation in RNC Measurement Presentation in RN3.0 .

10.2.1 RAN1.029: Packet scheduler algorithm

PI ID Name Abbreviation

M1000C24 AVE LRT CLASS 0 AVE_LRT_CLASS_0

M1000C25 LRT DENOM 0 LRT_DENOM_0








M1000C33 LRT DENOM 4 LRT_DENOM_4M1000C34 AVE LNRT CLASS 0 AVE_LNRT_CLASS_0

M1000C35 LNRT DENOM 0 LNRT_DENOM_0

M1000C36 AVE LNRT CLASS 1 AVE_LNRT_CLASS_1








M1000C44 AVE PTX NRT CLASS 0 AVE_PTX_NRT_CLASS_0

M1000C45 PTX NRT DENOM 0 PTX_NRT_DENOM_0





Table 31 Cell resource measurements for the packet scheduling algorithm













154 DN0495772

Issue 14C


Id:0900d8058065d474






M1000C89 AVE TRX FOR RL IN CELL AVE_TRX_FOR_RL_IN_CELL

M1000C90 NBR OF RLS NBR_OF_RLS

M1000C91 SUM SQR TRX FOR RL IN CELL SUM_SQR_FOR_RL_IN_CELL

M1000C92 NBR OF RL MEAS REPS NBR_OF_RL_MEAS_REPS

M1000C93 AVE PTX RT CLASS 0 AVE_PTX_RT_CLASS_0

M1000C94 PTX RT DENOM 0 PTX_RT_DENOM_0

M1000C95 AVE PTX RT CLASS 1 AVE_PTX_RT_CLASS_1M1000C96 PTX RT DENOM 1 PTX_RT_DENOM_1







M1000C232 MINIMUM PTXTARGETPS MIN_PTX_TARGET_PS

M1000C233 MAXIMUM PTXTARGETPS MAX_PTX_TARGET_PS

M1000C234 AVERAGE PTXTARGETPS AVE_PTX_TARGET_PS

M1000C235 PTXTARGETPS DENOM PTX_TARGET_PS_DENOM


Table 31 Cell resource measurements for the packet scheduling algorithm (Cont.)


M1002C0 DCH REQ FOR SIG LINK IN SRNC DCH_REQ_LINK_SRNC

M1002C1 DCH REQ FOR SIG LINK REJECT IN UL IN

SRNC

DCH_REQ_LINK_REJ_UL_SRNC

M1002C2 DCH REQ FOR SIG LINK REJECT IN DL IN

SRNC

DCH_REQ_LINK_REJ_DL_SRNC

M1002C3 DCH REQ FOR RRC CONN IN SRNC DCH_REQ_RRC_CONN_SRNC

M1002C4 DCH DHO REQ FOR SIG LINK IN SRNC DCH_DHO_REQ_LINK_SRNC

M1002C5 DCH DHO REQ FOR SIG LINK REJECT IN

SRNC

DCH_DHO_REQ_LINK_REJ_SRNC

M1002C6 DCH ALLO FOR SIG LINK 1.7 KBPS IN SRNC DCH_ALLO_LINK_1_7_SRNC



Table 32 Traffic measurements for the packet scheduling mechanism



DN0495772

Issue 14C

155


Id:0900d8058065d474

M1002C9 DCH ALLO DURA FOR SIG LINK 1.7 KBPS IN

SRNC

DCH_ALLO_DURA_LINK_1_7_SRNC

M1002C10 DCH ALLO DURA FOR SIG LINK 3.4 KBPS INSRNC



SRNC


M1002C12 RT DCH REQ FOR CS VOICE CALL IN SRNC REQ_CS_VOICE_IN_SRNC

M1002C13 RT DCH REQ FOR CS VOICE CALL REJECT

IN UL IN SRNC

REQ_CS_VOICE_REJ_UL_SRNC


IN DL IN SRNC

REQ_CS_VOICE_REJ_DL_SRNC

M1002C15 RT DCH INIT REQ FOR CS VOICE CALL IN

SRNC

RT_DCH_INIT_VOICE_SRNC

M1002C16 RT DCH DHO REQ FOR CS VOICE CALL IN

SRNC

REQ_CS_VOICE_SRNC

M1002C17 RT DCH DHO REQ FOR CS VOICE CALL

REJECT IN SRNC

REQ_CS_VOICE_REJ_SRNC

M1002C50 RT DCH REQ FOR CS DATA CALL CONV

CLASS IN SRNC

REQ_CS_DATA_CONV_SRNC

M1002C51 RT DCH REQ FOR CS DATA CALL STREAM

CLASS IN SRNC

REQ_CS_STREAM_SRNC

M1002C52 RT DCH REQ FOR CS DATA CALL CONV

CLASS REJECT IN UL IN SRNC

REQ_CS_CONV_REJ_UL_SRNC

M1002C53 RT DCH REQ FOR CS DATA CALL CONVCLASS REJECT IN DL IN SRNC

REQ_CS_CONV_REJ_DL_SRNC


CLASS REJECT IN UL IN SRNC

REQ_CS_STREAM_REJ_UL_SRNC


CLASS REJECT IN DL IN SRNC

REQ_CS_STREAM_REJ_DL_SRNC

M1002C56 RT DCH INI REQ FOR CS DATA CALL CONV

CLASS IN SRNC

INI_REQ_CS_DATA_CONV_SRNC

M1002C57 RT DCH INI REQ FOR CS DATA CALL

STREAM CLASS IN SRNC

INI_REQ_CS_STREAM_UL_SRNC

M1002C58 RT DCH DHO REQ FOR CS DATA CALL

CONV CLASS IN SRNC

RT_REQ_DATA_CONV_SRNC

M1002C59 RT DCH DHO REQ FOR CS DATA CALL CONV

CLASS REJECT IN SRNC

RT_REQ_DATA_CONV_REJ_SRNC



RT_REQ_DATA_STREAM_SRNC


STREAM CLASS REJECT IN SRNC

RT_REQ_DATA_STREAM_REJ_SRNC

M1002C62 RT DCH ALLO FOR TRANS CS DATA CONV

CLASS 28.8 KBPS IN SRNC

ALLO_TRAN_CS_CONV_28_8_SRNC


Table 32 Traffic measurements for the packet scheduling mechanism (Cont.)



156 DN0495772

Issue 14C


Id:0900d8058065d474



CLASS 32 KBPS IN SRNC

ALLO_TRAN_CS_CONV_32_IN_SRNC

M1002C64 RT DCH ALLO FOR TRANS CS DATA CONVCLASS 33.6 KBPS IN SRNC

ALLO_TRAN_CS_CONV_33_6_SRNC


CLASS 64 KBPS IN SRNC

ALLO_TRAN_CS_CONV_64_IN_SRNC

M1002C66 RT DCH ALLO DUR FOR TRANS CS DATA

CONV CLASS 28.8 KBPS IN SRNC

ALLO_DUR_CS_CONV_28_8_SRNC


CONV CLASS 32 KBPS IN SRNC

ALLO_DUR_CS_CONV_32_IN_SRNC


CONV CLASS 33.6 KBPS IN SRNC

ALLO_DUR_CS_CONV_33_6_SRNC


CONV CLASS 64 KBPS IN SRNC

ALLO_DUR_CS_CONV_64_IN_SRNC

M1002C70 RT DCH ALLO FOR NONTRANS CS DATA

STREAM CLASS 14.4 KBPS IN UL IN SRNC

ALLO_NTRANS_STREAM_14_4_UL








STREAM CLASS 14.4 KBPS IN DL IN SRNC

ALLO_NTRANS_STREAM_14_4_DL







M1002C76 RT DCH ALLO DUR FOR NONTRANS CS

DATA STREAM CLASS 14.4 KBPS IN UL IN

SRNC

ALLO_DUR_NTRANS_STRM_14_4_UL



SRNC




SRNC



DATA STREAM CLASS 14.4 KBPS IN DL IN

SRNC

ALLO_DUR_NTRANS_STRM_14_4_DL



SRNC




SRNC






DN0495772

Issue 14C

157


Id:0900d8058065d474

M1002C82 RT DCH REQ FOR PS CALL CONV CLASS IN

SRNC

REQ_FOR_PS_CONV_SRNC

M1002C83 RT DCH REQ FOR PS CALL STREAM CLASSIN SRNC

REQ_FOR_PS_STREAM_SRNC

M1002C84 NRT DCH REQ FOR PS CALL INTERA CLASS

IN UL IN SRNC

REQ_FOR_PS_INTERA_UL_SRNC


IN DL IN SRNC

REQ_FOR_PS_INTERA_DL_SRNC

M1002C86 NRT DCH REQ FOR PS CALL BACKG CLASS

IN UL IN SRNC

REQ_FOR_PS_BACKG_UL_SRNC


IN DL IN SRNC

REQ_FOR_PS_BACKG_DL_SRNC

M1002C88 RT DCH REQ FOR PS CALL CONV CLASS

REJECT IN UL IN SRNC

REQ_PS_CONV_REJ_UL_SRNC

M1002C89 RT DCH REQ FOR PS CALL CONV CLASS

REJECT IN DL IN SRNC

REQ_PS_CONV_REJ_DL_SRNC

M1002C90 RT DCH REQ FOR PS CALL STREAM CLASS


REQ_PS_STREAM_REJ_UL_SRNC

M1002C91 RT DCH REQ FOR PS CALL STREAM CLASS


REQ_PS_STREAM_REJ_DL_SRNC



REQ_PS_INTERA_REJ_UL_SRNC



REQ_PS_INTERA_REJ_DL_SRNC



REQ_PS_BACKG_REJ_UL_SRNC



REQ_PS_BACKG_REJ_DL_SRNC

M1002C96 RT DCH INI REQ FOR PS CALL CONV CLASS

IN SRNC

INI_REQ_PS_CONV_SRNC

M1002C97 RT DCH INI REQ FOR PS CALL STREAM

CLASS IN SRNC

INI_REQ_PS_STREAM_UL_SRNC

M1002C98 NRT DCH INI REQ FOR PS CALL INTERA

CLASS IN UL IN SRNC

INI_REQ_PS_INTERA_UL_SRNC

M1002C99 NRT DCH INI REQ FOR PS CALL INTERA

CLASS IN DL IN SRNC

INI_REQ_PS_INTERA_DL_SRNC

M1002C100 NRT DCH INI REQ FOR PS CALL BACKGR

CLASS IN UL IN SRNC

INI_REQ_PS_BACKGR_UL_SRNC

M1002C101 NRT DCH INI REQ FOR PS CALL BACKGR

CLASS IN DL IN SRNC

INI_REQ_PS_BACKGR_DL_SRNC

M1002C102 RT DCH DHO REQ FOR PS CALL CONV

CLASS IN SRNC

RT_REQ_PS_CONV_SRNC

M1002C103 RT DCH DHO REQ FOR PS CALL CONV


RT_REQ_PS_CONV_REJ_SRNC





158 DN0495772

Issue 14C


Id:0900d8058065d474


M1002C104 RT DCH DHO REQ FOR PS CALL STREAM

CLASS IN SRNC

RT_REQ_PS_STREAM_SRNC

M1002C105 RT DCH DHO REQ FOR PS CALL STREAMCLASS REJECT IN SRNC

RT_REQ_PS_STREAM_REJ_SRNC

M1002C106 NRT DCH DHO REQ FOR PS CALL INTERA

CLASS IN SRNC

NRT_REQ_PS_INTERA_SRNC

M1002C107 NRT DCH DHO REQ FOR PS CALL INTERA


NRT_REQ_PS_INTERA_REJ_SRNC

M1002C108 NRT DCH DHO REQ FOR PS CALL BACKG

CLASS IN SRNC

NRT_REQ_PS_BACKG_SRNC

M1002C109 NRT DCH DHO REQ FOR PS CALL BACKG


NRT_REQ_PS_BACKG_REJ_SRNC

M1002C110 RT DCH ALLO FOR PS CALL CONV CLASS 8

KBPS IN UL IN SRNC

ALLO_PS_CONV_8_UL_IN_SRNC


KBPS IN UL IN SRNC



KBPS IN UL IN SRNC



KBPS IN UL IN SRNC


M1002C114 RT DCH ALLO FOR PS CALL CONV CLASS

128 KBPS IN UL IN SRNC












KBPS IN DL IN SRNC

ALLO_PS_CONV_8_DL_IN_SRNC


KBPS IN DL IN SRNC



KBPS IN DL IN SRNC



KBPS IN DL IN SRNC



128 KBPS IN DL IN SRNC















DN0495772

Issue 14C

159


Id:0900d8058065d474

M1002C126 RT DCH ALLO FOR PS CALL STREAM CLASS


ALLO_PS_STREAM_8_UL_IN_SRNC

M1002C127 RT DCH ALLO FOR PS CALL STREAM CLASS16 KBPS IN UL IN SRNC










ALLO_PS_STREAM_128_UL_SRNC












ALLO_PS_STREAM_8_DL_IN_SRNC












ALLO_PS_STREAM_128_DL_SRNC










M1002C142 NRT DCH ALLO FOR PS CALL INTERA CLASS


ALLO_PS_INTERA_8_UL_IN_SRNC












ALLO_PS_INTERA_128_UL_SRNC








160 DN0495772

Issue 14C


Id:0900d8058065d474





M1002C149 NRT DCH ALLO FOR PS CALL INTERA CLASS384 KBPS IN UL IN SRNC




ALLO_PS_INTERA_8_DL_IN_SRNC












ALLO_PS_INTERA_128_DL_SRNC










M1002C158 NRT DCH ALLO FOR PS CALL BACKG CLASS


ALLO_PS_BACKG_8_UL_IN_SRNC
























ALLO_PS_BACKG_8_DL_IN_SRNC














DN0495772

Issue 14C

161


Id:0900d8058065d474




M1002C171 NRT DCH ALLO FOR PS CALL BACKG CLASS256 KBPS IN DL IN SRNC








M1002C174 RT DCH ALLO DUR FOR PS CALL CONV

CLASS 8 KBPS IN UL IN SRNC

DUR_PS_CONV_8_UL_IN_SRNC























CLASS 8 KBPS IN DL IN SRNC

DUR_PS_CONV_8_DL_IN_SRNC






















M1002C190 RT DCH ALLO DUR FOR PS CALL STREAM


DUR_PS_STREAM_8_UL_IN_SRNC








162 DN0495772

Issue 14C


Id:0900d8058065d474





M1002C193 RT DCH ALLO DUR FOR PS CALL STREAMCLASS 64 KBPS IN UL IN SRNC
















DUR_PS_STREAM_8_DL_IN_SRNC






















M1002C206 NRT DCH ALLO DUR FOR PS CALL INTERA


DUR_PS_INTERA_8_UL_IN_SRNC


























DN0495772

Issue 14C

163


Id:0900d8058065d474



DUR_PS_INTERA_8_DL_IN_SRNC

M1002C215 NRT DCH ALLO DUR FOR PS CALL INTERACLASS 16 KBPS IN DL IN SRNC




















M1002C222 NRT DCH ALLO DUR FOR PS CALL BACKG


DUR_PS_BACKG_8_UL_IN_SRNC
























DUR_PS_BACKG_8_DL_IN_SRNC




















164 DN0495772

Issue 14C


Id:0900d8058065d474





M1002C237 NRT DCH ALLO DUR FOR PS CALL BACKGCLASS 384 KBPS IN DL IN SRNC


M1002C238 DCH REQ FOR SIG LINK IN DRNC DCH_REQ_SIG_LINK_DRNC

M1002C239 DCH REQ FOR SIG LINK REJECT IN UL IN

DRNC

DCH_REQ_SIG_LINK_UL_DRNC

M1002C240 DCH REQ FOR SIG LINK REJECT IN DL IN

DRNC

DCH_REQ_SIG_LINK_DL_DRNC

M1002C241 DCH DHO REQ FOR SIG LINK IN DRNC DCH_DHO_REQ_SIG_LINK_DRNC

M1002C242 DCH DHO REQ FOR SIG LINK REJECT IN

DRNC

DCH_REQ_SIG_LINK_REJ_DRNC

M1002C243 DCH ALLO FOR SIG LINK 1.7 KBPS IN DRNC DCH_ALLO_SIG_LINK_1_7_DRNC




DRNC

DCH_ALLO_DURA_LINK_1_7_DRNC


DRNC



DRNC


M1002C249 RT DCH REQ FOR CS VOICE CALL IN DRNC REQ_CS_VOICE_IN_DRNC


IN UL IN DRNC

REQ_CS_VOICE_REJ_UL_IN_DRNC


IN DL IN DRNC

REQ_CS_VOICE_REJ_DL_IN_DRNC

M1002C252 RT DCH DHO REQ FOR CS VOICE CALL IN

DRNC

RT_REQ_CS_VOICE_DRNC

M1002C253 RT DCH DHO REQ FOR CS VOICE CALL

REJECT IN DRNC

RT_REQ_CS_VOICE_REJ_DRNC

M1002C286 DCH REQ FOR DATA CALL IN DRNC REQ_DATA_IN_IN_DRNC

M1002C287 DCH REQ FOR DATA CALL REJECT IN UL IN

DRNC

REQ_DATA_REJ_IN_UL_IN_DRNC

M1002C288 DCH REQ FOR DATA CALL REJECT IN DL IN

DRNC

REQ_DATA_REJ_IN_DL_IN_DRNC

M1002C289 DCH DHO REQ FOR DATA CALL IN DRNC DCH_DHO_REQ_DATA_DRNC

M1002C290 DCH DHO REQ FOR DATA CALL REJECT IN

DRNC

DCH_DHO_REQ_DATA_REJ_DRNC

M1002C291 DCH ALLO FOR DATA CALL 8 KBPS IN UL IN

DRNC

ALLO_FOR_DATA_8_UL_IN_DRNC

M1002C292 DCH ALLO FOR DATA CALL 14.4 KBPS IN UL

IN DRNC

ALLO_FOR_DATA_14_4_UL_DRNC





DN0495772

Issue 14C

165


Id:0900d8058065d474

M1002C293 DCH ALLO FOR DATA CALL 16 KBPS IN UL

IN DRNC


M1002C294 DCH ALLO FOR DATA CALL 28.8 KBPS IN ULIN DRNC



IN DRNC



IN DRNC



IN DRNC



IN DRNC



IN DRNC



IN DRNC



IN DRNC



IN DRNC


M1002C303 DCH ALLO FOR DATA CALL 8 KBPS IN DL IN

DRNC

ALLO_FOR_DATA_8_DL_IN_DRNC

M1002C304 DCH ALLO FOR DATA CALL 14.4 KBPS IN DL

IN DRNC

ALLO_FOR_DATA_14_4_DL_DRNC

M1002C305 DCH ALLO FOR DATA CALL 16 KBPS IN DL

IN DRNC



IN DRNC



IN DRNC



IN DRNC



IN DRNC



IN DRNC



IN DRNC



IN DRNC



IN DRNC



IN DRNC






166 DN0495772

Issue 14C


Id:0900d8058065d474


M1002C315 DCH ALLO DURA FOR DATA CALL 8 KBPS IN

uL IN DRNC

DURA_FOR_DATA_8_UL_IN_DRNC

M1002C316 DCH ALLO DURA FOR DATA CALL 14.4KBPS IN UL IN DRNC

DURA_FOR_DATA_14_4_UL_DRNC

M1002C317 DCH ALLO DURA FOR DATA CALL 16 KBPS

IN UL IN DRNC


M1002C318 DCH ALLO DURA FOR DATA CALL 28.8

KBPS IN UL IN DRNC



IN UL IN DRNC



KBPS IN UL IN DRNC



KBPS IN UL IN DRNC



IN UL IN DRNC



IN UL IN DRNC



IN UL IN DRNC



IN UL IN DRNC



IN UL IN DRNC


M1002C327 DCH ALLO DURA FOR DATA CALL 8 KBPS IN

DL IN DRNC

DURA_FOR_DATA_8_DL_IN_DRNC


KBPS IN DL IN DRNC

DURA_FOR_DATA_14_4_DL_DRNC


IN DL IN DRNC



KBPS IN DL IN DRNC



IN DL IN DRNC



KBPS IN DL IN DRNC



KBPS IN DL IN DRNC



IN DL IN DRNC



IN DL IN DRNC



IN DL IN DRNC






DN0495772

Issue 14C

167


Id:0900d8058065d474


IN DL IN DRNC


M1002C338 DCH ALLO DURA FOR DATA CALL 384 KBPSIN DL IN DRNC


M1002C339 DCH HHO REQ FOR SIG LINK IN SRNC DCH_HHO_REQ_LINK_SRNC

M1002C340 DCH HHO REQ FOR SIG LINK REJECT IN

SRNC

DCH_HHO_REQ_LINK_REJ_SRNC

M1002C341 RT DCH HHO REQ FOR CS VOICE CALL IN

SRNC

REQ_CS_VOICE_HHO_SRNC

M1002C342 RT DCH HHO REQ FOR CS VOICE CALL

REJECT IN SRNC

REQ_CS_VOICE_HHO_REJ_SRNC

M1002C343 RT DCH HHO REQ FOR CS DATA CALL CONV

CLASS IN SRNC

RT_REQ_DATA_CONV_HHO_SRNC

M1002C344 RT DCH HHO REQ FOR CS DATA CALL CONV


RT_REQ_DATA_CNV_HHO_REJ_SRNC

M1002C345 RT DCH HHO REQ FOR CS DATA CALL


RT_REQ_DATA_STREAM_HHO_SRNC

M1002C346 RT DCH HHO REQ FOR CS DATA CALL

STREAM CLASS REJECT IN SRNC

RT_REQ_DATA_STRM_HHO_RJ_SRNC

M1002C347 RT DCH HHO REQ FOR PS CALL CONV

CLASS IN SRNC

RT_REQ_PS_CONV_HHO_SRNC

M1002C348 RT DCH HHO REQ FOR PS CALL CONV


RT_REQ_PS_CONV_HHO_REJ_SRNC

M1002C349 RT DCH HHO REQ FOR PS CALL STREAMCLASS IN SRNC

RT_REQ_PS_STREAM_HHO_SRNC

M1002C350 RT DCH HHO REQ FOR PS CALL STREAM


RT_REQ_PS_STRM_HHO_REJ_SRNC

M1002C351 NRT DCH HHO REQ FOR PS CALL INTERA

CLASS IN SRNC

NRT_REQ_PS_INTERA_HHO_SRNC

M1002C352 NRT DCH HHO REQ FOR PS CALL INTERA


NRT_REQ_PS_INT_HHO_REJ_SRNC

M1002C353 NRT DCH HHO REQ FOR PS CALL BACKG

CLASS IN SRNC

NRT_REQ_PS_BACKG_HHO_SRNC

M1002C354 NRT DCH HHO REQ FOR PS CALL BACKG


NRT_REQ_PS_BACKG_HHO_RJ_SRNC

M1002C371 DCH HHO OVER IUR REQ FOR SIG LINK IN

DRNC

DCH_HHO_REQ_LINK_DRNC

M1002C372 DCH HHO OVER IUR REQ FOR SIG LINK

REJECT IN DRNC

DCH_HHO_REQ_LINK_REJ_DRNC

M1002C373 RT DCH HHO OVER IUR REQ FOR CS VOICE

CALL IN DRNC

REQ_CS_VOICE_HHO_DRNC

M1002C374 RT DCH HHO OVER IUR REQ FOR CS VOICE

CALL REJECT IN DRNC

REQ_CS_VOICE_HHO_REJ_DRNC





168 DN0495772

Issue 14C


Id:0900d8058065d474


10.2.2 RAN2.0084: Packet scheduler interruption timer

10.2.3 RAN395: Enhanced priority based scheduling and overload control

for NRT traffic

M1002C375 DCH HHO OVER IUR REQ FOR DATA CALL IN

DRNC

DCH_HHO_REQ_DATA_DRNC

M1002C376 DCH HHO OVER IUR REQ FOR DATA CALLREJECT IN DRNC

DCH_HHO_REQ_DATA_REJ_DRNC




M1006C71 CELL DCH TO CELL FACH STATE TRANSI-

TIONS DUE TO PS INTERRUPTION TIMER

DCH_TO_FACH_PS_INTERRUPT_TIM

Table 33 Counters for packet scheduler interruption timer


M1000C142 RB DOWNGRADE BY ENH OVERLOAD

CONTROL USING TFC SUBSET

RB_DOWNGR_DUE_OLC_TFC_SUBS

M1000C143 RB DOWNGRADE BY DYN LINK OPT DUE TO

RL POWER CONGESTION

RB_DOWNGR_DUE_DYLO_RL_POWER

M1000C145 RB DOWNGRADE BY PBS DUE TO AAL2CONGESTION

RB_DOWNGR_DUE_PBS_AAL2

M1000C146 RB DOWNGRADE BY PBS DUE TO BTS CON-

GESTION

RB_DOWNGR_DUE_PBS_BTS

M1000C147 RB DOWNGRADE BY PBS DUE TO INTER-

FERENCE CONGESTION

RB_DOWNGR_DUE_PBS_INTERF

M1000C148 RB DOWNGRADE BY PBS DUE TO SPREAD-

ING CODE CONGESTION

RB_DOWNGR_DUE_PBS_SPREAD

M1000C150 RB DOWNGRADE BY PRE-EMPTION DUE TO

AAL2 CONGESTION

RB_DOWNGR_DUE_PRE_EMP_AAL2


BTS CONGESTION

RB_DOWNGR_DUE_PRE_EMP_BTS


INTERFERENCE CONGESTION

RB_DOWNGR_DUE_PRE_EMP_INTERF


SPREADING CODE CONGESTION

RB_DOWNGR_DUE_PRE_EMP_SPREAD

M1000C154 RB DOWNGRADE BY ENH OVERLOAD

CONTROL USING RL RECONF

RB_DOWNGR_DUE_OLC_RL_RECONF

M1000C155 RB RELEASE BY DYN LINK OPT DUE TO RL

POWER CONGESTION

RB_RELEASE_DUE_DYLO_RL_POWER

Table 34 Cell resource measurements



DN0495772

Issue 14C

169


Id:0900d8058065d474

M1000C157 RB RELEASE BY PBS DUE TO AAL2 CON-

GESTION

RB_RELEASE_DUE_PBS_AAL2

M1000C158 RB RELEASE BY PBS DUE TO BTS CONGES-TION

RB_RELEASE_DUE_PBS_BTS

M1000C159 RB RELEASE BY PBS DUE TO INTERFER-

ENCE CONGESTION

RB_RELEASE_DUE_PBS_INTERF

M1000C160 RB RELEASE BY PBS DUE TO SPREADING

CODE CONGESTION

RB_RELEASE_DUE_PBS_SPREAD

M1000C162 RB RELEASE BY PRE-EMPTION DUE TO

AAL2 CONGESTION

RB_RELEASE_DUE_PRE_EMP_AAL2

M1000C163 RB RELEASE BY PRE-EMPTION DUE TO BTS

CONGESTION

RB_RELEASE_DUE_PRE_EMP_BTS


INTERFERENCE CONGESTION

RB_RELEASE_DUE_PRE_EMP_INTF


SPREADING CODE CONGESTION

RB_RELEASE_DUE_PRE_EMP_SPREA

M1000C166 RB RELEASE DUE TO ENH OVERLOAD

CONTROL USING RL RECONF

RB_RELEASE_DUE_OLC_RL_RECONF


Table 34 Cell resource measurements (Cont.)


M1005C153 RL RECONF PREP SYNCH FOR DCH DEL

DUE TO PRIORITY BASED SCHEDULING

RECONF_PREP_DCH_DEL_PBS

M1005C154 RL RECONF PREP SYNCH FOR DCH

DELETION DUE TO PRE-EMPTION

RECONF_PREP_DCH_DEL_PRE_EMPT


DUE ENHANCED OVERLOAD CONTROL

RECONF_PREP_DCH_DEL_ENH_OLC


DUE DYNAMIC LINK OPTIMIZATION

RECONF_PREP_DCH_DEL_DLNK_OPT

M1005C158 RL RECONF PREP SYNCH FOR DCH MOD

DUE PBS DOWNGRADING

RECONF_PREP_DCH_MOD_PBS_DGR


DUE PRE-EMPTION DOWNGRADING

RECONF_PREP_DCH_MOD_PRE_DGR


DUE ENHANCED OLC DOWNGRADING

RECONF_PREP_DCH_MOD_OLC_DGR

Table 35 L3 signalling at Iub measurement



170 DN0495772

Issue 14C


Id:0900d8058065d474


10.2.4 RAN409: Throughput-based optimisation of the packet scheduler

algorithm

10.2.5 Counters for quality of service (QoS) management

The counters related to QoS aware HSPA scheduling and Streaming QoS for HSPA can

be found in the WCDMA RAN RRM HSDPA functional area description.

10.3 Parameters

This section lists the parameters per feature. See also WCDMA Radio Network Config-

uration Parameters.There are no parameters related to the following features:

• RAN919: Decrease of the retried NRT DCH bit rate

• RAN1039: Lightweight flexible upgrade of NRT DCH data rate

• RAN920: Selective NRT DCH data rate set

• RAN2.0107: RRC connection re-establishment

10.3.1 RAN866: Dynamic link optimisation for NRT traffic coverage


M1000C226 RB DOWNGRADE DUE TO THROUGHPUT

BASED OPTIMIZATION

RB_DOWNGR_DUE_THRPOPT

M1000C227 RB RELEASE DUE TO THROUGHPUT BASED

OPTIMIZATION

RB_RELEASE_DUE_THRPOPT


DUE THROUGHPUT BASED OPTIMISATION

RECONF_PREP_DCH_MOD_THRPOPT


DUE THROUGHPUT BASED OPTIMISATION

RECONF_PREP_DCH_DEL_THRPOPT

M1006C86 STATE TRANS CELL_DCH TO CELL_FACH

DUE TO LOW UTILISATION

CELL_DCH_FACH_LOW_UTIL

Table 36 Counters for throughput-based optimisation of the packet scheduler algorithm

Parameter name Abbreviated name Modifiable /

system-defined

Object

Dynamic Link Optimisation prohibit time DLOptimisationProhibitTime On-Line RNC

Power offset for dynamic link optimisation DLOptimisationPwrOffset On-Line RNC

Dynamic link optimisation usage DLOptimisationUsage On-Line RNC

Table 37 RAN866: Dynamic link optimisation for NRT traffic coverage









DN0495772

Issue 14C

171


Id:0900d8058065d474

10.3.2 RAN242: Flexible upgrade of NRT DCH data rate


system-defined

Object

Window size for the high throughput measurement DCHUtilHighAveWin On-Line RNC

Threshold below the NRT DCH data rate DCHUtilHighBelowNRTDat-

aRateThr

On-Line RNC

Time to trigger for the high throughput measurement DCHUtilHighTimeToTrigger On-Line RNC

Usage of the Flexible Upgrade of the NRT DCH data

rate

FlexUpgrUsage On-Line RNC

Traffic volume threshold for downlink NRT DCH bit

rates

TrafVolThresholdDLHighBi-

tRate

On-Line RNC

Traffic volume threshold for DL NRT DCH of 128 kbps TrafVolThresholdDLHighDCH1

28

On-Line RNC


6

On-Line RNC


56

On-Line RNC


2

On-Line RNC


4

On-Line RNC

Traffic volume threshold for DL NRT DCH of 8 kbps TrafVolThresholdDLHighDCH8 On-Line RNC

Traffic volume threshold for uplink NRT DCH bit rates TrafVolThresholdULHighBi-

tRate

On-Line RNC

Traffic volume threshold for UL NRT DCH of 128 kbps TrafVolThresholdULHighDCH1

28

On-Line RNC


6

On-Line RNC


56

On-Line RNC


2

On-Line RNC


4

On-Line RNC

Traffic volume threshold for UL NRT DCH of 8 kbps TrafVolThresholdULHighDCH8 On-Line RNC

Tx power of radio l ink averaging window size for DLO DLORLAveragingWindowSize On-Line WBTS

Tx power of radio link averaging window size for PS PSRLAveragingWindowSize On-Line WBTS

Table 38 RAN242: Flexible upgrade of NRT DCH data rate



172 DN0495772

Issue 14C


Id:0900d8058065d474


10.3.3 RAN1.029: Packet scheduler algorithm


system-defined

Object

Dynamic usage of UL NRT DCH HSDPA returnChannel

DynUsageHSDPAReturn-Channel

On-Line RNC

Table 39 RAN242: Flexible upgrade of NRT DCH data rate


system-defined

Object

DL DPCH TX Power Threshold for AMR GsmDLTxPwrThrAMR On-Line FMCG

DL DPCH TX Power Threshold for CS GsmDLTxPwrThrCS On-Line FMCG

DL DPCH TX Power Threshold for NRT PS GsmDLTxPwrThrNrtPS On-Line FMCG

DL DPCH TX Power Threshold for RT PS GsmDLTxPwrThrRtPS On-Line FMCG

UE TX Power Threshold for AMR GsmUETxPwrThrAMR On-Line FMCG

UE TX Power Threshold for CS GsmUETxPwrThrCS On-Line FMCG

UE TX Power Threshold for NRT PS GsmUETxPwrThrNrtPS On-Line FMCG

UE TX Power Threshold for RT PS GsmUETxPwrThrRtPS On-Line FMCG

DL DPCH TX Power Threshold for AMR InterFreqDLTxPwrThrAMR On-Line FMCI

DL DPCH TX Power Threshold for CS InterFreqDLTxPwrThrCS On-Line FMCI

DL DPCH TX Power Threshold for NRT PS InterFreqDLTxPwrThrNrtPS On-Line FMCI

DL DPCH TX Power Threshold for RT PS InterFreqDLTxPwrThrRtPS On-Line FMCI

UE TX Power Threshold for AMR InterFreqUETxPwrThrAMR On-Line FMCI

UE TX Power Threshold for CS InterFreqUETxPwrThrCS On-Line FMCI

UE TX Power Threshold for NRT PS InterFreqUETxPwrThrNrtPS On-Line FMCI

UE TX Power Threshold for RT PS InterFreqUETxPwrThrRtPS On-Line FMCI

Threshold for the downlink DCH release measurement DCHUtilRelThrDL On-Line RNC

Threshold for the uplink DCH release measurement DCHUtilRelThrUL On-Line RNC

Factor to determine minimum PBS interval FactorMinPBSinterval On-Line RNC

Inactivity timer for downlink 128kbps DCH InactivityTimerDownlinkDCH128

On-Line RNC

Inactivity timer for downlink 16kbps DCH InactivityTimerDownlinkDCH

16

On-Line RNC


256

On-Line RNC


32

On-Line RNC


320

On-Line RNC

Table 40 RAN1.029: Packet scheduler algorithm



DN0495772

Issue 14C

173


Id:0900d8058065d474


384

On-Line RNC


64

On-Line RNC


8

On-Line RNC

Inactivity timer for uplink 128kbps DCH InactivityTimerUplinkDCH128 On-Line RNC








Initial bit rate in downlink InitialBitRateDL On-Line WCEL

Initial bit rate in uplink InitialBitRateUL On-Line WCEL

Maximum number of UEs in CM due to critical HO

measurement

MaxNumberUECmHO On-Line WCEL

Maximum number of UEs in CM due to SLHO mea-

surement

MaxNumberUECmSLHO On-Line WCEL

Minimum allowed bit rate in downlink MinAllowedBitRateDL On-Line WCEL

Minimum allowed bit rate in uplink MinAllowedBitRateUL On-Line WCEL

Downlink NAS signalling volume threshold NASsignVolThrDL On-Line WCEL

Uplink NAS signalling volume threshold NASsignVolThrUL On-Line WCEL

Uplink noise level PrxNoise On-Line WCEL

Offset for activation time ActivationTimeOffset On-Line RNC

Maximum downlink capacity request queuing time CrQueuingTimeDL On-Line RNC

Maximum uplink capacity request queuing time CrQueuingTimeUL On-Line RNC

Inactivity timer for downlink DCH InactivityTimerDownlinkDCH On-Line RNC

Inactivity timer for uplink DCH InactivityTimerUplinkDCH On-Line RNC

PS load control period LoadControlPeriodPS On-Line WBTS

Maximum uplink power decrease in packet scheduling DeltaPrxMaxDown On-Line WCEL

Maximum uplink power increase in packet scheduling DeltaPrxMaxUp On-Line WCEL

Maximum downlink power decrease in packet sched-

uling

DeltaPtxMaxDown On-Line WCEL

Maximum downlink power increase in packet schedul-

ing

DeltaPtxMaxUp On-Line WCEL


system-defined

Object

Table 40 RAN1.029: Packet scheduler algorithm (Cont.)



174 DN0495772

Issue 14C


Id:0900d8058065d474


Margin for FACH load for downlink channel type selec-

tion

FachLoadMarginCCH On-Line WCEL

Threshold for FACH load for downlink channel type

selection

FachLoadThresholdCCH On-Line WCEL

Margin for total downlink transmission power for

downlink channel type selection

PtxMarginCCH On-Line WCEL

Threshold for total downlink transmission power for

downlink channel type selection

PtxThresholdCCH On-Line WCEL

Margin for RACH load for downlink channel type selec-

tion

RachLoadMarginCCH On-Line WCEL

Threshold for RACH load for downlink channel type

selection

RachLoadThresholdCCH On-Line WCEL

Downlink traffic volume measurement high threshold TrafVolThresholdDLHigh On-Line RNC

Downlink traffic volume measurement low threshold TrafVolThresholdDLLow On-Line WCEL

Downlink traffic volume measurement pending time

after trigger

TrafVolPendingTimeDL On-Line RNC

Downlink traffic volume measurement time to trigger TrafVolTimeToTriggerDL On-Line RNC

Uplink traffic volume measurement low threshold TrafVolThresholdULLow On-Line RNC

Uplink traffic volume measurement high threshold TrafVolThresholdULHigh On-Line RNC

Uplink traffic volume measurement time to trigger TrafVolTimeToTriggerUL On-Line RNC

Uplink traffic volume measurement pending time after

trigger

TrafVolPendingTimeUL On-Line RNC

Compressed mode master switch CMmasterSwitch On-Line RNC

Higher Layer Scheduling mode selection HLSModeSelection On-Line RNC

Gap position single frame GapPositionSingleFrame On-Line RNC

Radio link downlink power control range PCrangeDL On-Line RNC

Transmision gap pattern length in case of double

frame: NRT PS service and GSM measurement

TGPLdoubleframeN-

RTPSgsm

On-Line RNC

Transmision gap pattern length in case of double

frame: NRT PS service and IF measurement

TGPLdoubleframeNRTPSin-

terFreq

On-Line RNC

Transmision gap pattern length in case of single frame:

AMR service and GSM measurement

TGPLsingleframeAMRgsm On-Line RNC


AMR service and IF measurement

TGPLsingleframeAMRinter-

Freq

On-Line RNC


CS service and GSM measurement

TGPLsingleframeCSgsm On-Line RNC


CS service and IF measurement

TGPLsingleframeCSinterFreq On-Line RNC


NRT PS service and GSM measurement

TGPLsingleframeNRTPSgsm On-Line RNC


system-defined

Object




DN0495772

Issue 14C

175


Id:0900d8058065d474

10.3.4 RAN395: Enhanced priority based scheduling and overload control

for NRT traffic


NRT PS service and IF measurement

TGPLsingleframeNRTPSin-

terFreq

On-Line RNC


RT PS service and GSM measurement

TGPLsingleframeRTPSgsm On-Line RNC


RT PS service and IF measurement

TGPLsingleframeRTPSinter-

Freq

On-Line RNC

Load measurement averaging window size for packet

scheduling

PSAveragingWindowSize On-Line WBTS

Type of measurement filter for uplink total received

power

PrxAlpha On-Line WBTS

Number of frames to be used averaging in PrxTotal

measurement

PrxMeasAveWindow On-Line WBTS

Type of measurement filter for downlink total transmit-

ted power

PtxAlpha On-Line WBTS

DPCH downlink transmission power maximum value PtxDPCHmax On-Line WBTS

DPCH downlink transmission power minimum value PtxDPCHmin On-Line WBTS

Number of frames to be used averaging in PtxTotal

measurement

PtxMeasAveWindow On-Line WBTS

Scheduling period SchedulingPeriod On-Line WBTS

Compressed Mode: Alternative scrambling code AltScramblingCodeCM On-Line WCEL

Offset of the P-CPICH and reference service powers CPICHtoRefRABoffset On-Line WCEL

Eb/No parameter set identifier EbNoSetIdentifier Requires objectlocking

WCEL

Maximum downlink bit rate for PS domain NRT data MaxBitRateDLPSNRT On-Line WCEL

Maximum uplink bit rate for PS domain NRT data MaxBitRateULPSNRT On-Line WCEL

PrxNoise autotuning allowed PrxNoiseAutotuning On-Line WCEL

Offset for received power PrxOffset On-Line WCEL

Target for received power PrxTarget On-Line WCEL

Planned maximum downlink transmission power of a

radio link

PtxDLabsMax On-Line WCEL

Offset for transmitted power PtxOffset On-Line WCEL

Target for transmitted power PtxTarget On-Line WCEL


system-defined

Object



system-defined

Object

Factor to determine minimum PBS interval FactorMinPBSinterval On-Line RNC

Table 41 RAN395: Enhanced priority based scheduling and overload control for NRT traffic



176 DN0495772

Issue 14C


Id:0900d8058065d474


10.3.5 RAN409: Throughput-based optimisation of the packet scheduler

algorithm

Priority based scheduling policy PBSpolicy On-Line RNC

Threshold for DL NRT DCH allocation time inenhanced overload control

OCdlNrtDCHgrantedMinAl-locT

On-Line WCEL

PBS granted min DCH allocation time PBSgrantedMinDCHallocT On-Line WCEL

PBS granted min DCH allocation time equal priority PBSgrantedMinDCHal-

locTequalP

On-Line WCEL

PBS granted min DCH allocation time higher priority PBSgrantedMinDCHal-

locThigherP

On-Line WCEL

PBS granted min DCH allocation time lower priority PBSgrantedMinDCHallocT-

lowerP

On-Line WCEL


system-defined

Object

Table 41 RAN395: Enhanced priority based scheduling and overload control for NRT traffic (Cont.)


system-defined

Object

Threshold below the downgrade bit rate DCHUtilBelowDowngradeThr On-Line RNC

Window size for the lower throughput measurement DCHUtilLowerAveWinBi-

tRate

On-Line RNC

Lower measurement window size for NRT DCH of 128

kbps

DCHUtilLowerAveWin128 On-Line RNC


kbps



kbps



kbps



kbps


Lower downgrade threshold DCHUtilLowerDowngrade-

ThrBitRate

On-Line RNC

Lower downgrade threshold for the NRT DCH of 128

kbps

DCHUtilLowerDowngradeThr

128

On-Line RNC


kbps


256

On-Line RNC


kbps


32

On-Line RNC


kbps


384

On-Line RNC


kbps


64

On-Line RNC

Table 42 RAN409: Throughput-based optimisation of the packet scheduler algorithm



DN0495772

Issue 14C

177


Id:0900d8058065d474

Time to trigger for the lower throughput measurement DCHUtilLowerTimeToTrig-

gerBitRate

On-Line RNC

Lower time to trigger for the NRT DCH of 128 kbps DCHUtilLowerTimeToTrigger

128

On-Line RNC


256

On-Line RNC


32

On-Line RNC


384

On-Line RNC


64

On-Line RNC

Guard time for throughput measurement DCHUtilMeasGuardTime On-Line RNC

Window size for the release throughput measurement DCHUtilRelAveWin On-Line RNC

Time to trigger for the release throughput measure-

ment

DCHUtilRelTimeToTrigger On-Line RNC

Window size for the upper throughput measurement DCHUtilUpperAveWinBi-

tRate

On-Line RNC

Upper measurement window size for NRT DCH of 128

kbps

DCHUtilUpperAveWin128 On-Line RNC


kbps


Upper measurement window size for NRT DCH of 32kbps



kbps



kbps


Upper downgrade threshold DCHUtilUpperDowngrade-

ThrBitRate

On-Line RNC

Upper downgrade threshold for the NRT DCH of 128

kbps

DCHUtilUpperDowngradeThr

128

On-Line RNC


kbps


256

On-Line RNC


kbps


32

On-Line RNC


kbps


384

On-Line RNC


kbps


64

On-Line RNC

Time to trigger for the upper throughput measurement DCHUtilUpperTimeToTrig-

gerBitRate

On-Line RNC


system-defined

Object

Table 42 RAN409: Throughput-based optimisation of the packet scheduler algorithm (Cont.)



178 DN0495772

Issue 14C


Id:0900d8058065d474


10.3.6 Parameters for quality of service (QoS) management

The parameters related to QoS aware HSPA scheduling and Streaming QoS for HSPA

can be found in the WCDMA RAN RRM HSDPA functional area description.

10.3.7 Common measurements over Iub

10.3.8 RAN973: HSUPA Basic RRM

Table RAN973: HSUPA Basic RRM shows RAN973: HSUPA Basic RRM parameters

used in the context of the Packet Scheduler FAD. For an overview of all parameters

related to RAN973: HSUPA Basic RRM see WCDMA RAN RRM HSUPA.

Upper time to trigger for the NRT DCH of 128 kbps DCHUtilUpperTimeToTrigger

128

On-Line RNC


256

On-Line RNC


32

On-Line RNC


384

On-Line RNC


64

On-Line RNC

Throughput based optimisation of the PS algorithm

usage

PSOpThroUsage On-Line RNC


system-defined

Object

Table 42 RAN409: Throughput-based optimisation of the packet scheduler algorithm (Cont.)


system-defined

Object

Radio Resource Indication Period RRIndPeriod On-Line WBTS

Reporting period for the TCP measurements. PtxTotalReportPeriod On-Line WCEL

Reporting period for the RTWP measurements PrxTotalReportPeriod On-Line WCEL

Table 43 Common measurements over Iub


system-defined

Object

Non E-DCH ST interference averaging window size for

LC

WinLCHSUPA On-Line WBTS

Table 44 RAN973: HSUPA Basic RRM







DN0495772

Issue 14C

179


Id:0900d8058065d474

10.3.9 RAN1759: Support for I-HSPA Sharing and Iur Mobility Enhance-

ments

Parameter name Abbreviated name Modifiable /system-defined

Object

IBTS Sharing IBTSSharing On-Line IUR

Type of the Neighbouring RNW Element NeighbouringRNWElement On-Line IUR

RNSAP Congestion And Preemption RNSAPCongAndPreemp-

tion

On-Line IUR

DCH Scheduling Over Iur DCHScheOverIur On-Line RNC

RAB Combinations Supported by IBTS IBTSRabCombSupport On-Line RNC

ISHO In Iur Mobility ISHOInIurMobility On-Line RNC

Priority handling over Iur-interface IurPriority On-Line RNC

List of neighbouring IBTS and SRNC Identifiers ControllerIdList On-Line VBTS

Neighbouring IBTS Identifier and Its SRNC Identifier ControllerIdPair On-Line VBTS

I-HSPA Adapter Identifier IHSPAadapterId On-Line VBTS

Serving RNC Identifier ServingRNCId On-Line VBTS

Dedicated Measurement Reporting Period CS data DediMeasRepPeriodCS-

data

On-Line VBTS

Dedicated Measurement Reporting Period PS data DediMeasRepPeriodPS-

data

On-Line VBTS

Dedicated Measurement Reporting Period DedicatedMeasReportPe-

riod

On-Line VBTS

Measurement filter coefficient MeasFiltCoeff On-Line VBTS

Change Origin VBTSChangeOrigin Not modifiable VBTS

Time Stamp VBTSTimeStamp Not modifiable VBTS

Time Stamp day VBTSDay Not modifiable VBTS

Time Stamp hours VBTSHours Not modifiable VBTS

Time Stamp hundredths of seconds VBTSHundredths Not modifiable VBTS

Time Stamp minutes VBTSMinutes Not modifiable VBTS

Time Stamp month VBTSMonth Not modifiable VBTS

Time stamp seconds VBTSSeconds Not modifiable VBTS

Time Stamp year VBTSYear Not modifiable VBTS

Configured CS AMR mode sets CSAMRModeSET On-Line VCEL

Configured CS WAMR mode sets CSAMRModeSETWB On-Line VCEL

Eb/No parameter set identifier EbNoSetIdentifier On-Line VCEL

Maximum allowed DL user bit rate in HHO HHoMaxAllowedBitrateDL On-Line VCEL

Maximum allowed UL user bit rate in HHO HHoMaxAllowedBitrateUL On-Line VCEL

Initial bit rate in downlink InitialBitRateDL On-Line VCEL

Initial bit rate in uplink InitialBitRateUL On-Line VCEL

Table 45 RAN1759: Support for I-HSPA Sharing and Iur Mobility Enhancements



180 DN0495772

Issue 14C


Id:0900d8058065d474


Location area code LAC On-Line VCEL

Maximum downlink bit rate for PS domain NRT data MaxBitRateDLPSNRT On-Line VCEL

Maximum uplink bit rate for PS domain NRT data MaxBitRateULPSNRT On-Line VCEL

Minimum allowed bit rate in downlink MinAllowedBitRateDL On-Line VCEL

Minimum allowed bit rate in uplink MinAllowedBitRateUL On-Line VCEL

NRT FMCG Identifier NrtFmcgIdentifier On-Line VCEL

NRT FMCI Identifier NrtFmciIdentifier On-Line VCEL

NRT FMCS Identifier NrtFmcsIdentifier On-Line VCEL

NRT HOPG Identifier NrtHopgIdentifier On-Line VCEL

NRT HOPI Identifier NrtHopiIdentifier On-Line VCEL

NRT HOPS Identifier NrtHopsIdentifier On-Line VCEL

Routing Area Code RAC On-Line VCEL

Usage of Relocation Commit procedure in inter RNC

HHO

RelocComm_in_InterRNC_

HHO

On-Line VCEL

RT FMCG Identifier RtFmcgIdentifier On-Line VCEL

RT FMCI Identifier RtFmciIdentifier On-Line VCEL

RT FMCS Identifier RtFmcsIdentifier On-Line VCEL

RT HOPG Identifier RtHopgIdentifier On-Line VCEL

RT HOPI Identifier RtHopiIdentifier On-Line VCEL

RT HOPS Identifier RtHopsIdentifier On-Line VCEL

Rx Diversity Indicator RxDivIndicator On-Line VCEL

Change Origin VCELChangeOrigin Not modifiable VCEL

Time Stamp VCELTimeStamp Not modifiable VCEL

Time Stamp day VCELDay Not modifiable VCEL

Time Stamp hours VCELHours Not modifiable VCEL

Time Stamp hundredths of seconds VCELHundredths Not modifiable VCEL

Time Stamp minutes VCELMinutes Not modifiable VCEL

Time Stamp month VCELMonth Not modifiable VCEL

Time Stamp seconds VCELSeconds Not modifiable VCEL

Time Stamp year VCELYear Not modifiable VCEL


system-defined

Object

Table 45 RAN1759: Support for I-HSPA Sharing and Iur Mobility Enhancements (Cont.)




10.3.10 DCH bit rate balancing


system-defined

Object

DCH bit rate balancing on/off switch DCHBitRateBalancing On-Line RNC

Table 46 DCH bit rate balancing

packet scheduler

Documents