PS PDF

Course Content
Radio Resource Management Overview

Parameter Configuration
Common Channels & Power Control
Load Control
Admission Control
Packet Scheduling
Handover Control
Resource Manager
1 NOKIA 31/10/2003 RANPAR Version 1.0

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?
Suitable for controllable load (=best effort NRT)
Requires fast resource allocation
Planned
Load Load/Power
(~ Power) Target
Free Capacity
Non-Controllable Load
real time traffic
interference from other cell users
noise
time
Why Packet Scheduling?
It is characteristic for RT traffic that its 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
overload
Power PtxTargetBTS PrxTargetBTS
/ Load
PtxOffset PrxOffset
PtxTarget PrxTarget
PtxTotal (variable) PrxTotal

PtxNrt PrxNrt
Desired
Prx/Ptx
Values
PtxRt PrxRt
controllable load
i.e. non RT Traffic
non-controllable load
i.e. RT Traffic

time
Supported Radio Bearers in RAN
RAN1.5.1
RAN1.5.1 RAN1.5.2ED2
RAN1.5.2ED2 RAN04
RAN04 RAN05
RAN05 RAN06
RAN06
AMR
AMR 12.2
12.2
Transparent
Transparent CS
CS data
data 64
64
Non-
Non
Non--transparent
Non- transparent CS data 57.6
CS data 57.6
NRT
NRT PS
PS data
data UL:64,
UL:64, DL(64,128,384)
DL(64,128,384)
Non-
Non--transparent
Non
Non- transparent CS
CS data
data 14.4
14.4
AMR
AMR 10.2,
10.2, 7.95,
7.95, 7.40,
7.40, 6.70,
6.70, 5.90.
5.90. 5.15,
5.15, 4.75
4.75
Transparent
Transparent CS
CS data
data 33.6,
33.6, 32,
32, 28.8
28.8
NRT
NRT PS
PS data
data 8,
8, 16,
16, 32
32
AMR = Conversational CS speech
Streaming
Streaming PS
PS data
data UL/DL(8,
UL/DL(8, 16,
16, 32,
32, 64,
64, 128),
128), DL:256
DL:256
Transparent CS data = Conversational CS data
Non-transparent CS data = Streaming CS data NRT
NRT PS
PS data
data 256
256
NRT PS data = Interactive/Background PS data
Conversational
Conversational PS PS
Implementation of Nokia RAN shall support QoS
QoS is
is aa study
study item
item
asymmetric combinations with all bit rates. The in
combinations supported by terminals are verified in
in RAN06
RAN06
system verification and inter-operability testing
between Nokia RAN and Nokia & third party
terminals.

Packet Scheduling
Overview
Bitrate Allocation
Bitrate Upgrade
Overload Control

RRC Modes with Parameters
UTRA RRC Connected Mode
Available in Available in
RAN04
the future RAN1.5.2ED2
URA_PCH CELL_PCH
DRX DRX
#cellUpdates cellUpdate, UL Tx
UL Tx
UL_DL_activation_timer
CELL_DCH CELL_FACH
Tx/Rx Tx/Rx FACH/RACH
inactivityTimer trafficVolume
Release RRC Release RRC UL_DL_activation_timer

Connection Connection (workaround)
(workaround, in RAN1.5.2 ED)
Establish RRC
Connection
(UE camps on UTRAN cell)
Idle Mode
RRC Modes and Packet Scheduling
The 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 packets
Packet 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 Establishment
In 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 RNCs RRC signalling entity performs a radio bearer setup with a RRC:Radio Bearer Setup
procedure.
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 RNCs RRC signalling entity starts a supervision timers RB_InactivityTimer and
SignallingLinkInactivityTimer
If the capacity request is received from the UE or from the RNCs 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
CELL_
DCH UE RNC SGSN
RRC Connection Establishment (SRB)
MM & CC (e.g. PDP Context Activation)
Traffic Volume RAB Assignment Request

Parameters
determination
Start
Measurement Control [Traffic Volume Measurements] RB_InactivityTimer
RB_InactivityTimer
expiry
yes
no
SignallingLinkInactivityTime
Capacity Request? expiry
yes
DCH for NRT RB(s) allocation CELL_
13 NOKIA 31/10/2003 RANPAR Version 1.0 FACH
Transition from CELL_DCH to CELL_FACH
The 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)

