06_PacketScheduling_2004

1 © NOKIA 31/10/2003 RANPAR Version 1.0

Course Content

• Radio Resource Management Overview

• Parameter Configuration

• Common Channels & Power Control

• Load Control

• Admission Control

• Packet Scheduling

• Handover Control

• Resource Manager


Course Objectives

At the end of the course you will be able to:

• Describe the criteria for RRC connection state change and their relationship to the packet scheduler

• Identify the transport channels used for NRT traffic

• Explain how packet scheduler influences the controllable load

• Explain the capacity request procedure

• Identify the reasons for TFCS modification

• Name and describe the main RAN parameters related to packet scheduler


Packet Scheduling• Overview

• Packet Transfer States & Parameters• Bitrate Allocation• Capacity Request & Traffic Volume Measurements• Channel Type Selection • Processing a Capacity Request

• Bitrate Upgrade

• Overload Control

• Dynamic Link Optimisation (DyLo)


Why Packet Scheduling?

Load(~ Power)

time

PlannedLoad/PowerTargetFree Capacity

Non-Controllable Load• real time traffic• interference from other cell users• noise

• Suitable for controllable load (=best effort NRT)• Requires fast resource allocation


Why Packet Scheduling?It is characteristic for RT traffic that it’s load cannot be controlled in efficient way. Load caused by RT

traffic, interference from other cell users and noise together is called non-controllable load. The available capacity, which is not used by non-controllable load, can be used for NRT radio bearers on best effort basis. To fill the whole load budget and achieve the maximum capacity, the allocation of NRT traffic needs to be fast.

The Packet scheduler is a general feature, which takes care of scheduling radio resources for NRT radio bearers for both uplink and downlink directions; Packet scheduling happens periodically (with the period of tens of milliseconds) and is implemented for both dedicated (DCH) and common control transport channels (RACH/FACH).

Scheduled capacity depends on the UE capabilities, Node B capabilities, current load of the cell as well as the availability of the physical radio resources.

Packet scheduler and MAC layer together make the decision of the used channel type for downlink direction, data transmission on dedicated channel is initiated when MAC layer requests transmission capacity

For uplink direction the decision of the used channel type is based on UE measurements and parameters controlled by network. Data transmission on dedicated channels is initiated when a capacity request is received from UE.

The selection of the channel type is done fast - taking into account the data amount in the buffers and the current radio conditions


Packet Scheduling principles• Packet Scheduler switches between common channels (FACH/RACH =

low capacity) and dedicated channels (DCH = higher bit rates)

• Packet Scheduler allocates to RABs temporarily dedicated channels with a set of maximum bit rates

• For instance within an allocation for 384kbit/s, the instantaneous bit rate can be {0, 64, 128, 384} kbit/s

• Packet Scheduler allocates DCH based on Capacity Requests• A Capacity Request (Nokia term) is triggered based on traffic

volume measurement info: the sender (UE or RNC) has data in buffer and no sufficient dedicated channel

• Packet Scheduler releases DCH upon inactivity

• Packet Scheduler re-schedules continuously DCH to serve all requests equally, and take into account changes in non-controllable load


Packet Scheduling Principles

Power/ Load

time

non-controllable loadi.e. RT Traffic

controllable loadi.e. non RT Traffic

PtxTotal (variable) PrxTotal

PtxNrt PrxNrt

PtxTarget PrxTarget

PtxOffset PrxOffset

PtxTargetBTS PrxTargetBTS

overload

DesiredPrx/PtxValues

PtxRt PrxRt


Supported Radio Bearers in RANRAN1.5.1RAN1.5.1RAN1.5.1RAN1.5.1RAN1.5.1RAN1.5.1RAN1.5.1RAN1.5.1RAN1.5.1RAN1.5.1RAN1.5.1RAN1.5.1 RAN1.5.2ED2RAN1.5.2ED2RAN1.5.2ED2RAN1.5.2ED2RAN1.5.2ED2RAN1.5.2ED2RAN1.5.2ED2RAN1.5.2ED2RAN1.5.2ED2RAN1.5.2ED2RAN1.5.2ED2RAN1.5.2ED2 RAN’04RAN’04RAN’04RAN’04RAN’04RAN’04RAN’04RAN’04RAN’04RAN’04RAN’04RAN’04 RAN’05RAN’05RAN’05RAN’05RAN’05RAN’05RAN’05RAN’05RAN’05RAN’05RAN’05RAN’05 RAN’06RAN’06RAN’06RAN’06RAN’06RAN’06RAN’06RAN’06RAN’06RAN’06RAN’06RAN’06

AMR = Conversational CS speechTransparent CS data = Conversational CS dataNon-transparent CS data = Streaming CS dataNRT PS data = Interactive/Background PS data

Implementation of Nokia RAN shall support asymmetric combinations with all bit rates. The combinations supported by terminals are verified in system verification and inter-operability testing between Nokia RAN and Nokia & third party terminals.

AMR AMR AMR AMR 12.212.212.212.2AMR AMR AMR AMR 12.212.212.212.2

TransparentTransparentTransparentTransparent CS data CS data CS data CS data 64646464TransparentTransparentTransparentTransparent CS data CS data CS data CS data 64646464

NonNonNonNon----transparenttransparenttransparenttransparent CS data CS data CS data CS data 57.657.657.657.6NonNonNonNon----transparenttransparenttransparenttransparent CS data CS data CS data CS data 57.657.657.657.6

NRT PS data NRT PS data NRT PS data NRT PS data UL:64, DL(64,128,384)UL:64, DL(64,128,384)UL:64, DL(64,128,384)UL:64, DL(64,128,384)NRT PS data NRT PS data NRT PS data NRT PS data UL:64, DL(64,128,384)UL:64, DL(64,128,384)UL:64, DL(64,128,384)UL:64, DL(64,128,384)

NonNonNonNon----transparenttransparenttransparenttransparent CS dataCS dataCS dataCS data 14.414.414.414.4NonNonNonNon----transparenttransparenttransparenttransparent CS dataCS dataCS dataCS data 14.414.414.414.4

AMR AMR AMR AMR 10.2, 7.95, 7.40, 6.70, 5.90. 5.15, 4.7510.2, 7.95, 7.40, 6.70, 5.90. 5.15, 4.7510.2, 7.95, 7.40, 6.70, 5.90. 5.15, 4.7510.2, 7.95, 7.40, 6.70, 5.90. 5.15, 4.75AMR AMR AMR AMR 10.2, 7.95, 7.40, 6.70, 5.90. 5.15, 4.7510.2, 7.95, 7.40, 6.70, 5.90. 5.15, 4.7510.2, 7.95, 7.40, 6.70, 5.90. 5.15, 4.7510.2, 7.95, 7.40, 6.70, 5.90. 5.15, 4.75

TransparentTransparentTransparentTransparent CS data CS data CS data CS data 33.6, 32, 28.833.6, 32, 28.833.6, 32, 28.833.6, 32, 28.8TransparentTransparentTransparentTransparent CS data CS data CS data CS data 33.6, 32, 28.833.6, 32, 28.833.6, 32, 28.833.6, 32, 28.8

NRT PS data NRT PS data NRT PS data NRT PS data 8, 16, 328, 16, 328, 16, 328, 16, 32NRT PS data NRT PS data NRT PS data NRT PS data 8, 16, 328, 16, 328, 16, 328, 16, 32

StreamingStreamingStreamingStreaming PS data PS data PS data PS data UL/DL(8, 16, 32, 64, 128), DL:256UL/DL(8, 16, 32, 64, 128), DL:256UL/DL(8, 16, 32, 64, 128), DL:256UL/DL(8, 16, 32, 64, 128), DL:256StreamingStreamingStreamingStreaming PS data PS data PS data PS data UL/DL(8, 16, 32, 64, 128), DL:256UL/DL(8, 16, 32, 64, 128), DL:256UL/DL(8, 16, 32, 64, 128), DL:256UL/DL(8, 16, 32, 64, 128), DL:256

NRT PS data NRT PS data NRT PS data NRT PS data 256256256256NRT PS data NRT PS data NRT PS data NRT PS data 256256256256

ConversationalConversationalConversationalConversational PS PS PS PS QoSQoSQoSQoS is a is a is a is a study itemstudy itemstudy itemstudy itemin RAN’06in RAN’06in RAN’06in RAN’06

