HSPA and EUL Scheduler

HSDPA QoS Scheduler feature introduces capability to

support different services on HSDPA fulfilling the
QoS mapping different QoS for each service

CN
RAB attributes
RAB Assignment Request
Flexible QoS and Allocation/Retention handling
TC, ARP SSD, SI
optional feature map any combination of
RANAP QoS attributes to SPI TD, GBR MBR, THP
RNC Internal ARP

Capacity Mgmt QoS mapping

HS-DSCH Scheduling Priority Indicator (SPI)

required SPI, GBR
E-DCH MBR
power Discard timer

RBS
HS EUL
Scheduler Scheduler
Scheduling Priority Indicator
Iu Attribute
Iu RAB parameters Mapping
Traffic
Traffic Class Handling Signalling UL DL
(tcInd) Priority (thp) Indication SPI SPI
Interactive 1 Yes 5 (3) 7 (3)
Interactive 1 No 4 (3) 4 (3)
Interactive 2 No 3 (3) 3 (3)
Default mapping
Interactive 3 No 2 (3) 2 (3)
Background N/A N/A 1 (3) 1 (3)

Iu Attribute
Iu RAB parameters Mapping
Source
Statistics
Traffic Class Descriptor UL DL
(tcInd) (ssd) SPI SPI
Conversational Unknown 7 6
Streaming Unknown 6 5

UL SPI, THP,SI
DL SPI SSD

RAB Assignment
Request message
RNC CN
 HSDPA Scheduler - considerations
How scheduler operates???
Two kinds of QoS variations are expected in an HSPA connection
- rapid (short term) variations: due to fading
- long-term variations: due to distance between RBS and UE.

PS data implication:
- relatively large short-term variations in service quality are acceptable (they
could be canceled by HARQ retransmissions),
- long-term variations must be limited
 HSDPA Scheduler - considerations
How scheduler operates???

Problem on strategy:
-system throughput should be maximized Prefer scheduling users
experiencing best downlink quality at all times.
- Fairness is not retained users experiencing worse downlink quality (cell
edge users or indoor users) will starve for resources

Solution: HSDPA scheduler should combine both by taking both system

throughput and fairness into account.

utilizes short-term variations and maintains some degree of long-term

fairness between the users.
 HSDPA Scheduler - considerations
Optional Feature: HSDPA QoS Scheduler
HSDPA Scheduler provides support for Quality of Service (QoS)
differentiation different handling of Guaranteed Bit Rate (GBR) services
and non-GBR services in the HSDPA Scheduler.

Optional Feature: Traffic Handling Priority (THP)

QoS differentiation between different Interactive services is also supported
used to determine the scheduling priority class of a service.
 These five procedures are
HSDPA Scheduler repeated every TTI,

R99 trafic. ->
R99 power ->
Resources Estimation 1
Codes/HW -> Available users
Selects users to transmit to in
CQI report. -> Queue Validation 2 the next TTI, based in radio
UE type -> quality, UE capability etc

It decides how to allocate

Resource Sharing 3
the available resource
between different
CQI report. -> UE to transmit Scheduling Priority Classes
Delay ->
Hyst. Rate -> Queue Selection 4 (SPI).

Priority queues are selected

TF Selection 5a Data to transmit considering other inputs, such
Power &
Codes left
as average rate and downlink
radio quality.
Remaining
Resources? NO?
YES? 5b
Layer 1
Scheduler Resource Estimation
HSDPA Code Control
numHsPdschCodes
Enable for operator to configure fixed number of HS-PDSCH codes
for a cell can not be used by DCH !!!!!

numHsScchCodes
Enable for operator to configure number of HS-SCCH codes for a
cell (if Code Multiplexing is activated)
HSDPA Code Control
optional feature Dynamic Code Allocation possible to borrow
codes from the DCH domain when those codes are not used for
DCH traffic.
dynamicHsPdschCodeAdditionOn
Optional Feature Dynamic Code Allocation Possibility to
dynamically adapt the HS-PDSCH code allocation depending on
code availability in the cell and the RBS

maxNumHsPdschCodes
Allocate maximum number of HS-PDSCH codes in a cell
maxNumHsPdschCodes = fixed # codes numHsPdschCodes + the
dynamic codes borrowed from the DCH domain.
RNC Code Control Algorithm
Allocation of HS-PDSCH codes
from the right of the code tree (C16,15 first)
HS-PDSCH codes allocated adjacent to each other.
Allocation of DCH codes
prioritize allocations with lowest index to avoid codes adjacent to
HS-PDSCH codes
Allocation of HS-SCCH codes
allocated in position with the lowest available code index
Example of Dynamic Code Allocation

HS-DSCH
DCH

Common
Channels DCH
DCH Load Min - HS-PDSCH
dependent Flexible numHsPdschCodes
increase
 Power available for the HS-PDSCHs