After the inactivity timer expires the RRC radio bearer reconfigurationprocedure 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).

CELL_
DCH UE Node B RNC
PDU Transport on the DCH/DPCH

All data is sent and
RLC-U buffer is empty
Inactivity detected Start
InactivityTimerUplinkDCH
InactivityTimerDownlinkDCH
Radio Bearer Reconfiguration Expiry
CELL_
FACH Radio Bearer Reconfiguration Complete
L2 configuration
Radio Bearer Release

Start
MAC: Inactivity detected
UL/DL activation timer

Transition from CELL_FACH to CELL_PCH
CELL_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 RNCs 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)

RRC State Transitions
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 RNCs 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.

Transition from CELL_FACH to ...
CELL_
FACH UE RNC
Start
MAC: Inactivity detected
CELL_ Expiry
PCH Radio Bearer Reconfiguration
CELL_ Inactivity detected Start

FACH Cell Update
MaxCellReselections
URA_ CellReselectionObservingTime
PCH Cell Update and
MaxPeriodicalCellUpdates
Cell Update Confirm
Expiry
analog in
URA_ CELL_PCH
PCH Transition to URA_PCH
URA Update
MSActivitySupervision
RRC- URA Update
IDLE URA Update Confirm
Transition from CELL_FACH to CELL_DCH
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.

UE initiated
CELL_
FACH UE Node B RNC
Measurement Report (Traffic Volume Event)
UL & DL packet scheduling
Radio Link Setup
Radio Bearer Reconfiguration

CELL_
DCH Radio Bearer Reconfiguration Complete

RNC initiated
CELL_
FACH UE Node B RNC
DL capacity need is
detected by MAC
Channel type selection
-> DCH
UL & DL
packet scheduling
Radio Link Setup
Radio Bearer Reconfiguration

CELL_ Radio Bearer Reconfiguration Complete
DCH

Nokia Parameters
RB_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
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 Parameters
InactivityTimerUplinkDCH
The time indicating how long the radio and transmission resources are reserved after silence
detection on uplink DCH before release procedures
range: 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 procedures
range: 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 Parameters
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 10s
range: 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 Iu
default value: 30 min;
range: 0 ... 1440 min; step 1 min

Nokia Parameters
CellReselectionObservingTime
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 changed
range: 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 state
default value: 1 time; range: 0 ... 10 times; step 1 times

URA reselection Cell reselection
Periodic URA update
(stationary MS) Summary (moving UE)
Periodic cell update
Periodic URA update (stationary UE)
(stationary MS) Paging response (DL
Paging response (DL data/ signalling)
data / signalling) Activity supervision UL Access (UL
UL Access (UL data / Completion of Cell data/signalling)
signalling) URA_ Update procedure Cell_
PCH PCH
Inactivity detection
of NRT RB Completion of URA Update
Release of RT RB
procedure
Max. number of periodic cell
updates in Cell_FACH /
Cell_ Cell_ Cell_PCH exceeded
DCH FACH
Setup of RT/NRT RB
RAB reconfiguration
DCH Up or Downgrade
Bit rate reduction due to
RRC Connection
load reasons
Release
Idle
Mode UL/DL data
CN originated paging (MT Call) or signalling
Random Access (MO Call) RT RB setup
RRC State Transition
Exercise: Add parameters to all transitions!!!!
URA_ Cell_
PCH PCH
Cell_ Cell_
DCH FACH
Idle
Mode

Packet Scheduling
Overview
Bitrate Allocation
Bitrate Upgrade
Overload Control

Power Budget for Packet Scheduling
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).
Prx _ total = Prx _ nc + Prx _ nrt

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).
Ptx _ total = Ptx _ nc + Ptx _ nrt
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

Example: UL
Bit Rate Allocation - Overview
Bit rate allocation algorithm
Prx _ allowed = Prx _ t arget Prx _ total
Calculate PrxAllowed
Prx _ nrt _ inactive Prx _ rt _ inactive
YES PrxTotal < PrxTarget NO