ConversationalConversationalConversationalConversational PS PS PS PS QoSQoSQoSQoS is a is a is a is a study itemstudy itemstudy itemstudy itemin RAN’06in RAN’06in RAN’06in RAN’06




• Bitrate Upgrade




RRC Modes with Parameters

Release RRCConnection


URA_PCH

CELL_DCH CELL_FACH

CELL_PCH

Establish RRCConnection

UTRA RRC Connected Mode

Idle Mode

(UE camps on UTRAN cell)

Available in RAN1.5.2ED2

Available in RAN’04

cellUpdate, UL Tx

UL_DL_activation_timer

#cellUpdates

UL Tx

UL_DL_activation_timer(workaround)

DRX DRX

Tx/RxinactivityTimer

Tx/Rx FACH/RACH

trafficVolume



URA_PCH

CELL_DCH CELL_FACH

CELL_PCH

Establish RRCConnection

UTRA RRC Connected Mode

Idle Mode

(UE camps on UTRAN cell)

Available in RAN1.5.2ED2

Available in the future

cellUpdate, UL Tx

UL_DL_activation_timer

#cellUpdates

UL Tx

UL_DL_activation_timer(workaround, in RAN1.5.2 ED)

DRX DRX

Tx/RxinactivityTimer

Tx/Rx FACH/RACH

trafficVolume


RRC Modes and Packet SchedulingThe packet access procedure in WCDMA should keep the interference caused to other users as small as

possible.Since there is no connection between the base station and the UE before the access procedure, initial

access is not closed loop power controlled and thus the information transmitted during this period should be kept at minimum.

There are three scenarios for WCDMA packet access: • infrequent transmission of small packets• frequent transmission of small packets and• transmission of large packetsPacket data transfer in WCDMA can be performed using common or dedicated transport channels.

Since the establishment of a dedicated transport channel itself requires signalling and thus consumes radio resources, it is reasonable to transmit infrequent and small NRT user data packets using common transport channels without closed loop power control.Then 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 transferred on common channels, the UE is in CELL_FACH state.Large or 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.


PS Connection EstablishmentIn the RRC connection setup procedure the UE is always transferred directly to CELL_DCH state in RAN1 (see previous slide).

The RRC connection setup and “a service establishment” for NRT RAB(s) is performed as follows:•After the UE has completed a RRC Connection setup procedure with the RNC, dedicated channel resources are allocated to the UE (a DCH for the signalling link is setup).

•The UE performs a NAS connection establishment to the PS CN.•After the service negotiation has been carried out between the UE and PS CN, the PS CN sends a RAB assignment to the RNC.

•The RNC’s RRC signalling entity performs a radio bearer setup with a RRC:Radio Bearer Setupprocedure.

The traffic volume measurement parameters (RLC buffer level, reporting criteria, etc.) are sent to the UE by using a RRC:Measurement Control procedure

•Based on this information the UE is able report the need of UL capacity (request the allocation of the DCH) by sending a RRC:MEASUREMENT REPORT message to the RNC

The RNC’s RRC signalling entity starts a supervision timers RB_InactivityTimer and SignallingLinkInactivityTimer

If the capacity request is received from the UE or from the RNC’s within the RB_InactivityTimer, the DCH for NRT RB(s) is allocated.

If there is no activity in RB(s) within the RB_InactivityTimer and the inactivity of signalling link is detected (‘SignallingLinkInactivityTimer’ has also expired), the state transition from CELL_DCH to CELL_FACH is initiated


PS Connection Establishment

RNCUE SGSN

RRC Connection Establishment (SRB)

MM & CC (e.g. PDP Context Activation)

RAB Assignment RequestTraffic Volume Parameters

determination

Measurement Control [Traffic Volume Measurements]

CELL_DCH

Start• RB_InactivityTimer• SignallingLinkInactivityTimer

RB_InactivityTimerexpiry

Capacity Request?

DCH for NRT RB(s) allocation

no

yes

yes

SignallingLinkInactivityTimeexpiry

CELL_FACH


Transition from CELL_DCH to CELL_FACHThe UE connection can be moved from dedicated channel (CELL_DCH state) to common channel (CELL_FACH state) either through the expiration of an inactivity timer or via explicit signalling

At the beginning of the transition from CELL_DCH to CELL_FACH state the cell must be selected (or RNC can allow the UE make cell selection)

•The cell can be the same cell where the MS was in CELL_DCH state.•If the MS had also soft/softer HO branches then so-called reference (=the best) branch is used for the cell selection (or the RNC can command MS to make cell selection).

•The RNC's RRC signalling includes the latest known ‘Main Cell (Cell-ID)’ information in to the RRC message (i.e. RRC: RADIO BEARER RECONFIGURATION). Only the Cell-IDs of SRNC are used.

The inactivity timers for uplink and downlink are RNC configuration parameters InactivityTimerUplinkDCH and InactivityTimerDownlinkDCH.

When UE is in CELL_DCH state the UL and DL data streams are monitored by the RNC.•In case the RNC detects inactivity (nothing sent or received), it will indicate this to the RRM and RRC signalling entities of the RNC.

After receiving the inactivity indication, the RRC signalling entity defines and starts an inactivity timer (InactivityTimerUplinkDCH or InactivityTimerDownlinkDCH).

(continued)


Transition from CELL_DCH to CELL_FACHAfter the inactivity timer expires the RRC radio bearer reconfiguration–procedure is performed.RRC sends an RRC: RADIO BEARER RECONFIGURATION message to the UE.UE acknowledges by sending the RRC: RADIO BEARER RECONFIGURATION COMPLETE –message to the RRC signaling entity of the RNC

•which starts L2 reconfiguration (as well as PS is informed about the cell state change).

Radio link and AAL2 resources are then released and UE is changed to CELL_FACH state.

In case the UE is having RT RB which has become inactive and at the same time it is having inactive NRT RB then RADIO BEARER RELEASE procedure is used (instead of RADIO BEARER RECONFIGURATION).


Transition from CELL_DCH to CELL_FACH

RNCUECELL_DCH Node B

PDU Transport on the DCH/DPCH

All data is sent andRLC-U buffer is empty

Inactivity detected Start

InactivityTimerUplinkDCHInactivityTimerDownlinkDCH

Radio Bearer Reconfiguration

Radio Bearer Reconfiguration Complete

ExpiryCELL_FACH

L2 configuration

Radio Bearer Release

StartMAC: Inactivity detected

UL/DL activation timer


Transition from CELL_FACH to CELL_PCHCELL_FACH state is entered, by transition from URA_PCH state, by transition from CELL_PCH state or by transition from CELL_DCH state. In CELL_FACH state the MS performs the following actions:

• Performs (FDD intra-frequency) measurements and cell reselections• Listens all FACH transport channels on the selected S-CCPCH (Secondary Common

Control Physical Channel)Since the MS performs continuous reception of FACH in CELL_FACH state, it should be moved to the CELL_PCH state if the data service has not been active for a while.

This state transition is done when the RNC’s RRC timer UL/DL activation timer expires.• This timer is started when the RNC's MAC entity for MS indicates observed inactivity in

UL and DL direction.• Also, the state transition from CELL_FACH to CELL_PCH is done immediately after

successful Cell Update procedure due to 'cell reselection' or 'periodic cell update' in case the UE was in CELL_PCH before executing Cell Update procedure.

(continued)


The RNC's RRC signaling entity counts the number of cell reselections and number of periodic cell updates while the UE is in CELL_FACH state or CELL_PCH state.

If number of cell reselections exceeds a threshold value MaxCellReselections within timer CellReselectionObservingTime then the RNC's RRC signaling entity will command the UE to change its state after cell update procedure from CELL_FACH state to URA_PCH state instead of CELL_PCH state.

If the number of periodic cell updates exceeds MaxPeriodicalCellUpdates then the UE is ordered to change the state to URA_PCH.

The state change happens via normal cell updating procedure (in response to CELL UPDATE message i.e. CELL UPDATE CONFIRM message).

When the UE is transferred to CELL_PCH/URA_PCH state, the RNC’s RRC signaling entity shall start a state supervision timer MSActivitySupervision.

The RRC signaling entity stops the state supervision timer when state transition from CELL_PCH/URA_PCH state is initiated. The state supervision timer is reset when a periodic Cell Update is received and a RRC:CELL UPDATE CONFIRM message is sent to the UE.

After expiry of the supervision timer (no periodic Cell Update received from the UE, or any other UL activity detected) all reserved resources for this UE are released.