Power Estimation availability (HS-PDSCHs) is performed in steps:
Step 1. total power available for all the HSDPA channels and the
Enhanced Uplink downlink channels, PHS, is estimated as:

Where Pmax : maximum downlink transmission power for the cell signaled
from the RNC (maximumTransmissionPower), and
Pnon-HS : total transmitted carrier power of all codes of all dedicated and
common channels (channels not used for HS-PDSCH, HS-SCCH, E-
HICH, E-RGCH and E-AGCH transmission) measured by the RBS
every TTI
 Power available for the HS-PDSCHs
Power Estimation availability (HS-PDSCHs) is performed in steps:
Step 2. total power available for the HS-PDSCH, PPDSCH estimated:

Where PHsscchPower : code power used for the HS-SCCH and

PEUL is the code power used for the E-HICH, E-RGCH and E-AGCH.
Power available for the HS-PDSCHs

maximumTransmissionPower PMAX
hsPowerMargin
Total available cell power

HSDPA
PHS-required
HS-required

Pnon-HS
Dedicated channels (power controlled)

Common channels (not power controlled)

Queue Validation
 These five procedures are
HSDPA Scheduler repeated every TTI,

R99 trafic. ->
R99 power ->
Resources Estimation 1
Codes/HW -> Available users
Selects users to transmit to in
CQI report. -> Queue Validation 2 the next TTI, based in radio
UE type -> quality, UE capability etc

It decides how to allocate

Resource Sharing 3
the available resource
between different
CQI report. -> UE to transmit Scheduling Priority Classes
Delay ->
Hyst. Rate -> Queue Selection 4 (SPI).

Priority queues are selected

TF Selection 5a Data to transmit considering other inputs, such
Power &
Codes left
as average rate and downlink
radio quality.
Remaining
Resources? NO?
YES? 5b
Layer 1
 Queue Validation

checks all PQs and judges whether they are valid for scheduling during the
upcoming TTI:
1. user's associated dedicated channel is in sync in uplink,
2. user is capable of receiving data in the next TTI considering the UE's
minimum inter-TTI capability,
3. there is data in the PQ buffer to transmit,
4. valid adjusted CQI value exists for the user,
5. suitable HARQ process exists for retransmission or initial transmission
6. MAC-hs/MAC-ehs transmission window is not full
Scheduler Resource Sharing
 These five procedures are
HSDPA Scheduler repeated every TTI,

R99 trafic. ->
R99 power ->
Resources Estimation 1
Codes/HW -> Available users
Selects users to transmit to in
CQI report. -> Queue Validation 2 the next TTI, based in radio
UE type -> quality, UE capability etc

It decides how to allocate

Resource Sharing 3
the available resource
between different
CQI report. -> UE to transmit Scheduling Priority Classes
Delay ->
Hyst. Rate -> Queue Selection 4 (SPI).

Priority queues are selected

TF Selection 5a Data to transmit considering other inputs, such
Power &
Codes left
as average rate and downlink
radio quality.
Remaining
Resources? NO?
YES? 5b
Layer 1
HSDPA Resource Sharing number of SF16
codes per user

Two available solutions for resource sharing between different

scheduling priority classes SPI (flexible scheduler = TRUE):
absolute resource sharing provides absolute priority to
higher scheduling priority users they are scheduled before
lower scheduling priority users (decided by parameter
schPrioForAbsResSharing which can be set to any SPI
value) Lower scheduling priority user will only get what
remains of the resource, after the higher scheduling priority
users have taken what they need.
Advantage: possible to secure the required quality of service for high
scheduling priority users by providing absolute priority to them.
Drawback: is that low scheduling priority class users can be totally
starved.
HSDPA Resource Sharing

Two available solutions for resource sharing between different

scheduling priority classes (flexible scheduler = TRUE):
relative resource sharing: scheduling for users is
performed based on priority classes use a scheduling
weight factor defined by the operator configured parameter
schWeight for each scheduling priority class.
Advantage: it utilizes the available resource efficiently and fairly

Drawback: required QoS for high scheduling priority user are not always
fulfilled, even when resources are available.

Parameter schPrioForAbsResSharing (can be set to any SPI value) defines the

threshold below which relative resource sharing is performed.

Queue Selection algorithm is performed only for relative resource sharing queues
HSDPA Resource Sharing
SPI: 15 Absolute Resource Sharing
SPI: 14
Absolute priority to higher SPI values
SPI: ..
SPI: .. 0 to 15
SPI: 11 Default= 15
SPI: 10 (10 illustrated)
HSDPA
schPrioForAbsResSharing
SPI: 9
Relative Resource Sharing
SPI: 8 Using Queue Selection Algorithm:
CQI
True or False SPI: .. priority
Default= False maximum delay
(True illustrated) SPI: .. average rate
SPI: 1 Delay
air rate
SPI: 0
flexibleSchedulerOn + retransmission
Queue Selection Coefficient
Queue Selection
 These five procedures are