estimated received estimated received
power of admitted power of RT admitted
RT bearers still in but currently inactive PrxTotal <
the in the bearers YES PrxTarget + PrxOffset
establishment phase
NO
Prx _ total = Prx _ nc + Prx _ nrt Increase loading Decrease loading
Allocate bit rates

non-controllable power
controllable power end

Bit Rate Allocation - Overview
In first phase PrxAllowed and PtxAllowed must be calculated by using:
Prx _ allowed = Prx _ t arg et Prx _ total Prx _ nrt _ inactive Prx _ rt _ inactive
Ptx _ allowed = Ptx _ t arg et Ptx _ total Ptx _ nrt _ inactive Ptx _ rt _ inactive
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

Packet Scheduling Principles
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 and Load Control
Packet Scheduler
decision frequency:
SchedulingPeriod
Node B
time RNC
Radio Resource Indication
n = PSAveragingWindowSize
Averaged PrxTotal:
RRIndPeriod Prx _ total (t ) + Prx _ total (t 1) + ... + Prx _ total (t (n 1))
Prx _ total =
n
Averaged PtxTotal: (analog to averaged PrxTotal)
Packet Scheduling and Load Control
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:
Prx _ total (t ) + Prx _ total (t 1) + ... + Prx _ total (t (n 1))

Prx _ total =
n
n = PSAveragingWindowSize
where Prx_total(t) is the latest received PrxTotal measurement and n equals to
PSAveragingWindowSize
PtxTotal is averaged same way

Parameters for Packet Scheduling
MinAllowedBitRateUL
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

SchedulingPeriod
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.
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
averaging
default value: 5;
range: 1 ... 20 , step 1
Individual Measurement Values 4 1 3 5 7 10 6

Averaging Window Size = 3 5.0 7.3 7.7

Packet Scheduling
Overview
Bitrate Allocation
Bitrate Upgrade
Overload Control

UL Traffic Volume Based RRC State Transition
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.
Reporting event:
4A: Transport Channel Traffic Volume becomes larger than an absolute threshold
UE in CELL_DCH: TrafVolThresholdULHigh (1024 Bytes)
Transport Channel
Traffic Volume
UE in CELL_FACH: TrafVolThresholdULLow (128 Bytes)
(= UE Ruffer Load)
4A 4A 4A
Measurement
report has
information about Thresholds
current
UE buffer load
time
UE
Measurement Report (Traffic Volume Event) RNC
TrafVolPendingTimeUL (2s)
Measurement Report (Traffic Volume Event)
DL Traffic Volume Based RRC State Transition
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.

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
(transport channel traffic volume)

RLC buffer payload
UL data transmission
on DCH in CELL_DCH
state
4A
TrafVolThresholdULLow (Cell parameter)
UL data transmission
on RACH in Traffic volume measurement
CELL_FACH state not triggered

Downlink traffic volume measurements
Traffic volume measurement
(transport channel traffic volume)

triggered, request for high bit rate
TrafVolThresholdDLHigh (RNC parameter)
RLC buffer payload

DL data transmission
on DCH in CELL_DCH
state Traffic volume measurement
triggered, request for low bit rate
TrafVolThresholdDLLow (Cell parameter)

DL data transmission
on FACH in Traffic volume measurement
CELL_FACH state not triggered

Possible cases for packet scheduling function
Data transmission on common channels in CELL_FACH state
Preconditions Postconditions
Channel
Case Channel allocation Trigger
UE state UE state allocation
UL DL UL DL
Data arrives to UE RLC buffer
1 Cell_FACH - - data_amount < TrafVolThresholdULLow Cell_FACH RACH FACH
(ul capacity request not triggered)
Data arrives to RNC RLC buffer
2 Cell_FACH - - data_amount < TrafVolThresholdDLLow Cell_FACH RACH FACH
(dl capacity request not triggered)