RRC State Transitions


Transition from CELL_FACH to ...

StartMAC: Inactivity detected

UL/DL activation timer

UECELL_FACH

CELL_FACH Cell Update

Cell UpdateCell Update Confirm

URA_PCH

MaxCellReselectionsCellReselectionObservingTimeandMaxPeriodicalCellUpdates

Start

Expiry

Expiry

RNC

analog inCELL_PCH

URA Update

URA UpdateURA Update Confirm

Inactivity detected

Transition to URA_PCH

MSActivitySupervision

URA_PCH

RRC-IDLE

CELL_PCH Radio Bearer Reconfiguration


The UE connection can be moved from common channel (CELL_FACH state) to dedicated channel (CELL_DCH state) if RNC has data waiting for the transmission in downlink or UE requests dedicated uplink capacity.

In uplink direction the need for the capacity is detected by the MAC of UE.UE makes the decision whether the common or dedicated channel type is used in uplink.UE requests dedicated capacity by sending an RRC: MEASUREMENT REPORT message on RACH to the

RRC signaling entity of RNC, which forwards the message to the RRM.After the procedure, data transmission on DCH can begin and UE is in CELL_DCH state.

In downlink direction the capacity need is detected by the UE MAC entity of RNC. It sends downlink capacity request directly to RRM.

After uplink and downlink packet scheduling, due to Uplink or Downlink capacity request PS requests resources from the RM.

PS requests the RRC signaling entity of RNC to start transport channel reconfiguration –procedure• The RRC signaling entity sends an RRC: TRANSPORT CHANNEL RECONFIGURATION message to

the UE on FACH, which is acknowledged with an RRC: TRANSPORT CHANNEL RECONFIGURATION COMPLETE

After the procedure, data transmission on DCH can begin and UE is in CELL_DCH state.

Transition from CELL_FACH to CELL_DCH



RNCUECELL_FACH Node B

UL & DL packet scheduling


Measurement Report (Traffic Volume Event)

CELL_DCH

Radio Link Setup


UE initiated



RNCUECELL_FACH Node B

DL capacity need isdetected by MAC


CELL_DCH

Radio Link Setup


RNC initiated

Channel type selection-> DCH

UL & DLpacket scheduling


Nokia ParametersRB_InactivityTimer• The timer is set after a DCH for a signaling link is allocated in RRC connection setup phase.