HSDPA Scheduler repeated every TTI,

R99 trafic. ->
R99 power ->
Resources Estimation 1
Codes/HW -> Available users
Selects users to transmit to in
CQI report. -> Queue Validation 2 the next TTI, based in radio
UE type -> quality, UE capability etc

It decides how to allocate

Resource Sharing 3
the available resource
between different
CQI report. -> UE to transmit Scheduling Priority Classes
Delay ->
Hyst. Rate -> Queue Selection 4 (SPI).

Priority queues are selected

TF Selection 5a Data to transmit considering other inputs, such
Power &
Codes left
as average rate and downlink
radio quality.
Remaining
Resources? NO?
YES? 5b
Layer 1
 HSDPA Queue Selection Algorithm
queue selection procedure selects among users (Priority Queues
(PQs)), have already passed the queue validation step, to allocate HS-
DSCH resources in each TTI

users with the highest priorities (queue selection coefficient) are

allocated the HS-DSCH resources in the TTI

Different seven priority factors are combined depending on the queue

selection algorithm (parameter queueSelectAlgorithm)
 HSDPA Queue Selection Algorithm
Priority Factors for Queue Selection Algorithm
CQI: indicates the downlink radio quality and the volume of data that
can be transmitted to the UE. used to prioritize users with good
channel conditions, which also leads to higher system throughput.
Priority: scheduling weight, schWeight, set for each scheduling
priority class. A large value on the schWeight gives high priority.
Maximum delay: QoS metric to allocate maximum allowed delay,
schMaxDelay, in the buffer for a scheduling priority class. Long
scheduling delay relative to schMaxDelay gives high priority.
Average rate: user's average achievable transmission data rate
(depending on downlink radio quality and UE capability). Priority
Queues with low offered bit rate gets high priority
 HSDPA Queue Selection Algorithm
Priority Factors for Queue Selection Algorithm
Delay: time a user has had to wait before being selected for
transmission by scheduler since the last transmission, considering only
PQs with data in the buffer used to control the fairness of the
resource allocation in time between users. Long delay gives high
priority.
Air rate: average data rate over the air interface. The lower data rate
the higher f(air rate) value (priority). The type of air interface data can
be acknowledged or transmitted, this is decided by the parameter
airRateTypeSelector.
Retransmission: prioritization of retransmissions over new
transmissions. The reason for considering this factor is that it is more
efficient to do a HARQ retransmission than an RLC retransmission.
 HSDPA Queue Selection Algorithm
CQI Function based on Channel Quality Indicator received from UE

priority Function based on configured schWeight for each SPI class

schWeight: 1 to 10000
default = 1,10,200,300,450,900,1000,4000,1,1,1,1,1,1,1,10000

maximum delay Function based on schMaxDelay,

schMaxDelay:-1 (undefined) to 300 (3000 ms)
Default: -1,-1,-1,-1,-1,100,10,-1,-1,-1,-1,-1,-1,-1,-1,-1

average rate Function based average achievable transmission data rate.

Delay Function based on waiting time since last transmission

air rate Function based on average data rate over air interface
airRateTypeSelector: Acknowledged or Transmitted (default)

+ retransmission A factor enabling prioritization of

retransmissions over new transmissions
Queue Selection Coefficient
 Queue selection
Possible to select between six different algorithms using the
parameter queueSelectAlgorithm

CQI priority max delay avg rate delay air rate retransm

Maximum CQI X X X

Proportional fair
X X X X
- low fairness

Proportional fair
X X X X
- med fairness

Proportional fair
X X X X
- high fairnes

Round Robin
X X X
- Time based

Equal rate X X X

Maximum delay X X X X

If flexible scheduler is disable (flexibleSchedulerOn = False) then only

Round Robin OR proportional fair medium fairness could be selected for
non-GBR traffic)
 Queue selection
Possible to select between six different algorithms using the
parameter queueSelectAlgorithm

CQI priority max delay avg rate delay air rate retransm

Maximum CQI X X X

Proportional fair
X X X X
- low fairness

Proportional fair
X X X X
- med fairness

Proportional fair
X X X X
- high fairnes

Round Robin
X X X
- Time based

Equal rate X X X

Maximum delay X X X X

not selectable by the operator and that it is used for all GBR flows
 HSDPA Queue Selection Algorithm