Channel switching from CELL_FACH to CELL_DCH state
Channel
UL DL UL DL
TrafVolThresholdULLow DCH DCH
3 Cell_FACH - - Cell_DCH
< data_amount < TrafVolThresholdULHigh low low
(ul capacity request triggered )
TrafVolThresholdDLLow DCH DCH
4 Cell_FACH - - Cell_DCH
< data_amount < TrafVolThresholdDLHigh low low
(dl capacity request triggered)
DCH DCH
5 Cell_FACH - - data_amount > Tr afVolThresholdULHigh Cell_DCH
high low
(ul capacity request triggered)
DCH DCH
6 Cell_FACH - - data_amount > TrafVolThresholdDLHigh Cell_DCH
low high
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).
DCH setup in CELL_DCH state
Channel
UL DL UL DL
DCH DCH
7 Cell_DCH - - data_amount < TrafVolThresholdULHigh Cell_DCH
low low
DCH DCH
8 Cell_DCH - - data_amount < TrafVolThresholdDLHigh Cell_DCH
low low
DCH DCH
9 Cell_DCH - - data_amount > TrafVolThresholdULHigh Cell_DCH
high low
DCH DCH
10 Cell_DCH - - data_amount > TrafVolThresholdDLHigh Cell_DCH
low high

DCH reconfiguration (bit rate upgrade) in CELL_DCH state
Channel
UL DL UL DL
DCH DCH DCH DCH
11 Cell_DCH data_amount > TrafVolThresholdULHigh Cell_DCH
low low high low
DCH DCH DCH DCH
12 Cell_DCH data_amount > TrafVolThresholdDLHigh Cell_DCH
low low low high
DCH DCH DCH DCH
13 Cell_DCH data_amount > TrafVolThresholdULHigh Cell_DCH
low high high high
DCH DCH DCH DCH
14 Cell_DCH data_amount > TrafVolThresholdDLHigh Cell_DCH
high low high high

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

Packet Scheduling
Overview
Bitrate Allocation
Bitrate Upgrade
Overload Control

Channel type selection
Channel Type Selection Yes
(A)
The channel selection procedure the No
following parameters are needed: Yes
(B)
Downlink traffic volume measurement
low threshold (TrafVolThresholdDLLow) No
Maximum allowed total data amount Yes
(C)
on FACH (FachDataAllowedTotal)
No
Threshold for RACH load Yes
(RachLoadThresholdCCH) (D)
Margin for RACH load No

(RachLoadMarginCCH)
Initial transmission
Threshold for FACH load on FACH Request DCH from PS
(FachLoadThresholdCCH)
Margin for FACH load end
(FachLoadMarginCCH)
Threshold for total downlink (A) Maximum allowed user data
transmission power (PtxThresholdCCH) amount on FACH exceeded
Margin for total downlink (B) Maximum allowed total data
transmission power (PtxMarginCCH) amount on FACH exceeded
(C) FACH in overload
55 NOKIA 31/10/2003 RANPAR Version 1.0 (D) FACH usage forbidden by PS
DL Traffic Type Selection
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 PtxTotal
exceeds 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
FACH overload
FachLoadThresholdCCH/
Load RachLoadThresholdCCH
FACH in
overload FachLoadMarginCCH/
RachLoadMarginCCH
time
FACH
usage ok
FACH forbidden
PtxThresholdCCH
Power
/ Load
FACH in PtxMarginCCH
overload
time
FACH
57 NOKIA 31/10/2003 RANPAR Version 1.0 usage ok
FACH/RACH Load Related Parameters
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).
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)

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

Packet Scheduling
Overview
Bitrate Allocation
Bitrate Upgrade
Overload Control

Processing of Capacity Request
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

New capacity request
CrQueuingTimeUL
CrQueuingTimeDL
No
(A) Capacity (A) Start scheduling process
request from
UE already in Yes
a queue?
(B) Is new Yes
(B) Delete the request
capacity
request same
as original? No
based on CrHandlingPolicyUL
new capacity request CrHandlingPolicyDL
for a change in data Arrival time
rate? Bearer class
Traffic handling priority
Modify the content type of the original capacity request in a queue
Delete the new

capacity request
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;
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.
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: 2
range: 1 (arrival time only), 2 (arrival time and bearer class), 3 (arrival time,
bearer class and traffic handling priority)

Packet Scheduling
Overview
Bitrate Allocation
Bitrate Upgrade
Overload Control

Initial bitrate allocation & 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 CRs
they are first accepted in priority order. For each CR PrxTotalNew and PtxTotalNew, are
calculated:
Prx _ total _ new = Prx _ total + Prx _ total _ change
Ptx _ total _ new = Ptx _ total + Ptx _ total _ change
where: P_totalchange is the power change estimation.