The timer is reset when any DL/UL activity detected (i.e. capacity request received from the MS or RNC's MAC-c). In expiry of the timer, the state transition from CELL_DCH to CELL_FACH is initiated when also the SignallingLinkInactivityTimer has expired.default value: 2s; range: 0 ... 20 s; step 0.5 s

SignallingLinkInactivityTimer• The timer is used for inactivity detection of the signaling link in CELL_DCH and CELL_FACH

states. The timer is set after inactivity of the signaling link is detected and reset when any activity detected. In expiry of the timer, a state transition from CELL_DCH to CELL_FACH (or from CELL_FACH to CELL_PCH) state is initiated when also the corresponding RB inactivity timer(s) expired. default value: 2s; range: 0 ... 20 s; step 0.5 s


Nokia ParametersInactivityTimerUplinkDCH• The time indicating how long the radio and transmission resources are reserved after silence

detection on uplink DCH before release proceduresrange: 8 kbps: 5 s, 16 kbps: 5 s, 32 kbps: 5 s, 64 kbps: 3 s, 128 kbps: 2 s, 256 kbps: 2 s, 320 kbps: 2 s, 384 kbps: 2 s

InactivityTimerDownlinkDCH• The time indicating how long the radio and transmission resources are reserved after silence

detection on downlink DCH before release proceduresrange: 8 kbps: 5 s, 16 kbps: 5 s, 32 kbps: 5 s, 64 kbps: 3 s, 128 kbps: 2 s, 256 kbps: 2 s, 320 kbps: 2 s, 384 kbps: 2 s

• Recommendation is to use 20 s for all services


Nokia ParametersUL/DL activation timer• This timer is set when the MS is transferred to CELL_FACH state due to inactivity, or MS

inactivity is detected in CELL_FACH state (CELL_FACH-> IDLE)default value: : 2s; Recommendation is to set this to 10srange: 50 ... 10000 ms; step 50 ms

MSActivitySupervision• The RNC supervises traffic of MS with only NRT RABs. When no data transfer is performed

during the defined time period, the RNC asks SGSN to release Iudefault value: 30 min; range: 0 ... 1440 min; step 1 min


Nokia ParametersCellReselectionObservingTime• Detailed description: The timer is set when first Cell Update message due to 'cell

reselection' is received while MS is in CELL_FACH or CELL_PCH state. In expiry of the timer, the counter MaxCellReselections is reset.default value: 10s; range: 0 ... 60 s; step 1 s

MaxCellReselections• The number of Cell Reselections in CELL_FACH or CELL_PCH state during

CellReselectionObservingTime before transition to URA_PCH state.default value: 3 times; This is set to 0 in RAN1.5.2ED2, cannot be changedrange: 0 ... 100 times; step 1 times

MaxPeriodicalCellUpdates• Counter for a number of Periodical Cell Updates in CELL_FACH or CELL_PCH state before

transition to URA_PCH statedefault value: 1 time; range: 0 ... 10 times; step 1 times


IdleMode

Cell_FACH

• Inactivity detection of NRT RB

• Release of RT RB

• Cell reselection (moving UE)

• Periodic cell update (stationary UE)

• Paging response (DL data/ signalling)

• UL Access (UL data/signalling)

• URA reselection Periodic URA update (stationary MS)

• Periodic URA update (stationary MS)

• Paging response (DL data / signalling)

• UL Access (UL data / signalling) Cell_

PCH

• Activity supervision• Completion of Cell Update procedure

• Setup of RT/NRT RB• RAB reconfiguration • DCH Up or Downgrade• Bit rate reduction due to load reasons

Cell_DCH

• CN originated paging (MT Call)• Random Access (MO Call)

URA_PCH

• Completion of URA Update procedure

• Max. number of periodic cell updates in Cell_FACH / Cell_PCH exceeded

• UL/DL data or signalling

• RT RB setup

RRC Connection Release

Summary


Cell_PCH

Cell_FACH

IdleMode

URA_PCH

Cell_DCH

RRC State TransitionExercise: Add parameters to all transitions!!!!




• Bitrate Upgrade




• In uplink direction the current total received interference power of a cell (PrxTotal) can be expressed as the sum of the non-controllable power (PrxNc) and the controllable power (PrxNrt).

• PrxNc consists of the powers of real-time users, other-cell users and noise.• PrxNrt consists of the powers influenced by PS

• In downlink direction the current total transmitted power of a cell (PtxTotal) can be expressed as the sum of the non-controllable power (PtxNc) and the controllable power, which is caused by NRT traffic (PtxNrt).

• The controllable power is used for NRT users on best effort basis by the packet scheduler.• The power available for best effort NRT traffic is the load target subtracted by the non-

controllable power.

• The bit rate allocation algorithm includes load increase and load decrease algorithms, which are the same in both uplink and downlink directions

nrtrxncrxtotalrx PPP ___ +=

nrttxnctxtotaltx PPP ___ +=

Power Budget for Packet Scheduling


Decrease loadingIncrease loading

Bit rate allocation algorithm

PrxTotal < PrxTarget NOYES

PrxTotal <PrxTarget + PrxOffsetYES

Allocate bit rates

end

NO

Calculate PrxAllowed

Bit Rate Allocation - Overview

nrtrxncrxtotalrx PPP ___ +=

non-controllable power

controllable power

inactivertrxinactivenrtrx

totalrxettrxallowedrx

PPPPP

____

_arg__

−−

−=

estimated received power of admitted RT bearers still in the in the establishment phase

estimated received power of RT admitted but currently inactive bearers

Example: UL


• In first phase PrxAllowed and PtxAllowed must be calculated by using:

where• PrxRtInative is the estimated received power of admitted RT bearers, which are not active yet

because establishment phase is still ongoing.• PrxNRTInative is the estimation of the the received power that inactive bearers would cause

when they are active.

• In the second phase the PrxTotal is compared to the PrxTarget and PtxTotal to PtxTarget• In case PrxTotal < PrxTarget then loading in UL is increased• In case PtxTotal < PtxTarget then loading in DL is increased

In case above two cases are full-filled either bitrate of existing NRT users is increased or new NRT user will get allocated bitrate.

• In case PrxTotal > PrxTarget then next checking is performed PrxTotal < PrxTarget + PrxOffset• In case PtxTotal > PtxTarget then next checking is performed PtxTotal < PtxTarget + PtxOffset

inactivertrxinactivenrtrxtotalrxettrxallowedrx PPPPP _____arg__ −−−=

inactiverttxinactivenrttxtotaltxetttxallowedtx PPPPP _____arg__ −−−=

Bit Rate Allocation - Overview


• Packet scheduling is done on a per-cell basis.

• Since asymmetric traffic is supported and the load may vary a lot between uplink and downlink, capacity is allocated separately for both directions

• When DCH is allocated to one direction, it also has to be allocated to the other direction as well even if there is no user data to be sent

• PS allocates low data rate to the DCH in "idle" direction for higher layer acknowledgements (TCP acknowledgements), L2 acknowledgements, L2 control and power control

• This low bit rate channel is called "return channel“.• Minimum allowed bit rate is the bit rate allocated for return channel.• The RNC configuration parameters MinAllowedBitRateUL and MinAllowedBitRateDL define the

bit rate that is allocated for return channel.

• PS operates periodically (same actions are repeated within a specified period).• This period is an RNC configuration parameter called SchedulingPeriod.• The scheduling period is normally the period between two cell based load information

messages received from LC (radio resource indication period, RRIndPeriod), but different value can also be configured.

Packet Scheduling Principles


Packet Scheduling and Load Control

RNCRadio Resource Indication

Node B

Radio Resource Indication



RRIndPeriod

Packet Scheduler decision frequency: SchedulingPeriod

nntPtPtP

P totalrxtotalrxtotalrxtotalrx

))1((...)1()( ____

−−++−+=

n = PSAveragingWindowSize

Averaged PrxTotal:

Averaged PtxTotal: (analog to averaged PrxTotal)

time


• Averaged PrxTotal and PtxTotal values are used by PS.

• PSAveragingWindowSize is a BTS specific RNC configuration parameter that defines how many PrxTotal/PtxTotal measurements, which are received in the NBAP: RADIO RESOURCE INDICATION –messages, are included in the sliding window used in averaging of PS

• PrxTotal used in PS estimations is averaged using the following formula:

nntPtPtP

P totalrxtotalrxtotalrxtotalrx

))1((...)1()( ____

−−++−+=

• where Prx_total(t) is the latest received PrxTotal measurement and n equals to PSAveragingWindowSize

• PtxTotal is averaged same way

Packet Scheduling and Load Control

n = PSAveragingWindowSize


Parameters for Packet SchedulingMinAllowedBitRateUL• This parameter defines the minimum allowed bit rate in uplink that can be allocated by the

PS.default value: 8 kbps; range: 8 kbps, 16 kbps, 32 kbps, 64 kbps, 128 kbps, 256 kbps, 384 kbps

MinAllowedBitRateDL• This parameter defines the minimum allowed bit rate in downlink that can be allocated by

the PS. default value: 32 kbps; range: 8 kbps, 16 kbps, 32 kbps, 64 kbps, 128 kbps, 256 kbps, 384 kbps

• In RAN1.5.2 MinAllowerBitrateUL is always 64 kbits/s and MinallowedbitrateDL can be 64,128 or 384 kbits/s


Parameters for Packet SchedulingSchedulingPeriod• This parameter defines how often the packet scheduler makes scheduling decisions, and

when it can start doing allocations.default value: 200 ms; range: 100 ... 2000 ms, step 100 ms

• Note: The value of the scheduling period should be set longer than (or equal) the Radio Resource Indication period (RRIndPeriod) in order to have the latest load information available for packet scheduling.

RRIndPeriod• The parameter defines the reporting period of the Radio Resource Indication messages,

which are used for cell based load measurements.default value: 200 ms; range: 0 ... 2000 ms, step 100 ms.

• With the Radio Resource Indication message the BTS reports periodically the total uplink interference power of the cells and the total transmitted power of the cell and RACH.


PSAveragingWindowSize• The parameter defines how many PrxTotal/PtxTotal measurements, which are received in

the NBAP: RADIO RESOURCE INDICATION - messages, are included in the sliding window averagingdefault value: 5; range: 1 ... 20 , step 1

Parameters for Packet Scheduling

Individual Measurement Values 4 1 3 5 7 10 6Averaging Window Size = 3 5.0 7.3 7.7Averaging Window Size = 4 4.0 6.3 7.0Averaging Window Size = 5 4.0 5.2 6.2




• Bitrate Upgrade




• In the uplink direction the UE sends a traffic volume event trigger RRC measurement report to the RNC, if:

• the data amount in the RLC buffer exceeds/drops below TrafVolThresholdULLow, the UE sends a traffic volume measurement (used in the state CELL_FACH).

• the data amount in the RLC buffer exceeds/drops below TrafVolThresholdULHigh the UE sends a traffic volume measurement (used in the state CELL_DCH).

• the UE does not receive a DCH allocation or bit rate upgrade, it resends the traffic volume measurement after a time period defined by TrafVolPendingTimeUL

• RNC participates to the uplink channel type selection procedure by setting the relevant parameters to UE for traffic volume measurements, which are included in the RRC: MEASUREMENT CONTROL message. Given traffic volume events reported by the UE, the RNC can decide, whether a state transmission takes place.

UE is in CELL_FACH state• When data amount in RLC transmission buffer exceeds a threshold value, UE sends traffic volume

measurement report including 'RB identity' and 'RLC transmission buffer payload‘.• The lower threshold value, which sets the traffic volume measurement reporting criteria is a radio

network planning parameter (TrafVolThresholdULLow)• Traffic volume measurement report from UE is handled as uplink capacity request in RNC, which

means request for DCH allocation when DCH is not allocated and DCH bit rate upgrade request when low bit rate DCH is allocated.

• Uplink traffic volume measurement report is included in the RRC: MEASUREMENT REPORT message.

UL Traffic Volume Based RRC State Transition


UL Traffic Volume Based RRC State TransitionReporting event:

4A: Transport Channel Traffic Volume becomes larger than an absolute threshold

time

Transport ChannelTraffic Volume

(= UE Ruffer Load)

Thresholds

4A 4A 4A

RNCUEMeasurement Report (Traffic Volume Event)

UE in CELL_FACH: TrafVolThresholdULLow (128 Bytes)UE in CELL_DCH: TrafVolThresholdULHigh (1024 Bytes)

Measurement Report (Traffic Volume Event)TrafVolPendingTimeUL (2s)

4A 4AMeasurement

report has information about

currentUE buffer load


In the downlink the process is the same:• When the data amount in the RLC buffer exceeds TrafVolThresholdDLLow, the UE specific entity

within the RNC reports a traffic volume measurement.• When the amount in the RLC buffer exceeds TrafVolThresholdDLHigh the UE specific entity

within the RNC reports a traffic volume measurement.• If the UE does not receive a DCH allocation or bit rate upgrade, UE specific entity within the

RNC reports the traffic volume measurement after a time period defined by TrafVolPendingTimeDL again.

DL Traffic Volume Based RRC State Transition


NRT bit rate allocation method

• The traffic volume measurement reports are classified into the following three types:

1. Initial request for low bit rate (UL/DL); when• The NRT RB in question has no previous DCH allocation• RLC buffer payload < TrafVolThresholdDLHigh or TrafVolThresholdULHigh• Low bitrate means minimum bitrate

2. Initial request for high bit rate (UL/DL); when• The NRT RB in question has no previous DCH allocation• RLC buffer payload => TrafVolThresholdDLHigh or TrafVolThresholdULHigh

3. Upgrade request for high bit rate (DL); when• The NRT RB in question has a low bit rate DCH allocation• RLC buffer payload => TrafVolThresholdDLHigh or TrafVolThresholdULHigh


Uplink traffic volume measurements

Traffic volume measurement not triggered

RLC

buff

er p

aylo

adRL

C bu

ffer

pay

load

(tra

nspo

rt c

hann

el t

raff

ic v

olum

e)(t

rans

port

cha

nnel

tra

ffic

vol

ume)

UL data transmission on RACH in

CELL_FACH state

UL data transmission on DCH in CELL_DCH

state

TrafVolThresholdULLow (Cell parameter)

4A


Downlink traffic volume measurements

RLC

buff

er p

aylo

adRL

C bu

ffer

pay

load

(tra

nspo

rt c

hann

el t

raff

ic v

olum

e)(t

rans

port

cha

nnel

tra

ffic

vol

ume)

TrafVolThresholdDLLow (Cell parameter)

TrafVolThresholdDLHigh (RNC parameter)

DL data transmission on FACH in

CELL_FACH state

DL data transmission on DCH in CELL_DCH

state

Traffic volume measurement not triggered

Traffic volume measurement triggered, request for low bit rate

Traffic volume measurement triggered, request for high bit rate


Possible cases for packet scheduling function

Preconditions Postconditions

Channel allocation Channel allocation Case UE state

UL DL

Trigger UE state UL DL

1 Cell_FACH - - Data arrives to UE RLC buffer

data_amount < TrafVolThresholdULLow (ul capacity request not triggered)

Cell_FACH RACH FACH

2 Cell_FACH - - Data arrives to RNC RLC buffer

data_amount < TrafVolThresholdDLLow (dl capacity request not triggered)

Cell_FACH RACH FACH

Data transmission on common channels in CELL_FACH stateData transmission on common channels in CELL_FACH state



Channel allocation Channel allocationCase UE state

UL DL

Trigger UE stateUL DL

3 Cell_FACH - -

Data arrives to UE RLC bufferTrafVolThresholdULLow

< data_amount < TrafVolThresholdULHigh(ul capacity request triggered )

Cell_DCH DCHlow

DCHlow

4 Cell_FACH - -

Data arrives to RNC RLC bufferTrafVolThresholdDLLow

< data_amount < TrafVolThresholdDLHigh(dl capacity request triggered)

Cell_DCH DCHlow

DCHlow

5 Cell_FACH - -Data arrives to UE RLC buffer

data_amount > TrafVolThresholdULHigh(ul capacity request triggered)

Cell_DCH DCHhigh

DCHlow

6 Cell_FACH - -Data arrives to RNC RLC buffer

data_amount > TrafVolThresholdDLHigh(dl capacity request triggered)

Cell_DCH DCHlow

DCHhigh

Channel switching from CELL_FACH to CELL_DCH stateChannel switching from CELL_FACH to CELL_DCH state


• DCH low bitrate is defined as parameter of MinAllowedBitRateUL or MinAllowedBitRateDL

• DCH high bitrate is based on the capacity situation in the cell (power change estimation).



Channel allocation ChannelallocationCase UE state

UL DL

Trigger UE stateUL DL

7 Cell_DCH - -Data arrives to UE RLC buffer

data_amount < TrafVolThresholdULHigh(ul capacity request triggered)

Cell_DCH DCHlow

DCHlow

8 Cell_DCH - -Data arrives to RNC RLC buffer

data_amount < TrafVolThresholdDLHigh(dl capacity request triggered)

Cell_DCH DCHlow

DCHlow

9 Cell_DCH - -Data arrives to UE RLC buffer

data_amount > TrafVolThresholdULHigh(ul capacity request triggered)

Cell_DCH DCHhigh

DCHlow

10 Cell_DCH - -Data arrives to RNC RLC buffer

data_amount > TrafVolThresholdDLHigh(dl capacity request triggered)

Cell_DCH DCHlow

DCHhigh

DCH setup in CELL_DCH stateDCH setup in CELL_DCH state




Channel allocation Channel allocation Case UE state

UL DL

Trigger UE state UL DL

11 Cell_DCH DCH low

DCH low

Data arrives to UE RLC buffer data_amount > TrafVolThresholdULHigh

(ul capacity request triggered) Cell_DCH DCH

high DCH low

12 Cell_DCH DCH low

DCH low

Data arrives to RNC RLC buffer data_amount > TrafVolThresholdDLHigh

(dl capacity request triggered) Cell_DCH DCH

low DCH high

13 Cell_DCH DCH low

DCH high

Data arrives to UE RLC buffer data_amount > TrafVolThresholdULHigh

(ul capacity request triggered) Cell_DCH DCH

high DCH high

14 Cell_DCH DCH high

DCH low

Data arrives to RNC RLC buffer data_amount > TrafVolThresholdDLHigh

(dl capacity request triggered) Cell_DCH DCH

high DCH high

DCH reconfiguration (bit rate upgrade) in CELL_DCH stateDCH reconfiguration (bit rate upgrade) in CELL_DCH state



TrafVolThresholdULLow• This parameter defines, in bytes, the threshold of data in the RLC buffer of RB that triggers

the uplink traffic volume measurement report, when the UE is in Cell_FACH state.

• Otherwise, UE sends data on RACH.

• This parameter is sent to the UE using an RRC: MEASUREMENT CONTROL message.

default value: 128 bytes; range: 8 bytes, 16 bytes, 32 bytes, 64 bytes, 128 bytes, 256 bytes, 512 bytes, 1024 bytes (1 KB)

TrafVolThresholdULHigh• The parameter defines the threshold of data in RLC buffer of RB in bytes.

• The parameter is sent to the UE using the RRC: MEASUREMENT CONTROL message.

default value: 1024 bytes; range: 8 bytes, 16 bytes, 32 bytes, 64 bytes, 128 bytes, 256 bytes, 512 bytes, 1024 bytes (1 KB), 2048 bytes (2 KB), 3072 bytes (3 KB), 4096 bytes (4 KB)



TrafVolPendingTimeUL• This parameter indicates the period of time, in seconds, during which it is forbidden to send

any new traffic volume measurement reports with the same measurement ID, even if the triggering condition is fulfilled again.

• Parameter is sent to UE using an RRC: MEASUREMENT CONTROL message.

default value: 2000 ms; range: 250 ms, 500 ms, 1000 ms, 2000 ms, 4000 ms, 8000 ms, 16000 ms

• Note: The same value should be set in all cells within a Node B.

TrafVolTimeToTriggerUL• This parameter defines, in ms, the period of time between the timing of event detection and

the timing of sending a traffic volume measurement report.

• This parameter is sent to the UE using an RRC: MEASUREMENT CONTROL message.

default value: 0 ms; range: 0 ms, 10 ms, 20 ms, 40 ms, 60 ms, 80 ms, 100 ms, 120 ms, 160 ms, 200 ms, 240 ms, 320 ms, 640 ms, 1280 ms, 2560 ms, 5000 ms



TrafVolThresholdDLLow• This parameter defines, in bytes, the threshold of data in the RLC buffer of RB that triggers

the downlink traffic volume measurement report (capacity request) on MAC, when UE is in Cell_FACH state. Otherwise, RNC sends data on FACHdefault value: 128 bytes;range: 0 bytes, 8 bytes, 16 bytes, 32 bytes, 64 bytes, 128 bytes, 256 bytes, 512 bytes, 1024 bytes (1 KB)

TrafVolThresholdDLHigh• This parameter defines the threshold of data in the RLC buffer of RB in bytes which triggers

downlink traffic volume measurement report (capacity request) on MAC, when UE is in a Cell_DCH state and the initial bit rate DCH is allocated for the radio bearerdefault value: 1024 bytes;range: 0 bytes, 8 bytes, 16 bytes, 32 bytes, 64 bytes, 128 bytes, 256 bytes, 512 bytes, 1024 bytes (1 KB), 2048 bytes (2 KB), 3072 bytes (3 KB), 4096 bytes (4 KB)



TrafVolTimeToTriggerDL• This parameter defines, in ms, the period of time between the timing of event detection and

the timing of sending a downlink capacity request.default value: 0 ms; range: 0 ms, 10 ms, 20 ms, 40 ms, 60 ms, 80 ms, 100 ms, 120 ms, 160 ms, 200 ms, 240 ms, 320 ms, 640 ms, 1280 ms, 2560 ms, 5000 ms

TrafVolPendingTimeDL• This parameter indicates the period of time, in ms, during which it is forbidden to send any

new downlink capacity requests with the same RB id, even if the triggering condition is fulfilled again.default value: 2000 ms; range: 250 ms, 500 ms, 1000 ms, 2000 ms, 4000 ms, 8000 ms, 16000 ms





• Bitrate Upgrade




The channel selection procedure the following parameters are needed:

• Downlink traffic volume measurement low threshold (TrafVolThresholdDLLow)

• Maximum allowed total data amount on FACH (FachDataAllowedTotal)

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

(A) Maximum allowed user data amount on FACH exceeded

(B) Maximum allowed total data amount on FACH exceeded

(C) FACH in overload(D) FACH usage forbidden by PS

Request DCH from PSInitial transmission

on FACH

Channel Type SelectionChannel type selection

(A)

(B)

(C)

(D)

end

No

No

No

No

Yes

Yes

Yes

Yes


FACH is in overload when FACH load exceeds FachLoadThresholdCCH. FACH usage is possible again when the FACH load is decreased under threshold by margin FachLoadMarginCCH.

FACH usage is forbidden by PS when RACH load exceeds RachLoadThresholdCCH or when PtxTotalexceeds PtxThresholdCCH. When one or both of the conditions are fulfilled, PS indicates that FACH usage is forbidden.

FACH usage is possible again when the RACH load and PtxTotal are decreased below thresholds set by margins RachLoadMarginCCH and PtxMarginCCH.

DL Traffic Type Selection


DL Traffic Type Selection

time

FACH overload FachLoadThresholdCCH/RachLoadThresholdCCH

FachLoadMarginCCH/RachLoadMarginCCH

FACH in overload

FACH usage ok

time

FACH forbidden

FACH in overload

FACH usage ok

PtxThresholdCCH

PtxMarginCCH

Load

Power / Load


FachDataAllowedTotal• This parameter defines the maximum amount of user data in all RLC buffers that can be

transmitted at any given time on FACH (FACH is already selected).default value: 1024 bytes; range: 0 bytes, 8 bytes, 16 bytes, 32 bytes, 64 bytes, 128 bytes, 256 bytes, 512 bytes, 1024 bytes (1 KB), 1536 bytes, 2048 bytes (2 KB), 3072 bytes (3 KB), 4096 bytes (4 KB), 6144 bytes (6 KB), 8192 bytes (8 KB), 12288 bytes (12 KB), 16384 bytes (16 KB), 24576 bytes (24 KB), 32768 bytes (32 KB)

FACH/RACH Load Related Parameters


RachLoadThresholdCCH• The threshold for the total load of RACH channel for uplink channel type selection. If the

threshold is exceeded, DCH is allocated.default value: 75%; range: 0 ... 100%; step 1%

RachLoadMarginCCH• The margin for the RACH load for downlink channel type selection

• When the measured load is below the set threshold by this margin, FACH usage is possible.

default value: 5%; range: 0 ... 100%; step 1%



FachLoadThresholdCCH• The threshold for the total load of SCCPCH (FACH/PCH) channel for downlink channel type

selection. If the threshold is exceeded, DCH is allocated.default value: 75%; range: 0 ... 100%; step 1%

FachLoadMarginCCH• The margin for the total load of SCCPCH (FACH/PCH) for downlink channel type selection.

When the measured load is below the threshold by at least this margin, FACH usage is possible.default value: 5%; range: 0 ... 100%; step 1%



PtxThresholdCCH• This is the threshold for the total downlink transmission power for downlink channel type

selection

• If the threshold is exceeded, a DCH is allocated. Assumption here is that a DCH is more efficient than a FACH, due to fast power control.

• Relative to PtxTarget

default value: -1 dB; range: -5 ... 0 dB; step 0.1 dB

PtxMarginCCH• The margin for the total downlink transmission power for downlink channel type selection

• When the measured load is below the threshold by this margin, FACH usage is possible.

default value: 0.5dB; range: 0 ... 2 dB; step 0.1 dB





• Bitrate Upgrade




There are separate queues for uplink and downlink capacity request messages.

If the packet scheduler is not able to allocate capacity requests for every radio bearer, these un-full-filled requests remain in the queue.

There is a time limit how long the request can stay in the queue• This limit is set by using RNC configuration parameters CrQueuingTimeUL and

CrQueuingTimeDL, separately for uplink and downlink.• When the limit is exceeded for the certain capacity request, it is permanently

removed from the queue.• New capacity request is then required when allocation is needed for that bearer

CrQueuingTimeUL and CrQueuingTimeDL parameters are related to the parameters TrafVolPendingTimeUL and TrafVolPendingTimeDL, which define the time between consecutive capacity requests

• These parameters should be set accordingly

Processing of Capacity Request


new capacity request for a change in data

rate?

No

Yes

New capacity request

No

Modify the content type of the original capacity request in a queue

Delete the new capacity request

YesDelete the request

Start scheduling process(A) Capacity request from UE already in a queue?

(B) Is new capacity request same as original?

(A)

(B)


CrQueuingTimeULCrQueuingTimeDL

based on• Arrival time• Bearer class• Traffic handling priority

CrHandlingPolicyULCrHandlingPolicyDL


The Packet Scheduler can arrange the capacity requests for DCH scheduling according to the following criteria:

• Arrival time of capacity request • Bearer class (interactive class, background class)• Traffic handling priority within bearer class

When the arrival time of the capacity request is taken into account, the oldest capacity request, which has been in the queue longest is treated first (First in – First out).

Bearer class may be taken into account, so that interactive class bearers always have higher priority than background class bearers and should be scheduled first.

Traffic handling priority within bearer class may be taken into account to distinguish bearers within same bearer class. Traffic handling priority is defined for interactive class bearers only. It has a following range: 1(highest), 2,3,…14(lowest), 15 (no priority used).

The policy how the capacity requests should be handled can be set by the operator using parameters CrHandlingPolicyUL and CrHandlingPolicyDL.



CrQueuingTimeUL• This parameter defines how long an uplink capacity request can stay in the queue

before it is permanently removed.default value: 4 sec; range: 1 ... 30 sec; step 1 sec

• Note: This value should be the same as TrafVolPendingTimeUL

TrafVolPendingTimeUL• This parameter indicates the period of time, in seconds, during which it is forbidden

to send any new traffic volume measurement reports with the same measurement ID, even if the triggering condition is fulfilled again. Parameter is sent to UE using an RRC: SYSTEM INFORMATION or an RRC: MEASUREMENT CONTROL message.

default value 4000 ms; range: 250 ms, 500 ms, 1000 ms, 2000 ms, 4000 ms, 8000 ms, 16000 ms

• Note: This value should be set the same in all cells within a BTS



CrQueuingTimeDL• This parameter defines how long an downlink capacity request can stay in the

queue before it is permanently removed.default value:4 sec; range: 1 ... 30 sec; step 1 sec

• Note: This value should be the same as TrafVolPendingTimeDL

TrafVolPendingTimeDL• This parameter indicates the period of time, in milliseconds, during which it is

forbidden to send any new downlink capacity requests with the same RB id, even if the triggering condition is fulfilled again.default value: 4000 ms; range: 250 ms, 500 ms, 1000 ms, 2000 ms, 4000 ms, 8000 ms, 16000 ms

• Note: This value should be set the same in all cells within a BTS



CrHandlingPolicyUL• This parameter defines the criteria which are taken into account when the capacity

requests are arranged for DCH scheduling.

default value: 2

range: 1 (arrival time only), 2 (arrival time and bearer class), 3 (arrival time, bearer class and traffic handling priority)

CrHandlingPolicyDL• This parameter defines the criteria which are taken into account when the capacity

requests are arranged for DCH scheduling.

default value: 2range: 1 (arrival time only), 2 (arrival time and bearer class), 3 (arrival time,

bearer class and traffic handling priority)




• Packet Transfer States & Parameters• Bitrate Allocation• Channel Type Selection• Capacity Request & Traffic Volume Measurements • Processing a Capacity Request

• Bitrate Upgrade




• In case PrxTotal < PrxTarget and/or PtxTotal < PtxTarget then the load increase algorithm will take place (UL and/or DL):First the Capacity Requests (CRs) in queue are checked and in case there are NRT CRsthey are first accepted in priority order. For each CR PrxTotalNew and PtxTotalNew, are calculated:

where: P_totalchange is the power change estimation.For each CR PrxNrtNew and PtxNrtNew are calculated based on the new or bitrateincrease (to be scheduled) radio bearer Eb/No requirement (bitrate requirement).

• Note : the upgrade will happen in the case of RLC buffer payload =>TrafVolThresholdDLHigh or TrafVolThresholdULHigh

Initial bitrate allocation & Bitrate upgrade

changetotalrxtotalrxnewtotalrx PPP _____ +=

changetotaltxtotaltxnewtotaltx PPP _____ +=


Any CRs in queueStart from

CR #1

Estimate PrxTotalNew andPrxNrtNew

Bit rate = MinAllowedBitRate

Increase loading

(A) PtxTotalNew < PtxTarget ANDPtxTotalChange < DeltaPtxMaxUpPtxNrtNew < PtxAllowed

(A)

End

Yes

NoNo

Bitrate Upgrade Process

changetotaltxtotaltxnewtotaltx PPP _____ +=

Example: DL

Yesmore CRsin queue

Move toNext CR inQueue

HigherAllowed Bitrates

Move toNext higher

bitrate

NoYes


• In the next phase the calculated PrxTotalNew, PtxTotalNew, PrxTotalChange, PtxTotalChange,PrxNrtNew and PtxNrtNew are compared against thresholds and bitrates are increased (orbitrate allocated to the new CR) in case:

• UL• PrxTotalNew < PrxTarget (RNC parameter)• PrxTotalChange < DeltaPrxMaxUp (RNC parameter)• PrxNrtNew < PrxAllowed (calculated in Power budget for packet scheduling UL

section)• DL

• PtxTotalNew < PtxTarget (RNC parameter)• PtxTotalChange < DeltaPtxMaxUp (RNC parameter)• PtxNrtNew < PtxAllowed (calculated in Power budget for packet scheduling UL

section)• It should be noted that in case DCH is allocated it must always be bi directional (at least

minimum bitrate must be possible, increase algorithm can work in either direction independently).

• Based on the load increase algorithm following examples can be made (minimum allowedbitrate 128kbps assumed) – see next slide:

Bit Rate upgrade process


128 (1) 256 (1) 384 (1)

PrxTarget

Step 1 Step 2 Step 3

No higher bit rateavailable, allocationaccording to step 3

128 (1)

128 (2)256 (1)

128 (2)

256 (1)

256 (2)

384 (1)

256 (2)PrxTarget

Step 1 Step 2 Step 3 Step 4

128 (1)

Step 5

Target exceeded,allocation according

to step 4

case 1: 1 CR in queue

case 2: 2 CRs in queue

128 (1)128 (2)

128 (3)

256 (1)

256 (2)

PrxTarget


128 (1)

Step 5

128 (2)128 (1)

128 (3)128 (2)

256 (1)

128 (3)


to step 4

128 (1)128 (2)

128 (3)

PrxTarget


128 (1)

Step 5

128 (2)128 (1) 128 (1)

128 (2)128 (3)128 (4)

256 (1)

128 (3)128 (2)

128 (4)


to step 4

128 (1)128 (2)

128 (3)

PrxTarget


128 (1)

Step 5

128 (2)128 (1) 128 (1)

128 (2)128 (3)128 (4)

128 (1)128 (2)128 (3)128 (4)128 (5)


to step 4, noallocation to CR #5




Bit Rate Allocation – Increase Load


• If case PrxTotal > PrxTarget or if PtxTotal > PtxTarget then next checking is performed PtxTotal (PrxTotal)< PtxTarget (PrxTarget) + PtxOffset (PrxOffset) (=PrxTargetBTS & PtxTargetBTS).

• In case the latter equation PtxTotal > PtxTargetBTS (or PrxTotal >PrxTargetBTS) then loading is decreased if not then previously scheduled loading is maintained i.e. no increase in bitrate.

• If the load is too high PS starts to decrease the bit rates of the NRT bearers.The bit rates can not be decreased lower than the MinAllowedBitRateUL or MinAllowedBitRateDL.

Bit Rate Allocation – Increase Load



• Packet Transfer States & Parameters• Bitrate Allocation• Channel Type Selection• Capacity Request & Traffic Volume Measurements • Processing a Capacity Request

• Bitrate Upgrade




PrxNrtNew

Overload Control (TFCC)Example: UL

Reduce to nextlower bit rate

Estimate PrxTotalNew and

Lower bit ratesallowed

Switch bearerto CCH

More bearers

Decrease loading

Select randomly one of thehighest bit rate bearers

(A) PrxTotalNew > PrxTarget ANDPrxTotalChange < DeltaPrxMaxDown

(A)End

Yes

No

Yes

No

No

Yes

TFCC means TransportFormat Combination

Control Procedure, noDCH Downgrade but

suspend of highertransport formats


AC produces the TrCH parameters:

• Transport Formats (TF)

• Transport Format Combination (TFC)

• TFC identifiers

Overload Control (TFCC)

SupportedBitrates

0

TFCS (SL & RT RB)

TrCh 1

TFI0

TFI164

128

384

0

TFI2384

128

Peak BitrateIn Bearer

Parameters

SheduledBitrate

TFS for RT RBintermediate

Bitrates

64

128

0

TFS subsetFor TFCS

construction

64

0

TrCh 2

TFI0

TFI1

0

64

0

TFI1

TFI0TFI0

TFCC here


• When overload is detected and dedicated channel is modified using Transport Format Combination Control(TFCC) –procedure, physical resources are not modified. it takes some time before the decrease in load (PrxTotal and PtxTotal) as can be seen in RNC from the NBAP: RADIO RESOURCE INDICATION messages.

• This delay may be longer than scheduling period and therefore it is necessary to wait that load control actions have effected, in order to prevent new unnecessary load control actions in the next scheduling period

• The parameter LoadControlPeriodPS determines the period how often PS can perform load control actions

• The selection of the bearers, whose transport formats combinations are modified, is done randomly but Bearer classes are taken into account so that the load decreased is performed in the following order:

1. DCH Bit rates of the Background class bearers are decreased in random order (not belowMinAllowedBitRateUL or MinAllowedBitRateDL)

2. DCH Bit rates of the Interactive class bearers are decreased in random order (not belowMinAllowedBitRateUL or MinAllowedBitRateDL)

3. Background class bearers are switched from DCH to CCH in random order4. Interactive class bearers are switched from DCH to CCH in random order

Overload Control


Example: DL Dedicated Channel Modification

BTS RNC-L2RNC-NBAP RNC-RRC RNC-RRM

BTS providesperiodical cell loadinformation to RRM

packet scheduling

PS indicates UE aboutthe modified capacityand selected UL TFC

subset

NBAP: RADIO RESOURCE INDICATION

UE

IubUu

RLC-PDU transportation on DCH

RR_ind

Capacity_modify

RLC-PDU transportation on modified DCH

UE in CELL_DCH state

[DCH] RRC: TRANSPORT FORMAT COMBINATION CONTROL

RRM detects overloadsituation in uplink


• In the next phase it is checked whether the selected bearer is already having the lowest possiblebitrate (according to MinAllowedBitRateUL and MinAllowedBitRateDL).

• in case minimum is reached then CCH is selected• in case minimum is not reached then bit rate is decreased to the next lower level

• PrxNrtNew and PtxNrtNew are calculated as in load increase algorithm.

• In the next step the following checks are done to see whether performed bitrate modifications are enough to decrease the loading below the PtxTarget + PtxOffset / PrxTarget + PrxOffset

• PrxTotalNew > PrxTarget• PtxTotalNew > PtxTarget

&• PrxTotalChange < DeltaPrxMaxDown• PtxTotalChange < DeltaPtxMaxDown

In case the above equations are true then more bearers' bitrates should be decreased (in case no more bearers available then ModificationPeriod time must be expired before new modification can be done for the bearers in question).

• The following pictures describe the operation of load decrease algorithm.

Overload Control


• In case of 3 bearers

• In case of 6 bearers

384

PrxTarget

Step 1 Step 2 Step 3

384

256

384

256

256

256

256

256

Step 1: 384 -> 256 (TFCC)Step 2: 384 -> 256 (TFCC)Allocation according to step 3

PrxTarget128

128

128


128

256

256

128

128

128

256

128

128

128

128

128

128

128

128

128

128128

128

128 Step 1: 256 -> 128 (TFCC)Step 2: 256 -> 128(TFCC)Step 3: 128 -> CCH (Radio Bearer Reconfiguration)Allocation according to step 4

Overload Control


• When the maximum bit rates of the NRT RBs are decreased (by TFCC procedure) 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

Overload Control


DeltaPrxMaxUp (not implemented in RAN1.5.2 ED2)• Defines the maximum received uplink power increase in a cell, used when bit rates are allocated or

increased by the packet scheduler, relative to PrxTotal.default value: 1.6dB; range: 0 ... 5 dB, step 0.2 dB

DeltaPtxMaxUp (not implemented in RAN1.5.2 ED2)• Defines the maximum transmitted downlink power increase in a cell, used when bit rates are

allocated or increased by the packet scheduler, relative to PtxTotal.default value: 1.6dB; range: 0 ... 5 dB, step 0.2 dB

Bit Rate Allocation


LoadControlPeriodPS• This parameter defines how often PS can perform load control actions for each bearer.

default value: 400ms; range: 100 ... 2000 ms, step 100 m

• Note: The value must not be smaller than scheduling period.

DeltaPtxMaxDown(not implemented in RAN1.5.2 ED2)• Defines the maximum transmitted downlink power decrease in a cell, used when bit rates are

decreased by the packet scheduler, relative to PtxTotal.default value: 3dB; range: 0 ... 5 dB, step 0.2 dB

DeltaPrxMaxDown(not implemented in RAN1.5.2 ED2)• Defines the maximum received uplink power decrease in a cell, used when bit rates are decreased by

the packet scheduler, relative to PrxTotal.default value: 3dB; range: 0 ... 5 dB, step 0.2 dB

Bit Rate Allocation



• Packet Transfer States & Parameters• Bitrate Allocation• Capacity Request & Traffic Volume Measurements • Channel Type Selection• Processing a Capacity Request

• Bitrate Upgrade




Dynamic Link Optimisation(DLO) for NRT Traffic Coverage

BTSBTSBTSBTS

UEUEUEUE

384kbps384kbps384kbps384kbps128kbps128kbps128kbps128kbps

Improved NRT traffic coverage

distanceRadio link is modified to use lower

bit rate when WBTS Tx power is getting close to maximum


Triggering of Dynamic Link Optimisation

time

Ptx, RLdistance

Ptx, ave

Triggering of DyLO

Ptx, maxOffset

Ptx, ave is averaged radio link power, measured and reported to RNC by BTS

Ptx, max is determined by admission control

The value of the Offset is fixed, 2 dB

Dynamic link optimisationis triggered if

Ptx, ave > Ptx, max - Offset


Decision algorithmMeasurementReportPtx,ave

(Ptx,ave + Offset) >Ptx,max

Select DCH(s) to bedowngraded

Requirements OK(min allowed bitrate,

SF, puncturing)

Reduce DCH bitrate(s) Reconfiguration notpossible

Compressed Modeactive

Guard timer active

No

Yes

No

Yes

No

No

Yes

Yes

Triggering of DyLO

DyLO is not possible during compressed mode

DyLO is possible for NRT DCH allocations that have lasted at least 2 seconds (fixed guard time)

Not applicable in RAN1.5 (only 1 NRT DCH possible per UE)

• SF is doubled (physical channel bit rate reduced to half of the original)

• Additional puncturing is not allowed• DyLO cannot reduce bit rate below the Initial and

minimum allowed bit rate in downlink (RAN1.5.2ED CD19)

• DyLO can be started only if the current bit rate is higher than Maximum Allowed DL User Bitrate in HHO (enable compressed mode due to DL power)


Bit Rate Upgrade• After downgrade of DCH bit rate due to DyLO, upgrade of the bit rate

can be performed from the initial bit rate level• Cell level parameter Initial and minimum allowed bit rate in

downlink is configurable by operator• Bit rate upgrade from any other bit rate is not possible• Bit rate upgrade is based on downlink traffic volume measurement

reports (capacity requests)• The change of the radio link power conditions does not trigger

upgrade• Possible triggering of the DyLO is checked before the bit rate is

upgraded, in order to avoid ping-pong effect (RAN1.5.2ED2)• New Ptx, max is calculated by AC according to the new bit rate• Initial Tx power Ptx, init is calculated by AC according to the new

bit rate• DyLO is possible if Ptx, init < (Ptx, max – Offset)• If inequality is not valid, the next lower bit rate is tried

Fixed, 2 dB


Related Parameters – operator controllable• WCEL: PtxDLAbsMax - Planned maximum downlink transmission power of a radio link

• The planned maximum downlink transmission power of radio link. This parameter is used in the downlink power allocation when CCTrCH includes one or more DCH's of interactive or background traffic class RAB's. The allocated power of a radio link cannot exceed the value of this parameter. The parameter is set separately for each cell. This parameter is the planned maximum, not the physical limit.

• -10...50 dBm, step 0.1 dBm, default 50 dBm

• WBTS: PtxDPCHmax - DPCH downlink transmission power maximum value• Parameter defines the maximum code channel output power for the power control dynamic range of BTS. The power

control dynamic range of BTS is the difference between the maximum and the minimum transmit output power of a code channel. The maximum transmission power is calculated by adding the value of the parameter to the BTS maximum output power (Pmax in dBm).

• -3...0 dB, step 0.1 dB, default –3 dBm

• WCEL: MinAllowedBitRateDL - Initial and minimum allowed bit rate in downlink• This parameter defines the minimum allowed bit rate in downlink that can be allocated by the PS. The allocated bit

rate corresponds to the highest bit rate in the TFS from which the TFCS is constructed.• 64, 128, 384 kbps, default 64 kbps (RAN1.5)• 8, 16, 32, 64, 128, 384 kbps, default 32 kbps (RAN04)• 8, 16, 32, 64, 128, 256, 384 kbps, default 32 kbps (RAN05)

• WCEL: HHoMaxAllowedBitrateDL - Maximum Allowed DL User Bitrate in HHO• This parameter determines the bitrate threshold which the maximum allocated user bitrate on the downlink DPCH

may not exceed in order for the inter-frequency or inter-RAT (GSM) handover to be possible due to high downlink DPCH power level.

• 64, 128, 384 kbps, default 64 kbps (RAN1.5)• 32, 64, 128, 384 kbps, default 64 kbps (RAN04)• 32, 64, 128, 256, 384 kbps, default 64 kbps (RAN05)


Related Parameters – fixed• Dynamic link optimisation usage

• Always used

• Downlink transmission power offset for dynamic link optimisation• 2 dB

• Guard time for dynamic link optimisation• 2 s


Restrictions

• Radio link under DRNC• Radio link under DRNC cannot trigger DyLO

• Transmission resources• The reconfiguration of Iub AAL2 transmission resources is not

performed due to DyLO

• Compressed mode• DyLO is not allowed during the compressed mode measurements


Bitrate Upgrade Possibilities in Nokia RAN

SF32(64k) SF8(384k) SF16(128k)

SF32(64k) SF8(384k)

CELL-FACH SF32(64k) SF8(384k)

SF32(64k) SF8(384k) SF16(128k) SF8(384k)×

○

○

With Max_Bit_Rate/Ini-Min_Bit_Rate = 384k/64k setting.

Need big Traffic Volume but cannot shift directly to SF8

Call can go back to SF8 when

- Downgrade to SF32 takes place due to DyLO

-Inactive timer expires and moves to Cell-FACH


Example DyLO scheme 1: PtxDLabsMax 50 dBm, PtxTotalMax 43dBmD

L pw

r (d

Bm)

PtxTotalMax 43dBm

PtxPrimaryCPICH 33dBm

PtxPrimaryCPICH – CPICHtoRefRABoffset = 31 dBm

PtxDLabsMax 50 dBm

Calculated max RL pwr Calculated max RL pwr - DLOptimisationPwrOffset

• This is where DyLO triggers. (If PtxDLabsMax is set high)

Default hidden value is 2dB

reftxP ,

max,txP

Ptx, threshold


Example DyLO scheme 2: PtxDLabsMax 38 dBm, PtxTotalMax 43dBmD

L pw

r (d

Bm)

PtxTotalMax 43dBm

PtxPrimaryCPICH 33dBm

PtxPrimaryCPICH – CPICHtoRefRABoffset = 31 dBm

PtxDLabsMax 38 dBm

Calculated max RL pwr

PtxDLabsMax - DLOptimisationPwrOffset = 36 dBm

• PtxDLabsMax is reduced from 50dBm to 38dBm•This is where DyLO now triggers.

max,txP

reftxP ,

Ptx, threshold


Chapter 5-Packet Scheduling-

1. Which channel types the PS selects based on traffic load and parameters?

2. Name the scenarios for the WCDMA packet access.

3. What are the adventages of the URA_PCH state?

4. What task does the cell specific part of the PS perform?

5. If RT RAB’s require temporarily the target transmission power of the node B, what will happen to the NRT RAB’s on the same node B at that time?

6. How the traffic volume measurements are sent to the UE?

7. What parameter will affect to the DyLo Operation ?

Documents

06_PacketScheduling_2004