parameter queueSelectAlgorithm
proportional fair algorithm is an optional feature which considers a
subset of the priority factors [CQI, priority, average rate, retransmission]
target is to provide a trade-off between system throughput and user
fairness.
Benefit: different users experience different radio conditions at a
certain time prioritize users experiencing good channel quality
higher throughput can be achieved.
Optimizing: To avoid some users being allocated few rate some
fairness in resource allocation is provided by including the average rate
factors in the scheduling decision.
Low fairness scale up the factor CQI,
High fairness scale down the factor CQI.
Remaining Resource Check
 These five procedures are
HSDPA Scheduler repeated every TTI,

R99 trafic. ->
R99 power ->
Resources Estimation 1
Codes/HW -> Available users
Selects users to transmit to in
CQI report. -> Queue Validation 2 the next TTI, based in radio
UE type -> quality, UE capability etc

It decides how to allocate

Resource Sharing 3
the available resource
between different
CQI report. -> UE to transmit Scheduling Priority Classes
Delay ->
Hyst. Rate -> Queue Selection 4 (SPI).

Priority queues are selected

TF Selection 5a Data to transmit considering other inputs, such
Power &
Codes left
as average rate and downlink
radio quality.
Remaining
Resources? NO?
YES? 5b
Layer 1
 Remaining Resource Check
Check if additional users can be selected after the MAC-hs/MAC-ehs
TFRC selection is performed.
Queue selection procedure is performed per cell and repeated until one of
the following criteria is not fulfilled:
Available number of HS-SCCH codes 1
Available number of HS-PDSCH codes 1
The remaining power, PHS, is sufficient

Remember
The maximum number of simultaneous users during a TTI is limited by the
configured number of available HS-SCCH codes, numHsScchCodes.
 Minimum Bit Rate HSDPA Scheduling

Optional Feature: Minimum bit rate HSDPA Scheduling (FAJ 121 1439)
Provides the operator the possibility to offer a premium mobile broadband
data service, guaranteeing user normally will get at least a minimum bit
rate.
New RBS parameter minBitRate allows the operator to set a minimum bit
rate between 1 and 512 kbps for each of the HSDPA SPI classes.
Attention: Setting parameter value -1 for any SPI class deactivates the
feature no minimum bit rate is applied.

THP and the ARP maps to SPI which in turn is associated with minBitRate.
 HSPA SPI Mapping
SPI:14 Attributes used for mapping:
Traffic Class Indicator (tcInd)
Core Network Indicator (cnInd)
Source Statistics Descriptor (ssd)
SPI:13 Service Indicator (serviceInd)
Guaranteed bit rate (gbrRangeStart gbrRangeEnd)
Transfer Delay (tdRangeStart tdRangeEnd)
Traffic Handling Priority (thp)
SPI:12
HSPA Signalling Indicator (si)
Allocation/Retention Priority (ARP)
ManagedElement
+-RncFunction
+-RabHandling
+-RnlQosClassProfile
tcPsBgQosRef
SPI:0 tcPsBgArpSpiMapRef RANAP RAB
+-ArpSpiMap [0..53] Assignment Request CN
+-SpiQosClass [15..15]
+-TrafficClass [3..3]
+-TcMap [0..15]
+-TrafficClassPsInt [4..4]
 Minimum Bit Rate HSDPA Scheduling
minimum bit rate of 100 kbps has been set for SPI 3 and 124 kbps for SPI 4 only
SPI = 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
minBitRate = -1, -1, -1, 100, 128, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1
SPI:9 CQI: 6 FAJ 121 1439
SPI:1 CQI: 24 OPTIONAL

SPI:4 CQI: 5 100 kbps min bit rate

minBitRateMinCqi = 0 to 30, default = 8
SPI:3 CQI: 22

SPI:8 CQI: 5 128 kbps min bit rate

SPI:4 CQI: 24

SPI:3 CQI: 6 Queue Selection Coefficient:

f(CQI) * f(priority) * f(average rate) * f(minBitRate) * tRetrans.
 Minimum Bit Rate HSDPA Scheduling

Optional Feature: Minimum bit rate HSDPA Scheduling (FAJ 121 1439)

Algorithm:
1.HSDPA scheduling algorithm measures the user bit rate
2.Compare with configured minimum bit rate
3. If user bit rate < configured minimum bit rate add an extra scheduling
weight f(minBitRate) to the Queue Selection Coefficient calculation.
 HSDPA RBR QoS Profiling
Optional Feature: HSDPA RBR QoS Profiling used for Quality of
Service (QoS) differentiation of the throughput for HSDPA gold, silver and
bronze users over Transport Network (TN) bottleneck that limits the
HSDPA traffic.

Configuration operator parameter hsRbrWeight for each SPI and

HSDPA QoS Factors to differentiate when TN limits HSDPA traffic writes
these weights on the RBS MO IubDataStreams

hsRbrWeight defines relative bit rate among gold, silver and bronze users
independently of the number of users of each type