For each CR PrxNrtNew and PtxNrtNew are calculated based on the new or bitrate
increase (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

Bitrate Upgrade Process
Increase loading
Example: DL
Bit rate = Start from
Any CRs in queue MinAllowedBitRate CR #1
Move to Estimate PrxTotalNew and

Next CR in PrxNrtNew
Queue
Yes
more CRs Yes (A)
Move to in queue
Next higher No
bitrate No
Higher
Yes Allowed Bitrates No End
(A) PtxTotalNew < PtxTarget AND

Ptx _ total _ new = Ptx _ total + Ptx _ total _ change PtxTotalChange < DeltaPtxMaxUp
PtxNrtNew < PtxAllowed
Bit Rate upgrade process
In the next phase the calculated PrxTotalNew, PtxTotalNew, PrxTotalChange, PtxTotalChange,
PrxNrtNew and PtxNrtNew are compared against thresholds and bitrates are increased (or
bitrate 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 allowed
bitrate 128kbps assumed) see next slide:

Bit Rate Allocation Increase Load
No higher bit rate Target exceeded,
case 1: 1 CR in queue available, allocation case 4: 4 CRs in queue allocation according
PrxTarget according to step 3 to step 4
PrxTarget
128 (4)
384 (1) 128 (4) 128 (3)
128 (1) 256 (1) 128 (3) 128 (3) 128 (2)
Step 1 Step 2 Step 3 128 (2) 128 (2) 128 (2)
256 (1)
128 (1) 128 (1) 128 (1) 128 (1)
Step 1 Step 2 Step 3 Step 4 Step 5
Target exceeded,
case 2: 2 CRs in queue

allocation according
to step 4 case 5: 5 CRs in queue
PrxTarget
256 (2)
128 (2) 256 (2) PrxTarget 128 (5)
128 (2) 384 (1)
256 (1) 256 (1) 128 (4) 128 (4)
128 (1) 128 (1) 128 (3) 128 (3) 128 (3)
Step 1 Step 2 Step 3 Step 4 Step 5 128 (2) 128 (2) 128 (2) 128 (2)
Target exceeded, 128 (1) 128 (1) 128 (1) 128 (1) 128 (1)
case 3: 3 CRs in queue allocation according
to step 4
Target exceeded,
PrxTarget
128 (3) allocation according
128 (3)
256 (2)
to step 4, no
128 (3) 128 (2) allocation to CR #5
128 (2) 128 (2)
256 (1) 256 (1)
128 (1) 128 (1) 128 (1)
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.

Packet Scheduling
Overview
Bitrate Allocation
Bitrate Upgrade
Overload Control

Overload Control (TFCC)
Decrease loading
Example: UL
Select randomly one of the No Switch bearer
Lower bit rates
highest bit rate bearers allowed to CCH
Yes
TFCC means Transport Reduce to next
Format Combination lower bit rate
Control Procedure, no
DCH Downgrade but Estimate PrxTotalNew and
suspend of higher PrxNrtNew
transport formats
Yes
No Yes
End More bearers (A)
No
(A) PrxTotalNew > PrxTarget AND

PrxTotalChange < DeltaPrxMaxDown
Overload Control (TFCC)
AC produces the TrCH parameters:
Transport Formats (TF)
Transport Format Combination (TFC)
TFC identifiers
TFCC
here
384 384 TrCh 1 TrCh 2
128 TFI2
128 128
64 TFI1 64 TFI1
64
0 TFI0 0 TFI0 64 TFI1
0
TFI0 0 TFI0
00
Supported Peak Bitrate Sheduled TFS for RT RB TFS subset TFCS (SL & RT RB)
Bitrates In Bearer Bitrate intermediate For TFCS
Parameters Bitrates construction

Overload Control
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 below
MinAllowedBitRateUL or MinAllowedBitRateDL)
2. DCH Bit rates of the Interactive class bearers are decreased in random order (not below
MinAllowedBitRateUL or MinAllowedBitRateDL)
3. Background class bearers are switched from DCH to CCH in random order
4. Interactive class bearers are switched from DCH to CCH in random order