HSDPA QoS Factors for gold, silver and bronze users are configured over
five different traffic class positions, for example, 0, 4, 2, 1, 0 (THP1/
SI=yes, THP1/ SI=no, THP2, THP3, BG).
 HSDPA RBR QoS Profiling
In times of congestion HS users Configuration limiting or throttling in
are downgraded with different the Core Network is not required
factors depending on their QoS
7000000

Gold 6000000 Gold

HSDPA 5000000
x Silver
Bronze HSSR3_pqidx0
Silver 4000000
HSSR3_pqidx1
HSSR3_pqidx2
3000000
HSSR4_pqidx0

Bronze 2000000
RNC CN
1000000

0
Time
08:38:03.080
08:38:33.280
08:38:46.628
08:38:58.880
08:39:12.080
08:39:24.280
08:39:38.280
08:39:54.580
08:40:07.480
08:40:20.380
08:40:33.080
08:40:45.380
08:40:58.380
08:41:11.280
08:41:28.480
08:41:45.280
08:41:58.580
08:42:17.128
08:42:34.428
08:42:46.580
08:43:02.380
08:43:20.728
08:43:33.328
08:43:46.080
08:43:58.980
HSDPA RBR QoS Profiling + HSDPA Flow Control
or
HSDPA RBR QoS Profiling + AQM based Congestion Control for HSDPA
(IP Transport Networks)
RBR Weights
default
ManagedElement
+-NodeBFunction Gold hsRbrWeight = 200%
+-Iub Twice bandwidth
+-IubDataStreams
hsRbrWeight
Default setting:
SPI0: 100
SPI1: 100 hsRbrWeight = 100%
SPI2: 50 One bandwidth unit
SPI3: 100
SPI4: 200
SPI5: 100

SPI15: 100 hsRbrWeight = 50%

Bronze
Half bandwidth
QoS factor spread 10:1
 FAJ 121 1664

AQM based Congestion Control for HSDPA

Optional Feature: AQM based Congestion Control for HSDPA (FAJ 121
1664) : introduces Active Queue Management based transport network
congestion control.
Attention1: This feature works only with IP Transport networks
Attention2: may be used in conjunction with the HSDPA RBR QoS
Profiling optional feature
Alternative to other Optional Feature: HSDPA Flow Control working with
ATM network
Algorithm: utilizes the technique of a controlled TCP packet discard to
enable the TCP server to reduce the data rate per TCP flow when
Transport Network or Air Interface congestion is detected
 FAJ 121 1664

AQM based Congestion Control for HSDPA

Controlled TCP packet discard

Application
Multiple technology (2G, 3G and LTE) Server
HSDPA
interactive and background traffic share
the same queue in a shared IP
Transport Network

3G 3G
Higher peak rates for
LTE LTE
Smartphone users 2G 2G
=> 1MB file
download time stable buffer levels => better radio resource
reduced by 20 90% utilization by minimizing empty buffer problems
 AQM based Congestion Control for
HSDPA Parameters read-only parameters that reflect automatically the
RBS feature capability and parameter settings

ManagedElement
Read-only
ManagedElement +-RncFunction
reflecting
+-NodeBFunction +-UtranCell
RBS settings
+-Iub +-Hsdsch
+-IubDataStreams hsAqmCongCtrlSupport
hsAqmCongCtrlSpiOnOff {OFF/ON}
Default setting: hsAqmCongCtrlSpiSupport
SPI0: OFF 1, 2, 3, 4, 7
SPI1: ON
SPI2: ON
SPI3: ON
SPI4: ON Must be
SPI5: OFF +-IurLink configured
SPI6: OFF +-ExternalUtranCell
SPI7: ON hsAqmCongCtrlSupport
{OFF/ON}
hsAqmCongCtrlSpiSupport
SPI15: OFF 1, 2, 3, 4, 7
Service Differentiation
Maximum Bit Rate (MBR) QoS Profiling
MBR set in HLR

Maximum Bit Rate (MBR) value is

a QoS parameter negotiated
between UE and CN. CN
A maximum value is typically MBR policing (SGSN)
configured by the operator,
usually in the HLR. Iu
RNC
MBR can be used in case of
HSDPA to avoid possible TCP MBR QoS
time-outs in case MBR policing is profiling
used in the CN
MBR can also be used to enforce Iub
users differentiation (e.g. gold,
silver and bronze subscriptions)
RBS 1MB/s
MBR QoS
Bronze profiling
Silver 10MB/s
Gold
100kB/s
HSDPA Max Bit Rate Limitation
Gives bit rate user differentiations

RNC limits the downlink max bit rate

Limiting the downlink flow
Maximum Bit Rate Handling

Traffic policing and shaping according to support/activation of HSDPA QoS Profiling and Flow Control

Policy = f(MBR)

AQM (only for R99)

HSDPA Flow Control = OFF HSDPA Flow Control = ON

HS-DSCH data frames bitrate
Shaping = f(MBR)
HSDPA MBR QoS Profiling HSDPA MBR QoS Profiling
Not supported
HS-DSCH data frames bitrate HS-DSCH data frames bitrate
Shaping = CA Shaping = f(Min(MBR,CA))

HSDPA Flow Control

MC Downlink User Plane Priority Queue
SC-PQ SC-PQ SC-PQ MC-PQ SC-PQ SC-PQ SC-PQ

HS-DSCH Scheduler (Cell 1 and Cell 2)

HARQ HARQ
(Cell 1) (Cell 2)

TFRC Selection TRFC Selection

(Cell 1) (Cell 2)

Channel Coding Channel Coding

(Cell 1) (Cell 2)

ACK/NACK ACK/NACK
Cell 1 Cell 2
Joint scheduling principle of HS-DSCH
scheduler

SC-PQa SC-PQb SC-PQc MC-PQ SC-PQd SC-PQe SC-PQf

Input/Output to/from the scheduler

Input/Output to/from the scheduler

from/to other functions in the cell

from/to other functions in the cell

HS-DSCH Scheduler

Scheduling Result
(Cell 1 and Cell 2)
Priority PQ Cell
The MC-PQ is prioritized against other PQs in
each of the cells in the MSS. 1. SC-PQf 2
2. SC-PQb 1
3. MC-PQ 2
4. SC-PQa 1
5. MC-PQ 1
6. SC-PQe 2
7. SC-PQc 1
8. SC-PQd 2
Cell 1 Cell 2

MC Scheduling Set
EUL scheduling
 EUL scheduling - Basics