Example: DL Dedicated Channel Modification
Uu Iub
UE BTS RNC-NBAP RNC-RRC RNC-L2 RNC-RRM
UE in CELL_DCH state
RLC-PDU transportation on DCH
BTS provides
periodical cell load
information to RRM
NBAP: RADIO RESOURCE INDICATION

RR_ind
RRM detects overload

situation in uplink
packet scheduling
PS indicates UE about
the modified capacity
and selected UL TFC
subset
Capacity_modify
[DCH] RRC: TRANSPORT FORMAT COMBINATION CONTROL
RLC-PDU transportation on modified DCH

Overload Control
In the next phase it is checked whether the selected bearer is already having the lowest possible
bitrate (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
256 PrxTarget
256
256
384
256 Step 1: 384 -> 256 (TFCC)
256
Step 2: 384 -> 256 (TFCC)
384 384
256 Allocation according to step 3
Step 1 Step 2 Step 3
In case of 6 bearers
128
128 128
PrxTarget
128 128 128
128 128 128 128 Step 1: 256 -> 128 (TFCC)
256
128 128 128 Step 2: 256 -> 128(TFCC)
128 128 128
128 128 Step 3: 128 -> CCH (Radio Bearer Reconfiguration)
256 256
128 128 Allocation according to step 4
Step 1 Step 2 Step 3 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

Bit Rate Allocation
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.
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.

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

Packet Scheduling
Overview
Bitrate Allocation
Bitrate Upgrade
Overload Control

Dynamic Link Optimisation
(DLO) for NRT Traffic Coverage
Improved NRT traffic coverage
128kbps
384kbps
UE
BTS
distance
Radio link is modified to use lower
bit rate when WBTS Tx power is
getting close to maximum
Triggering of Dynamic Link Optimisation
Ptx, ave is averaged radio

link power, measured and
reported to RNC by BTS
distance
Ptx, RL Ptx, max is determined by
Ptx, max admission control
Offset The value of the Offset is
fixed, 2 dB
Dynamic link optimisation
Triggering of DyLO is triggered if
Ptx, ave Ptx, ave > Ptx, max - Offset
time

Decision algorithm
Measurement
Report
Ptx,ave
(Ptx,ave + Offset) >

No
Ptx,max
Triggering of DyLO
Yes
DyLO is not possible during compressed mode
Compressed Mode
Yes
active
No
DyLO is possible for NRT DCH allocations that have
lasted at least 2 seconds (fixed guard time)
Yes Guard timer active
Not applicable in RAN1.5 (only 1 NRT DCH possible
No per UE)
Select DCH(s) to be
downgraded
SF is doubled (physical channel bit rate reduced
to half of the original)
Requirements OK Additional puncturing is not allowed
(min allowed bitrate, No DyLO cannot reduce bit rate below the Initial and
minimum allowed bit rate in downlink
SF, puncturing)
Yes (RAN1.5.2ED CD19)

Reduce DCH bitrate(s)
Reconfiguration not DyLO can be started only if the current bit rate is
possible
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 Fixed, 2 dB
DyLO is possible if Ptx, init < (Ptx, max Offset)
If inequality is not valid, the next lower bit rate is tried

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

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
With Max_Bit_Rate/Ini-Min_Bit_Rate = 384k/64k setting.
SF32(64k) SF8(384k) SF16(128k) SF8(384k)
Need big Traffic Volume but

cannot shift directly to SF8
CELL-FACH SF32(64k) SF8(384k)

SF32(64k) SF8(384k) SF16(128k)
SF32(64k) SF8(384k)
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 43dBm
PtxDLabsMax 50 dBm
PtxTotalMax 43dBm
Ptx,max
Calculated max RL pwr
Calculated max RL pwr - DLOptimisationPwrOffset
Ptx, threshold
DL pwr (dBm)
Default hidden
value is 2dB
PtxPrimaryCPICH 33dBm
Ptx ,ref
PtxPrimaryCPICH CPICHtoRefRABoffset = 31 dBm
This is where DyLO triggers. (If PtxDLabsMax is set high)

Example DyLO scheme 2: PtxDLabsMax 38 dBm, PtxTotalMax 43dBm
PtxTotalMax 43dBm
Ptx,max
Calculated max RL pwr
PtxDLabsMax 38 dBm
DL pwr (dBm)
PtxDLabsMax - DLOptimisationPwrOffset = 36 dBm

Ptx, threshold
PtxPrimaryCPICH 33dBm
Ptx ,ref
PtxPrimaryCPICH CPICHtoRefRABoffset = 31 dBm
PtxDLabsMax is reduced from 50dBm to 38dBm

This is where DyLO now triggers.

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 RABs require temporarily the target transmission power of the node B, what will happen
to the NRT RABs 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 ?

PS PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PS PDF

Uploaded by

Copyright:

Available Formats

Course Content

Radio Resource Management Overview

1 NOKIA 31/10/2003 RANPAR Version 1.0

2 NOKIA 31/10/2003 RANPAR Version 1.0

3 NOKIA 31/10/2003 RANPAR Version 1.0

6 NOKIA 31/10/2003 RANPAR Version 1.0

PtxTotal (variable) PrxTotal

7 NOKIA 31/10/2003 RANPAR Version 1.0

8 NOKIA 31/10/2003 RANPAR Version 1.0

9 NOKIA 31/10/2003 RANPAR Version 1.0

Release RRC Release RRC UL_DL_activation_timer

(UE camps on UTRAN cell)

There are three scenarios for WCDMA packet access:

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

Traffic Volume RAB Assignment Request

14 NOKIA 31/10/2003 RANPAR Version 1.0

15 NOKIA 31/10/2003 RANPAR Version 1.0

PDU Transport on the DCH/DPCH

Radio Bearer Release

UL/DL activation timer

17 NOKIA 31/10/2003 RANPAR Version 1.0

18 NOKIA 31/10/2003 RANPAR Version 1.0

CELL_ Inactivity detected Start

20 NOKIA 31/10/2003 RANPAR Version 1.0

Radio Link Setup

Radio Bearer Reconfiguration

21 NOKIA 31/10/2003 RANPAR Version 1.0

Radio Link Setup

Radio Bearer Reconfiguration

22 NOKIA 31/10/2003 RANPAR Version 1.0

23 NOKIA 31/10/2003 RANPAR Version 1.0

24 NOKIA 31/10/2003 RANPAR Version 1.0

25 NOKIA 31/10/2003 RANPAR Version 1.0

26 NOKIA 31/10/2003 RANPAR Version 1.0

28 NOKIA 31/10/2003 RANPAR Version 1.0

29 NOKIA 31/10/2003 RANPAR Version 1.0

Prx _ total = Prx _ nc + Prx _ nrt

30 NOKIA 31/10/2003 RANPAR Version 1.0

YES PrxTotal < PrxTarget NO

Prx _ total = Prx _ nc + Prx _ nrt Increase loading Decrease loading

Allocate bit rates

31 NOKIA 31/10/2003 RANPAR Version 1.0

32 NOKIA 31/10/2003 RANPAR Version 1.0

33 NOKIA 31/10/2003 RANPAR Version 1.0

Prx _ total (t ) + Prx _ total (t 1) + ... + Prx _ total (t (n 1))

35 NOKIA 31/10/2003 RANPAR Version 1.0

In RAN1.5.2 MinAllowerBitrateUL is always 64 kbits/s and MinallowedbitrateDL can be

36 NOKIA 31/10/2003 RANPAR Version 1.0

Individual Measurement Values 4 1 3 5 7 10 6

38 NOKIA 31/10/2003 RANPAR Version 1.0

39 NOKIA 31/10/2003 RANPAR Version 1.0

42 NOKIA 31/10/2003 RANPAR Version 1.0

3. Upgrade request for high bit rate (DL); when

43 NOKIA 31/10/2003 RANPAR Version 1.0

(transport channel traffic volume)

44 NOKIA 31/10/2003 RANPAR Version 1.0

Traffic volume measurement

(transport channel traffic volume)

RLC buffer payload

TrafVolThresholdDLLow (Cell parameter)

45 NOKIA 31/10/2003 RANPAR Version 1.0

46 NOKIA 31/10/2003 RANPAR Version 1.0

DCH low bitrate is defined as parameter of MinAllowedBitRateUL or