Basic functionality implies that whenever a EUL user enters the system it is
assigned an initial minimum hardware allocation and a scheduled grant
of zero kbps.
Why initial minimum hardware allocation facilitates terminal to send
non-scheduled data, for example signaling and rate requests.
Why scheduled grant of zero kbps a minimum amount of hardware is
already allocated to the user first increase of scheduled grant from zero
kbps to a scheduled data rate that is equal to the minimum HW is very
quick and does not require new HW to be allocated
EUL user sends scheduled data in uplink only if it is assigned a non-zero
scheduled grant.Hence EUL scheduler will only give a user a non-zero
scheduled grant, if it receives a request from that user (for example via the
'happy bit) that indicates that the user requires sending data on a higher
data rate
 EUL scheduling - Basics
3GPP definition conditions for a UE being unhappy with its scheduled
grant as long as the terminal is unhappy with the scheduled grant the
EUL scheduler tries to increase it in steps provided that all resource checks
are passed.

UE finishes data transactions there is no more data coming from the

terminal scheduled grant is eventually reduced (back) to zero kbps +
minimum hardware allocation is kept until the connection is released.
 EUL scheduling - Basics
Important aspects for managed uplink Uu load: Coverage and stability
Noise rise (rise-over-thermal) determines the coverage reduction (cell
breathing) and can be expressed as the total interference divided by the
thermal noise level.
Total interference = signals from terminals controlled by the own cell
(intra-cell interference) + signals from terminals controlled by other cells
(near-fra orovershooting problems) + possible external interference sources
+ thermal noise.
stability only parameter from totalinterference to be controlled is the
intra-cell interference target is to limit the load caused by interference
generated in own cell only in order to avoid party effects (power rushes).
 EUL scheduling - Basics
Important aspects for managed uplink hardware
EUL scheduler manages the HW consumption of EUL users that is required
to send scheduled data (hardware available to EUL users fluctuates with
time)
uplink resource shortage ? EUL scheduler re-distributes the available
resources between the EUL users that are transmitting and requesting
resources
Uplink resources
The uplink resources controlled by the enhanced uplink
scheduler are:
- The air-interface (Uu) interference load
- The RBS hardware (CE)

The Iub flow control feature requests the scheduler to

reduce the rate of EUL users in Iub congestion situations
The uplink resources controlled by the enhanced
Overview of the work flow of the EUL
scheduler
 Rate Requests and Transmission of
Absolute or Relative Grants
scheduled grant is the maximum
scheduled data rate that the EUL
scheduler can expect from an EUL user

E-DPDCH carries both scheduled data and non-scheduled (RRC sig)

E-DPCCH carries uplink control information such as the happy bit and information about which
transport format (e-TFCI) that is used by the UE in the current TTI.
Scheduling Control Signaling

Scheduling request (UL) Absolute grant Relative grants

Used by the UE to request

Rate
UE1
Request
more resources
Absolute grant (DL)

Rate
UE2
Used for large absolute
changes of the data rate
Relative grant (DL)
Single bit, (UP)/HOLD/DOWN
 Maximum number of serving EUL users
possible to control the maximum number of serving EUL users with a
scheduled grant larger than zero kbps

E-DCH

E-DCH

E-DCH
eulMaxNoSchEdch
E-DCH

E-DCH

E-DCH

E-DCH
EUL Scheduler interactions
RBS UL Uu load
UE
estimator

UE Rate
Increase Request

Iub Flow Control Iub bandwidth

Scheduler Absolute grant

HW resources
in RH

Rate selection

RLS (Radio
Link Supervision)

RNC
CM configuration Radio connection
max and min configuration e-TFCI table UE config
rates at call setup
EUL Scheduler responsibility

RBS

Scheduler
Iub HW resources
resources for for all cells
all cells served served by RBS
by RBS

Cell A Cell B Cell C

Uu Uu Uu
interface interface interface
resources resources resources
(e.g. load) (e.g. load) (e.g. load)
 Resource calculation Input to scheduler;
UL Uu load, UL Iub flow Control and RH

7 dB 2 Mbps 128 CE

EUL scheduling
Scheduler
Total pool size

limit
E-DCH

Same DCH can occupy

different proportions of
DCH resource pool in Uu, Iub and
0 HW pools
UL Noise Rise

UL Iub capacity

UL CE
 Interference headroom in Uu Load
Estimator
The headroom reported to the EUL scheduler is always the minimum of the two
 E-TFCI Selection
1. scheduler estimates the
amount of available resources
and signals information to the
UE corresponding to the
maximum E-DPDCH/DPCCH
power ratio the UE may use.
TF8
2. The UE then translates this
ratio to an appropriate TF7
transport format (E-TFC). This
is the maximum transport TF6
format the UE may use. Amount of available data
However, the UE might e.g. be TF5
power limited or have no data
in its buffer and therefore
TF4
Scheduling Grant
choose a lower transport TF3
format.
UE Power Limitation
3. The actual transport format TF2
that the UE uses is not known
by the system and is therefore
TF1 Selected TF
signaled explicitly as the E-
TFCI on the E-DPCCH in UL.
 Scheduling example

UL interference
Max allowed interference
UE TX power granted by scheduler
E-DCH MAC-e
in RBS
rate selection
user 1
Bit rate (transport format E-TFCI) E-DCH MAC-e
adjusted based on available rate selection
user 2
resources

power control tries to maintain that

rate and compensates for path loss,
fading and interference changes on R5 DCH + other interference
the radio link
t
E-TFC Transport Block size table 1
TB Index TB Size (bits) TB Index TB Size (bits) TB Index TB Size (bits) TB Index TB Size (bits) TB Index TB Size (bits)

0 18 25 2370 50 6438 75 10788 100 14892

1 186 26 2388 51 6756 76 10824 101 15156

2 204 27 2706 52 6774 77 11124 102 15228

3 354 28 2724 53 7092 78 11178 103 15492

4 372 29 3042 54 7110 79 11460 104 15564

5 522 30 3060 55 7428 80 11514 105 15828

6 540 31 3378 56 7464 81 11796 106 15900

7 690 32 3396 57 7764 82 11850 107 16164

8 708 33 3732 58 7800 83 12132 108 16236

9 858 34 3750 59 8100 84 12186 109 16500

10 876 35 4068 60 8136 85 12468 110 16572

11 1026 36 4086 61 8436 86 12522 111 17172

12 1044 37 4404 62 8472 87 12804 112 17244

13 1194 38 4422 63 8772 88 12858 113 17844

14 1212 39 4740 64 8808 89 13140 114 17916

15 1362 40 4758 65 9108 90 13194 115 18516

16 1380 41 5076 66 9144 91 13476 116 18606

17 1530 42 5094 67 9444 92 13530 117 19188

18 1548 43 5412 68 9480 93 13812 118 19278

19 1698 44 5430 69 9780 94 13866 119 19860

20 1716 45 5748 70 9816 95 14148 120 19950

21 1866 46 5766 71 10116 96 14202

22 1884 47 6084 72 10152 97 14484

23 2034 48 6102 73 10452 98 14556

24 2052 49 6420 74 10488 99 14820

EUL Scheduler QoS Support
internal priority for a user is determined based both on the granted rate for
that user and the Scheduling Weight eulSchedulingWeight.
A higher rate means a higher internal priority.
A lower Scheduling Weight means a lower internal priority.

eulSchedulingWeight is a configurable weight factor associated with

each of the 16 Scheduling Priorities (SPI) in the system.
By configuring this parameter the operator may control the relative
bandwidth allocated between individual users that have services with
different SPIs.
EUL Scheduler QoS Support

Scheduling priority (SPI) is considered in user

priority in EUL scheduler to support THP
Each Scheduling Priority is associated with an operator
configurable weight factor eulSchedulingWeight.
The user priority is determined from the following criteria
in the given order:

1. QoS Priority = Granted Rate/eulSchedulingWeight

2. User SPI
3. Number of TTI the user has been unhappy
EUL Scheduler QoS Support
Examples
1. A special case is that if eulSchedulingWeight is set to infinity for an
SPI then users with that SPI have a higher priority than all users using
an SPI with a non infinity setting of eulSchedulingWeight.
2. If a number of users have different SPIs and each have
eulSchedulingWeight set to infinity then the internal priority between
those users is based only on the SPI, and the users with a higher SPI
always have a higher internal priority.
Priority in Scheduling of Users
One priority list at each resource pool
Users in cell A, based on Uu rate
Users in cell B, based on Uu rate
Users in cell C, based on Uu rate
All users in RBS, based on HW rate

Priority based on rate and Scheduling Weight (eulSchedulingWeight):

- lowest rate = highest prio (Uu rate for Uu pools, Iub rate for Iub pool,
etc)
- lowest weight = lowest prio
Rates mapped from e-TFCI used: resource cost table
Equal prio? then oldest request wins
Still equal prio? then oldest grant loses
EUL Scheduler Operation
After the initial increase the scheduled rate is increased at least to
eulTargetRate
continue to increase scheduled rate with the maximum step size at each
consecutive scheduling action until:

there are no more resources to schedule,

or
the UE signals that it is "happy",
or
the grant reaches the maximum value that is allowed for the user
(determined from the E-DCH MBR for the connection received over
NBAP).
EUL Scheduler: 2 ms TTI vs 10 ms TTI

EUL Scheduler supports both 10 ms and 2 ms users

2 ms and 10 ms users have an equal rate component of priority

eulTargetRate, eulMaxShoRate, eulNonServHwRate and eulLowRate apply
both for 2 ms and 10 ms EUL scheduler performs quantization
Transittions between 2 and 10 ms TTI are supported
 EUL Scheduler
Scheduled Grant
Left over
User rate
User Data rate

Max step
0 to 6016 kbps
default:128 kbps
Max step
eulTargetRate

Step up TargetRate

Minimum hardware allocation

Zero kbps

Time
UE rate increase request Absolute Grant order to UE
 Feature: EUL Single HARQ Process
Scheduling
20 kbps rate allows for more 2 ms TTI users
HARQ #1 transmitting at the same time
Significant increase
=> lower latency
in capacity in terms
of the number of HARQ #2
users and lower
latency
HARQ #3 eul2msFirstSchedStep = 20, 160 default = 160 kbps

HARQ #4

HARQ #5
FAJ 121 1443

HARQ #6
One 40-Byte PDU
every 8 sub-frames
HARQ #7
40 X 8 ManagedElement
= 20 kbps +-NodeBFunction
8 X 2 X1000 licenseStatePerHarqProcessGrant = ENABLED
HARQ #8
featureStatePerHarqProcessGrant = ACTIVATED
 Enhanced UL - Scheduling

Rate adaptation within RBS

Complement to the RNC CELL_FACH CELL_DCH switching
UE rate request instead of system evaluation delay

Idle E-DCH FACH E-DCH FACH Idle

Sched rate Inactivity timers

/UE rate

Minimum ....
HW alloc
0
Time
Absolute

Absolute

Absolute
Absolute
increase

increase

increase
UE rate

UE rate
request

request

UE rate
request
grant

grant

grant
grant
Rescheduling UE indicates unhappy

Why?
UE1 requests rate increase, but no resources left
When?
UE2 have lower prio
After rescheduling: new prio for UE2 new prio for UE1
After rescheduling: scheduled grant for UE2 eulTargetRate

2
Sceduled grant

2
eulTargetRate

eulTargetRate
Scheduled grant

Calculated rates Min step size

Calculated rates

1 1

Zero kbps Zero kbps

Rescheduling OK! Rescheduling NOK!

EUL Scheduler Enhancements
Unused Air Interface resources recovered
and used either for scheduling more users
or for increasing the cell throughput

Utilization based
<=160 kbps
Load Estimation

FAJ 121 1443

>160 kbps Grant based

Load Estimation
HW allocation - example one EUL Soft HO
user
Serving cell Non-Serving cell

Resources
Resources dynamically
dynamically available for
available for other EUL Resources
dynamically
EUL users users allocated for one
EUL user in non-
serving cell =
eulNonServHwRate
pre-alloc HW allocated HW
pre-alloc HW
minimum pre- allocated HW
minimum allocated
allocated HW HW (static)
(static) UE in
Soft HO
Current Current
DCH DCH
consumption consumption
Scheduling in soft HO, example
5

1
4
2
3

Rate Mbps
SHO
5
1 Event 1d-hs
eulMaxShoRate
eulNonServHwRate

1.472

SHO
gain!

0.384

0.128 2
4
3