06 packetscheduling 2006 partner
Post on 23-Jan-2016
36 Views
Preview:
DESCRIPTION
TRANSCRIPT
1 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Course Content
• Radio Resource Management Overview
• Parameter Configuration
• Common Channels & Power Control
• Load Control
• Admission Control
• Packet Scheduling
• Handover Control
• Resource Manager
2 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
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
3 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Packet Scheduling• Overview
• Packet Transfer States & Parameters• Bitrate Allocation• Capacity Request & Traffic Volume Measurements • Channel Type Selection• Processing a Capacity Request• Packet Scheduler Interruption Timer
• Bitrate Upgrade
• Overload Control
• Dynamic Link Optimisation (DyLo)
• Activation Time optimization
4 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Why Packet Scheduling?
Load(~ Power)
time
PlannedLoad/PowerTargetFree Capacity
Non-Controllable Load• real time traffic• interference from other cell users• noise
• Suitable for controllable load (=best effort NRT)• Requires fast resource allocation
5 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Nokia Packet Scheduler – main features
6 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Packet Scheduling Principles
Cell_FACH Cell_DCH Cell_FACH
Uplink DCH
Downlink DCH
non-GBR RB data transfer active Radio link & Iub AAL2 setupnon-GBR RB inactivity timer running Radio link & Iub AAL2 release
RRC state
7 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Cell_FACH Cell_DCH Cell_FACH
Uplink DCHs
Downlink DCHs
GBR RB Radio link & Iub AAL2 setupnon-GBR RB data transfer active Radio Link & Iub AAL2 modificationnon-GBR RB inactivity timer running Radio link & Iub AAL2 release
RRC state
Packet Scheduling Principles
8 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
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, 8, 16, 32, 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
9 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Packet Scheduling
Power/ Load
time
non-controllable loadi.e. RT Traffic
controllable loadi.e. non RT Traffic
PtxTotal (variable) PrxTotal
PtxNrt PrxNrt
PtxTarget PrxTarget
PtxOffset PrxOffset
PtxTargetBTS PrxTargetBTS
overload
DesiredPrx/PtxValues
PtxRt PrxRt
10 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
RAN1.5.1RAN1.5.1RAN1.5.1 RAN1.5.2ED2
RAN1.5.2EDRAN1.5.2ED22 RAN04RAN04RAN04 RAN05RAN05RAN05
Supported Radio Bearers in RANFuture itemsFutureFuture itemsitems
AMR 12.2
AMR = Conversational CS speechTransparent CS data = Conversational CS dataUDI = Unrestricted Digital Information (Video Call)Non-transparent CS data = Streaming CS dataNRT PS data = Interactive/Background PS data
RBs of higher uplink bit rates than 64 kbit/s not end-to-end tested, up to UE availability. Delivery 6 monthsfrom a stabile UE for the tests at earliest.
Streaming PS data RBs are subject to changes and restrictions according to 3GPP TS 25.993 and TS 34.108. Delivery 6 months from a stabile UE for the tests at earliest. 256 for DL only.
AMR 12.2Transparent CS data (UDI) 64Transparent CS data (UDI) 64Non-transparent CS data 14.4, 57.6Non-transparent CS data 14.4, 57.6NRT PS data 64, 128, 384NRT PS data 64, 128, 384
Non-transparent CS data 14.4Non-transparent CS data 14.4NRT PS data 8, 16, 32NRT PS data 8, 16, 32Streaming PS data 8, 16, 32, 64, 128, 256 (DL)Streaming PS data 8, 16, 32, 64, 128, 256 (DL)
NRT PS data 256NRT PS data 256
Lower AMR speech ratesLower AMR speech rates
WB-AMR speechratesWB-AMR speechrates
ConversationalPS QoSConversationalPS QoS
11 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Packet Scheduling• Overview
• Packet Transfer States & Parameters• Bitrate Allocation• Capacity Request & Traffic Volume Measurements • Channel Type Selection• Processing a Capacity Request• Packet Scheduler Interruption Timer
• Bitrate Upgrade
• Overload Control
• Dynamic Link Optimisation (DyLo)
• Activation Time optimization
12 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
URA_PCH
CELL_DCH CELL_FACH
CELL_PCH
UTRA RRC Connected Mode
Idle Mode
URA_PCH
CELL_DCH CELL_FACH
CELL_PCH
Cell selectionCell re-selection
Dedicated resourcesallocated (DCH)Tx and Rx mode
Common resourcesallocated (RACH-FACH)
Tx and Rx mode
UE in DRX modediscontinous receiption
UE in DRX modediscontinous reception
RRC State Machine
IuB
Cell Update, UL Tx
UL/DL activation timer
Traffic volumeInactivity Timer
UL Tx
Frequent cell updates
13 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
PS Connection Establishment
RNCUE SGSN
RRC Connection Establishment (SRB)
MM & CC (e.g. PDP Context Activation)
RAB Assignment RequestTraffic Volume Parameters
determination
Measurement Control [Traffic Volume Measurements]
CELL_DCH
Start• RB_InactivityTimer• SignallingLinkInactivityTimer
RB_InactivityTimerexpiry
Capacity Request?
DCH for NRT RB(s) allocation
no
yes
yes
SignallingLinkInactivityTimeexpiry
CELL_FACH
14 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Transition from CELL_DCH to CELL_FACH
RNCUECELL_DCH Node B
PDU Transport on the DCH/DPCH
All data is sent andRLC-U buffer is empty
Inactivity detected Start
InactivityTimerUplinkDCHInactivityTimerDownlinkDCH
Radio Bearer Reconfiguration
Radio Bearer Reconfiguration Complete
ExpiryCELL_FACH
L2 configuration
Radio Link Release
StartMAC: Inactivity detected
UL/DL activation timer
15 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Transition from CELL_FACH/CELL_PCH to Idle
StartMAC: Inactivity detected
UL/DL activation timer
UECELL_FACH
CELL_FACH Cell Update
Cell UpdateCell Update Confirm
URA_PCH
MaxCellReselectionsCellReselectionObservingTimeandMaxPeriodicalCellUpdates
Start
Expiry
Expiry
RNC
analog inCELL_PCH
URA Update
URA UpdateURA Update Confirm
Inactivity detected
Transition to URA_PCH
MSActivitySupervision
URA_PCH
RRC-IDLE
CELL_PCH Radio Bearer Reconfiguration
16 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Transition from CELL_FACH to CELL_DCH
RNCUECELL_FACH Node B
UL & DL packet scheduling
Radio Bearer Reconfiguration
Measurement Report (Traffic Volume Event e4a)
CELL_DCH
Radio Link Setup
Radio Bearer Reconfiguration Complete
UE initiated
17 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Transition from CELL_FACH to CELL_DCH
RNCUECELL_FACH Node B
DL capacity need isdetected by MAC
Radio Bearer Reconfiguration
CELL_DCH
Radio Link Setup
Radio Bearer Reconfiguration Complete
RNC initiated
Channel type selection-> DCH
UL & DLpacket scheduling
18 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
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
• SignallingLinkInactivityTimer• The timer is used for inactivity detection of the signaling link in CELL_DCH and
CELL_FACH states. The timer is set after inactivity of the signaling link is detected and reset when any activity detected. In expiry of the timer, a state transition from CELL_DCH to CELL_FACH (or from CELL_FACH to CELL_PCH) state is initiated when also the corresponding RB inactivity timer(s) expired. default value: 2s; range: 0 ... 20 s; step 0.5 s
19 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
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
20 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Nokia Parameters
• UL/DL activation timer• This timer is set when the MS is transferred to CELL_FACH state due to inactivity, or MS
inactivity is detected in CELL_FACH state (CELL_FACH-> IDLE)default value: : 2s; Recommendation is to set this to 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
21 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
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 changedrange: 0 ... 100 times; step 1 times
• MaxPeriodicalCellUpdates• Counter for a number of Periodical Cell Updates in CELL_FACH or CELL_PCH state
before transition to URA_PCH state
• default value: 1 time; range: 0 ... 10 times; step 1 times
22 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
IdleMode
Cell_FACH
• Inactivity detection of NRT RB
• Release of RT RB
• Cell reselection (moving UE)
• Periodic cell update (stationary UE)
• Paging response (DL data/ signalling)
• UL Access (UL data/signalling)
• URA reselection Periodic URA update (stationary MS)
• Periodic URA update (stationary MS)
• Paging response (DL data / signalling)
• UL Access (UL data / signalling) Cell_
PCH
• Activity supervision• Completion of Cell Update procedure
• Setup of RT/NRT RB• RAB reconfiguration • DCH Up or Downgrade• Bit rate reduction due to load reasons
Cell_DCH
• CN originated paging (MT Call)• Random Access (MO Call)
URA_PCH
• Completion of URA Update procedure
• Max. number of periodic cell updates in Cell_FACH / Cell_PCH exceeded
• UL/DL data or signalling
• RT RB setup
RRC Connection Release
Summary
23 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Packet Scheduling• Overview
• Packet Transfer States & Parameters• Bitrate Allocation• Capacity Request & Traffic Volume Measurements • Channel Type Selection• Processing a Capacity Request• Packet Scheduler Interruption Timer
• Bitrate Upgrade
• Overload Control
• Dynamic Link Optimisation (DyLo)
• Activation Time optimization
24 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Decrease loadingIncrease loading
Bit rate allocation algorithm
PrxTotal < PrxTarget NOYES
PrxTotal <PrxTarget + PrxOffsetYES
Allocate bit rates
end
NO
Calculate PrxAllowed
Bit Rate Allocation - Overview
nrtrxncrxtotalrx PPP ___ +=
non-controllable power
controllable power
inactivertrxinactivenrtrx
totalrxettrxallowedrx
PP
PPP
____
_arg__
−−
−=
estimated received power of admitted RT bearers still in the in the establishment phase
estimated received power of RT admitted but currently inactive bearers
Example: UL
25 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Packet Scheduling and Load Control
RNCRadio Resource Indication
Node B
Radio Resource Indication
Radio Resource Indication
Radio Resource Indication
RRIndPeriod
Packet Scheduler decision frequency: SchedulingPeriod
nntPtPtP
P totalrxtotalrxtotalrxtotalrx
))1((...)1()( ____
−−++−+=
n = PSAveragingWindowSize
Averaged PrxTotal:
Averaged PtxTotal: (analog to averaged PrxTotal)
time
26 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
• 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 6Averaging Window Size = 3 5.0 7.3 7.7Averaging Window Size = 4 4.0 6.3 7.0Averaging Window Size = 5 4.0 5.2 6.2
Parameters for Packet Scheduling
27 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Parameters for Packet Scheduling• MinAllowedBitRateUL
• This parameter defines the minimum allowed bit rate in uplink that can be allocated by the PS
• default value: 16 kbps; range: 8 kbps, 16 kbps, 32 kbps, 64 kbps, 128 kbps, 256 kbps, 320 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, 320 kbps, 384 kbps
• In RAN1.5.2 MinAllowerBitrateUL is always 64 kbits/s and MinallowedbitrateDLcan be 64,128 or 384 kbits/s
28 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Parameters for Packet Scheduling• SchedulingPeriod
• This parameter defines how often the packet scheduler makes scheduling decisions, and when it can start doing allocations.default value: 500 ms; range: 100 ... 2000 ms, step 100 ms
• Note: The value of the scheduling period should be set longer than (or equal) the Radio Resource Indication period (RRIndPeriod) in order to have the latest load information available for packet scheduling.
• RRIndPeriod• The parameter defines the reporting period of the Radio Resource Indication messages,
which are used for cell based load measurements
• default value: 500 ms; range: 0 ... 2000 ms, step 100 ms.
• With the Radio Resource Indication message the BTS reports periodically the total uplink interference power of the cells and the total transmitted power of the cell and RACH load (average number of RACH received per radio frame).
29 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Packet Scheduling• Overview
• Packet Transfer States & Parameters• Bitrate Allocation• Capacity Request & Traffic Volume Measurements • Channel Type Selection• Processing a Capacity Request• Packet Scheduler Interruption Timer
• Bitrate Upgrade
• Overload Control
• Dynamic Link Optimisation (DyLo)
• Activation Time optimization
30 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
UL Traffic Volume Based RRC State TransitionReporting event:
4A: Transport Channel Traffic Volume becomes larger than an absolute threshold
time
Transport ChannelTraffic Volume
(= UE Buffer Load)
Thresholds
4A 4A 4A
RNCUEMeasurement Report (Traffic Volume Event)
UE in CELL_FACH: TrafVolThresholdULLow (128 Bytes)UE in CELL_DCH: TrafVolThresholdULHigh (4096 Bytes)
Measurement Report (Traffic Volume Event)TrafVolPendingTimeUL (2s)
4A 4AMeasurement
report hasinformation about
currentUE buffer load
31 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
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
32 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Uplink traffic volume measurements
Traffic volume measurement not triggered
RLC
buff
er p
aylo
adRL
C bu
ffer
pay
load
(tra
nspo
rt c
hann
el t
raff
ic v
olum
e)(t
rans
port
cha
nnel
tra
ffic
vol
ume)
UL data transmission on RACH in
CELL_FACH state
UL data transmission on DCH in CELL_DCH
state
TrafVolThresholdULLow (Cell parameter)
4A
TrafVolThresholdULHigh (RNC parameter)
Traffic volume measurement triggered, request for high bit rate4A
33 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Downlink traffic volume measurements
RLC
buff
er p
aylo
adRL
C bu
ffer
pay
load
(tra
nspo
rt c
hann
el t
raff
ic v
olum
e)(t
rans
port
cha
nnel
tra
ffic
vol
ume)
TrafVolThresholdDLLow (Cell parameter)
TrafVolThresholdDLHigh (RNC parameter)
DL data transmission on FACH in
CELL_FACH state
DL data transmission on DCH in CELL_DCH
state
Traffic volume measurement not triggered
Traffic volume measurement triggered, request for low bit rate
Traffic volume measurement triggered, request for high bit rate
34 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
• TrafVolThresholdULLow• This parameter defines, in bytes, the threshold of data in the RLC buffer of RB that
triggers the uplink traffic volume measurement report, when the UE is in Cell_FACH state.
• Otherwise, UE sends data on RACH.
• This parameter is sent to the UE using an RRC: MEASUREMENT CONTROL message.
• default value: 128 bytes; range: 8 bytes, 16 bytes, 32 bytes, 64 bytes, 128 bytes, 256 bytes, 512 bytes, 1024 bytes (1 KB)
• TrafVolThresholdULHigh• The parameter defines the threshold of data in RLC buffer of RB in bytes.
• The parameter is sent to the UE using the RRC: MEASUREMENT CONTROL message.
• default value: 4096 bytes; range: 8 bytes, 16 bytes, 32 bytes, 64 bytes, 128 bytes, 256 bytes, 512 bytes, 1024 bytes (1 KB), 2048 bytes (2 KB), 3072 bytes (3 KB), 4096 bytes (4 KB)
UL Traffic Volume Based RRC State Transition
35 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
• TrafVolPendingTimeUL• This parameter indicates the period of time, in seconds, during which it is forbidden to
send any new traffic volume measurement reports with the same measurement ID, even if the triggering condition is fulfilled again
• Parameter is sent to UE using an RRC: MEASUREMENT CONTROL message.
• default value: 2000 ms; range: 250 ms, 500 ms, 1000 ms, 2000 ms, 4000 ms, 8000 ms, 16000 ms
• Note: The same value should be set in all cells within a Node B
• TrafVolTimeToTriggerUL• This parameter defines, in ms, the period of time between the timing of event detection
and the timing of sending a traffic volume measurement report.
• This parameter is sent to the UE using an RRC: MEASUREMENT CONTROL message.
• default value: 0 ms; range: 0 ms, 10 ms, 20 ms, 40 ms, 60 ms, 80 ms, 100 ms, 120 ms, 160 ms, 200 ms, 240 ms, 320 ms, 640 ms, 1280 ms, 2560 ms, 5000 ms
UL Traffic Volume Based RRC State Transition
36 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
• 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
• default value: 128 bytes; range: 0 bytes, 8 bytes, 16 bytes, 32 bytes, 64 bytes, 128 bytes, 256 bytes, 512 bytes, 1024 bytes (1 KB)
• TrafVolThresholdDLHigh• This parameter defines the threshold of data in the RLC buffer of RB in bytes which
triggers downlink traffic volume measurement report (capacity request) on MAC, when UE is in a Cell_DCH state and the initial bit rate DCH is allocated for the radio bearer
• default value: 4096 bytes; range: 0 bytes, 8 bytes, 16 bytes, 32 bytes, 64 bytes, 128 bytes, 256 bytes, 512 bytes, 1024 bytes (1 KB), 2048 bytes (2 KB), 3072 bytes (3 KB), 4096 bytes (4 KB)
DL Traffic Volume Based RRC State Transition
37 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
• TrafVolTimeToTriggerDL• This parameter defines, in ms, the period of time between the timing of event detection
and the timing of sending a downlink capacity request
• default value: 0 ms; range: 0 ms, 10 ms, 20 ms, 40 ms, 60 ms, 80 ms, 100 ms, 120 ms, 160 ms, 200 ms, 240 ms, 320 ms, 640 ms, 1280 ms, 2560 ms, 5000 ms
• TrafVolPendingTimeDL• This parameter indicates the period of time, in ms, during which it is forbidden to send
any new downlink capacity requests with the same RB id, even if the triggering condition is fulfilled again
• default value: 2000 ms; range: 250 ms, 500 ms, 1000 ms, 2000 ms, 4000 ms, 8000 ms, 16000 ms
DL Traffic Volume Based RRC State Transition
38 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
RN23 Monitoring ResultsRN23 Monitoring Results
Fact Recaped:Fact Recaped:
Effective Date & Time: 12 April 2006 @ 1900hrsEffective Date & Time: 12 April 2006 @ 1900hrs
Parameter changed: RNC Parameter changed: RNC PS Tab PS Tab Traffic Volume Traffic Volume Measurement High Threshold Measurement High Threshold Downlink = 1024bytes to Downlink = 1024bytes to
4096bytes4096bytes
39 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
RN23 – DUR_PS_BACKG_XXX_DL_IN_SRNC (384/128/64kbps)
40 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
RN23 – DUR_PS_BACKG_XXX_DL_IN_SRNC (384/128/64kbps)
Before ChangeBefore Change After ChangeAfter Change
41 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Counters MonitoredCounters Monitored
42 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
DUR_PS_BACKG_XXX_DL_IN_SRNC (M1002C233-37)
43 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Example SignallingExample Signalling
44 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
E.g. Signalling – Emome WAP (TrafVolThresholdDL High = 1024bytes)
Initial & Min. Bitrate = 128kbps assigned
SF16 = 128kbps
Initial & Min. Bitrate = 128kbps Initial & Min. Bitrate = 128kbps assigned assigned
SF16 = 128kbpsSF16 = 128kbps
DL Capacity Request Radio Bearer Reconfig to upgrade to Max. Bitrate = 384kbps
SF8 = 384kbps
DL Capacity Request DL Capacity Request Radio Radio Bearer Reconfig to upgrade to Bearer Reconfig to upgrade to Max. Bitrate Max. Bitrate = 384kbps= 384kbps
SF8 = 384kbpsSF8 = 384kbpsTypically 2 stages of Radio Bearer Reconfiguration: Init & Min Max Bitrate Upgrade if data amount arriving at RNC RLC Buffer > TrafVolThresholdDLHigh ( DL Capacity Request triggered)
Typically 2 stages of Radio Bearer Typically 2 stages of Radio Bearer Reconfiguration: Init & Min Reconfiguration: Init & Min Max Bitrate Max Bitrate Upgrade if data amount arriving at RNC RLC Upgrade if data amount arriving at RNC RLC Buffer > TrafVolThresholdDLHigh (Buffer > TrafVolThresholdDLHigh ( DL DL Capacity Request triggered)Capacity Request triggered)
45 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
E.g. Signalling – Emome WAP (TrafVolThresholdDL High = 4096bytes)
Initial & Min. Bitrate = 128kbps assigned
SF16 = 128kbps
Initial & Min. Bitrate = 128kbps Initial & Min. Bitrate = 128kbps assigned assigned
SF16 = 128kbpsSF16 = 128kbps
No DL Capacity Request to upgrade Radio Bearer, RB remains at Init & Min Bitrate = 128kbps
SF16 = 128kbps
No DL Capacity Request to No DL Capacity Request to upgrade Raupgrade Radio Bearer, RB dio Bearer, RB remains at Init & Min Bitrate remains at Init & Min Bitrate = = 128kbps128kbps
SF16 = 128kbpsSF16 = 128kbps
Typically 2 stages of Radio Bearer Reconfiguration: Init & Min Max Bitrate Upgrade if data amount arriving at RNC RLC Buffer > TrafVolThresholdDLHigh ( DL Capacity Request triggered).
In this case, WAP surfing is not assigned max bitrate of 384kbps due to the low byte size of Emome WAP pages.
Typically 2 stages of Radio Bearer Reconfiguration: Typically 2 stages of Radio Bearer Reconfiguration: Init & Min Init & Min Max Bitrate Upgrade if data amount Max Bitrate Upgrade if data amount arriving at RNC RLC Buffer > TrafVolThresholdDLHigh arriving at RNC RLC Buffer > TrafVolThresholdDLHigh (( DL Capacity Request triggered).DL Capacity Request triggered).
In this case, WAP surfing is not assigned max bitrate In this case, WAP surfing is not assigned max bitrate of 384kbps due to the low byte size of Emome WAP of 384kbps due to the low byte size of Emome WAP pages.pages.
46 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
E.g. Signalling – Nemo FTP (TrafVolThresholdDL High = 1024bytes)
Initial & Min. Bitrate = 128kbps assigned
SF16 = 128kbps
Initial & Min. Bitrate = 128kbps assigned Initial & Min. Bitrate = 128kbps assigned
SF16 = 128kbpsSF16 = 128kbps
DL Capacity Request Radio Bearer Reconfig to upgrade to Max. Bitrate = 384kbps
SF8 = 384kbps
DL Capacity Request DL Capacity Request Radio Bearer Radio Bearer Reconfig to upgrade to Max. Bitrate Reconfig to upgrade to Max. Bitrate = = 384kbps384kbps
SF8 = 384kbpsSF8 = 384kbps
Typically 2 stages of Radio Bearer Reconfiguration: Init & Min Max Bitrate Upgrade if data amount arriving at RNC RLC Buffer > TrafVolThresholdDLHigh (1024bytes) ( DL Capacity Request triggered)
Typically 2 stages of Radio Bearer Typically 2 stages of Radio Bearer Reconfiguration: Init & Min Reconfiguration: Init & Min Max Bitrate Max Bitrate Upgrade if data amount arriving at RNC RLC Upgrade if data amount arriving at RNC RLC Buffer > TrafVolThresholdDLHigh (1024bytes) Buffer > TrafVolThresholdDLHigh (1024bytes) (( DL Capacity Request triggered)DL Capacity Request triggered)
47 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
E.g. Signalling – Nemo FTP (TrafVolThresholdDL High = 4096bytes)
Initial & Min. Bitrate = 128kbps assigned
SF16 = 128kbps
Initial & Min. Bitrate = 128kbps assigned Initial & Min. Bitrate = 128kbps assigned
SF16 = 128kbpsSF16 = 128kbps
DL Capacity Request Radio Bearer Reconfig to upgrade to Max. Bitrate = 384kbps
SF8 = 384kbps
DL Capacity Request DL Capacity Request Radio Bearer Radio Bearer Reconfig to upgrade to Max. Bitrate Reconfig to upgrade to Max. Bitrate = = 384kbps384kbps
SF8 = 384kbpsSF8 = 384kbps
Typically 2 stages of Radio Bearer Reconfiguration: Init & Min Max Bitrate Upgrade if data amount arriving at RNC RLC Buffer > TrafVolThresholdDLHigh (1024bytes) ( DL Capacity Request triggered)
Typically 2 stages of Radio Bearer Typically 2 stages of Radio Bearer Reconfiguration: Init & Min Reconfiguration: Init & Min Max Bitrate Max Bitrate Upgrade if data amount arriving at RNC RLC Upgrade if data amount arriving at RNC RLC Buffer > TrafVolThresholdDLHigh (1024bytes) Buffer > TrafVolThresholdDLHigh (1024bytes) (( DL Capacity Request triggered)DL Capacity Request triggered)
48 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Packet Scheduling• Overview
• Packet Transfer States & Parameters• Bitrate Allocation• Capacity Request & Traffic Volume Measurements • Channel Type Selection• Processing a Capacity Request• Packet Scheduler Interruption Timer
• Bitrate Upgrade
• Overload Control
• Dynamic Link Optimisation (DyLo)
• Activation Time optimization
49 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
The channel selection procedure the following parameters are needed:
• Downlink traffic volume measurement low threshold (TrafVolThresholdDLLow)
• Maximum allowed total data amount on FACH (FachDataAllowedTotal)
• Threshold for RACH load (RachLoadThresholdCCH)
• Margin for RACH load (RachLoadMarginCCH)
• Threshold for FACH load (FachLoadThresholdCCH)
• Margin for FACH load (FachLoadMarginCCH)
• Threshold for total downlink transmission power (PtxThresholdCCH)
• Margin for total downlink transmission power (PtxMarginCCH)
(A) Maximum allowed user data amount on FACH exceeded
(B) Maximum allowed total data amount on FACH exceeded
(C) FACH in overload(D) FACH usage forbidden by PS
Request DCH from PSInitial transmission
on FACH
Channel Type SelectionChannel type selection
(A)
(B)
(C)
(D)
end
No
No
No
No
Yes
Yes
Yes
Yes
50 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
DL Traffic Type Selection
time
FACH overload FachLoadThresholdCCH/RachLoadThresholdCCH
FachLoadMarginCCH/RachLoadMarginCCH
FACH in overload
FACH usage ok
time
FACH forbidden
FACH in overload
FACH usage ok
PtxThresholdCCH(relative to PtxTarget
PtxMarginCCH
Load
Power / Load
51 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
• FachDataAllowedTotal• This parameter defines the maximum amount of user data in all RLC buffers that can be
transmitted at any given time on FACH (FACH is already selected)
• default value: 1024 bytes; range: 0 bytes, 8 bytes, 16 bytes, 32 bytes, 64 bytes, 128 bytes, 256 bytes, 512 bytes, 1024 bytes (1 KB), 1536 bytes, 2048 bytes (2 KB), 3072 bytes (3 KB), 4096 bytes (4 KB), 6144 bytes (6 KB), 8192 bytes (8 KB), 12288 bytes (12 KB), 16384 bytes (16 KB), 24576 bytes (24 KB), 32768 bytes (32 KB)
FACH/RACH Load Related Parameters
52 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
• 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%
FACH/RACH Load Related Parameters
53 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
• 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%
FACH/RACH Load Related Parameters
54 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
• 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
FACH/RACH Load Related Parameters
55 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Packet Scheduling• Overview
• Packet Transfer States & Parameters• Bitrate Allocation• Capacity Request & Traffic Volume Measurements • Channel Type Selection• Processing a Capacity Request• Packet Scheduler Interruption Timer
• Bitrate Upgrade
• Overload Control
• Dynamic Link Optimisation (DyLo)
• Activation Time optimization
56 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
new capacity request for a change in data
rate?
No
Yes
New capacity request
No
Modify the content type of the original capacity request in a queue
Delete the new capacity request
YesDelete the request
Start scheduling process(A) Capacity request from UE already in a queue?
(B) Is new capacity request same as original?
(A)
(B)
CrQueuingTimeULCrQueuingTimeDL
based on• Arrival time• Bearer class• Traffic handling priority
Processing of Capacity Request
CrHandlingPolicyULCrHandlingPolicyDL
57 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
• 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 2000 ms; range: 250 ms, 500 ms, 1000 ms, 2000 ms, 4000 ms, 8000 ms, 16000 ms
• Note: This value should be set the same in all cells within a BTS
Processing of Capacity Request
58 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
• CrQueuingTimeDL• This parameter defines how long an downlink capacity request can stay in the
queue before it is permanently removed.default value:4 sec; range: 1 ... 30 sec; step 1 sec
• Note: This value should be the same as TrafVolPendingTimeDL
• TrafVolPendingTimeDL• This parameter indicates the period of time, in milliseconds, during which it is
forbidden to send any new downlink capacity requests with the same RB id, even if the triggering condition is fulfilled again.default value: 2000 ms; range: 250 ms, 500 ms, 1000 ms, 2000 ms, 4000 ms, 8000 ms, 16000 ms
• Note: This value should be set the same in all cells within a BTS
Processing of Capacity Request
59 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
• 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)
Processing of Capacity Request
60 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Packet Scheduling• Overview
• Packet Transfer States & Parameters• Bitrate Allocation• Capacity Request & Traffic Volume Measurements • Channel Type Selection• Processing a Capacity Request• Packet Scheduler Interruption Timer
• Bitrate Upgrade
• Overload Control
• Dynamic Link Optimisation (DyLo)
• Activation Time optimization
61 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Any CRs in queueStart from
CR #1
Estimate PrxTotalNew andPrxNrtNew
Bit rate = MinAllowedBitRate
Increase loading
(A) PtxTotalNew < PtxTarget ANDPtxTotalChange < DeltaPtxMaxUpPtxNrtNew < PtxAllowed
(A)
End
Yes
No
Bitrate Upgrade Process
No
changetotaltxtotaltxnewtotaltx PPP _____ +=
Example: DL
Yesmore CRsin queue
Move toNext CR inQueue
HigherAllowed Bitrates
Move toNext higher
bitrate
NoYes
62 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
128 (1) 256 (1) 384 (1)
Step 3
PrxTarget
No higher bit rateavailable, allocationaccording to step 3
Step 1 Step 2
128 (1)
128 (2)256 (1)
128 (2)
256 (1)
256 (2)
384 (1)
256 (2)PrxTarget
Step 1 Step 2 Step 3 Step 4
128 (1)
Step 5
Target exceeded,allocation according
to step 4
case 1: 1 CR in queue
case 2: 2 CRs in queue
128 (1)128 (2)
128 (3)
256 (1)
256 (2)
PrxTarget
Step 1 Step 2 Step 3 Step 4
128 (1)
Step 5
128 (2)128 (1)
128 (3)128 (2)
256 (1)
128 (3)
Target exceeded,allocation according
to step 4
128 (1)128 (2)
128 (3)
PrxTarget
Step 1 Step 2 Step 3 Step 4
128 (1)
Step 5
128 (2)128 (1) 128 (1)
128 (2)128 (3)128 (4)
256 (1)
128 (3)128 (2)
128 (4)
Target exceeded,allocation according
to step 4
128 (1)128 (2)
128 (3)
PrxTarget
Step 1 Step 2 Step 3 Step 4
128 (1)
Step 5
128 (2)128 (1) 128 (1)
128 (2)128 (3)128 (4)
128 (1)128 (2)128 (3)128 (4)128 (5)
Target exceeded,allocation according
to step 4, noallocation to CR #5
case 3: 3 CRs in queue
case 4: 4 CRs in queue
case 5: 5 CRs in queue
Bit Rate Allocation – Increase Load
63 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Packet Scheduling• Overview
• Packet Transfer States & Parameters• Bitrate Allocation• Capacity Request & Traffic Volume Measurements • Channel Type Selection• Processing a Capacity Request• Packet Scheduler Interruption Timer
• Bitrate Upgrade
• Overload Control
• Dynamic Link Optimisation (DyLo)
• Activation Time optimization
64 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
PrxNrtNew
Overload Control (TFCC)Example: UL
Reduce to nextlower bit rate
Estimate PrxTotalNew and
Lower bit ratesallowed
Switch bearerto CCH
More bearers
Decrease loading
Select randomly one of thehighest bit rate bearers
(A) PrxTotalNew > PrxTarget ANDPrxTotalChange < DeltaPrxMaxDown
(A)End
Yes
No
Yes
No
No
Yes
TFCC means TransportFormat Combination
Control Procedure, noDCH Downgrade but
suspend of highertransport formats
65 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
AC produces the TrCH parameters:
• Transport Formats (TF)
• Transport Format Combination (TFC)
• TFC identifiers
Overload Control (TFCC)
SupportedBitrates
0
TFCS (SL & RT RB)
TrCh 1
TFI0
TFI164
128
384
0
TFI2384
128
Peak BitrateIn Bearer
Parameters
SheduledBitrate
TFS for RT RBintermediate
Bitrates
64
128
0
TFS subsetFor TFCS
construction
64
0
TrCh 2
TFI0
TFI1
0
64
0
TFI1
TFI0TFI0
TFCC here
66 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Example: DL Dedicated Channel Modification
BTS RNC-L2RNC-NBAP RNC-RRC RNC-RRM
BTS providesperiodical cell loadinformation to RRM
packet scheduling
PS indicates UE aboutthe modified capacityand selected UL TFC
subset
NBAP: RADIO RESOURCE INDICATION
UE
IubUu
RLC-PDU transportation on DCH
RR_ind
Capacity_modify
RLC-PDU transportation on modified DCH
UE in CELL_DCH state
[DCH] RRC: TRANSPORT FORMAT COMBINATION CONTROL
RRM detects overloadsituation in uplink
67 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
• In case of 3 bearers
• In case of 6 bearers
384
PrxTarget
Step 1 Step 2 Step 3
384
256
384
256
256
256
256
256
Step 1: 384 -> 256 (TFCC)Step 2: 384 -> 256 (TFCC)Allocation according to step 3
PrxTarget128
128
128
Step 1 Step 2 Step 3 Step 4
128
256
256
128
128
128
256
128
128
128
128
128
128
128
128
128
128128
128
128 Step 1: 256 -> 128 (TFCC)Step 2: 256 -> 128(TFCC)Step 3: 128 -> CCH (Radio Bearer Reconfiguration)Allocation according to step 4
Overload Control
68 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
• DeltaPrxMaxUp –WCELL (not implemented in RAN1.5.2 ED2)• Defines the maximum received uplink power increase in a cell, used when bit rates are allocated
or increased by the packet scheduler, relative to PrxTotal
• default value: 1.6dB; range: 0 ... 5 dB, step 0.2 dB
• DeltaPtxMaxUp-WCELL (not implemented in RAN1.5.2 ED2)• Defines the maximum transmitted downlink power increase in a cell, used when bit rates are
allocated or increased by the packet scheduler, relative to PtxTotal
• default value: 1.6dB; range: 0 ... 5 dB, step 0.2 dB
Bit Rate Allocation
69 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
• LoadControlPeriodPS• This parameter defines how often PS can perform load control actions for each bearer.
default value: 400ms; range: 100 ... 2000 ms, step 100 m
• Note: The value must not be smaller than scheduling period.
• DeltaPtxMaxDown(not implemented in RAN1.5.2 ED2)• Defines the maximum transmitted downlink power decrease in a cell, used when bit rates are
decreased by the packet scheduler, relative to PtxTotal.
• default value: 3dB; range: 0 ... 5 dB, step 0.2 dB
• DeltaPrxMaxDown (not implemented in RAN1.5.2 ED2)• Defines the maximum received uplink power decrease in a cell, used when bit rates are decreased
by the packet scheduler, relative to PrxTotal.
• default value: 3dB; range: 0 ... 5 dB, step 0.2 dB
Bit Rate Allocation
70 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Packet Scheduling• Overview
• Packet Transfer States & Parameters• Bitrate Allocation• Capacity Request & Traffic Volume Measurements • Channel Type Selection• Processing a Capacity Request• Packet Scheduler Interuption Timer
• Bitrate Upgrade
• Overload Control
• Dynamic Link Optimisation (DyLo)
• Activation Time optimization
71 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Dynamic Link Optimisation(DyLo) for NRT Traffic Coverage
BTS
UE384kbps
128kbps
Improved NRT traffic coverage
distanceRadio link is modified to use lower
bit rate when WBTS Tx power is getting close to maximum
72 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Triggering of Dynamic Link Optimisation
time
Ptx, RLdistance
Ptx, ave
Triggering of DyLO
Ptx, maxOffset
Ptx, ave is averaged radio link power, measured and reported to RNC by BTSPtx, max is determined by admission control
The value of the Offset is fixed, 2 dB
Dynamic link optimisationis triggered if
Ptx, ave > Ptx, max - Offset
73 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Decision algorithm
Triggering of DyLO
DyLO is not possible during compressed mode
DyLO is possible for NRT DCH allocations that have lasted at least 2 seconds (fixed guard time)
Not applicable in RAN1.5 (only 1 NRT DCH possible per UE)
• SF is doubled (physical channel bit rate reduced to half of the original)
• Additional puncturing is not allowed• DyLO cannot reduce bit rate below the Initial and
minimum allowed bit rate in downlink (RAN1.5.2ED CD19)
• DyLO can be started only if the current bit rate is higher than Maximum Allowed DL User Bitrate in HHO (enable compressed mode due to DL power)
74 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
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 only• Cell level parameter Initial and minimum allowed bit rate in
downlink is configurable by operator• Bit rate upgrade from any other bit rate is not possible• Bit rate upgrade is based on downlink traffic volume measurement
reports (capacity requests)• The change of the radio link power conditions does not trigger
upgrade• Possible triggering of the DyLO is checked before the bit rate is
upgraded, in order to avoid ping-pong effect (RAN1.5.2ED2)• New Ptx, max is calculated by AC according to the new bit rate• Initial Tx power Ptx, init is calculated by AC according to the new
bit rate• DyLO is possible if Ptx, init < (Ptx, max – Offset)• If inequality is not valid, the next lower bit rate is tried
Fixed, 2 dB
75 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
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.Range and Step: -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).Range and Step: -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.Range and Steps; 8, 16, 32, 64, 128, 256, 320, 384Default: 64 kbps (RAN1.5)
32 kbps (RAN04)
• 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.Range and Steps: 32, 64, 128, 256, 384Default; 64 kbps (RAN1.5)
32 kbps (RAN04)
76 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Related Parameters – fixed• Dynamic link optimisation usage
• Always used
• Downlink transmission power offset for dynamic link optimisation• 2 dB
• Guard time for dynamic link optimisation• 2 s
77 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Restrictions• Radio link under DRNC
• Radio link under DRNC cannot trigger DyLO
• Compressed mode• DyLO is not allowed during the compressed mode measurements
• Dylo can be started only if the current bit rate is higher than Maximum Allowed DL User Bitrate in HHO (enable compressed mode due to DL power). Parameter minimum value is 32 kbps. So this parameter actually defines absolute minimum bitrate where DyLo can downgrade, even if the parameter MinAllowedBitRateDL has lower (8 or 16 kbps) value
=> if parameter HhoMaxAllowedBitrateDL > MinAllowedBitRateDL, DyLo never reach value set by parameter MinAllowedBitRateDL which it should reach before upgrade procedure can start =>upgrade is not happening
AAL2 resource modification is supported from RAN04 + CD2 on !
78 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Bitrate Upgrade Possibilities in Nokia RAN
SF32(64k) SF8(384k) SF16(128k) CELL-FACH SF32(64k) SF8(384k) ○
Example: Max Bitrate 384kbps, Initial Bitrate 64kbps
Inactivity timers trigger release of resources
Bitrate[kbps]
time
RB setup32
64
128
384
Capacity Request DyLO triggered
Lightweight Flexible Upgrade feature active-Bitrate upgrade if sufficient resources available –
Maximum Bitrate > Allocated bitrate > InitialandMinAllowedBitrate
Capacity Request triggered from LFU feature
After RN2.0 CD3.0
Bitrate downgradeDue to DyLo
79 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Example DyLO scheme 1: PtxDLabsMax 50 dBm, PtxTotalMax 43dBmDL
pw
r(dB
m)
PtxTotalMax 43dBm
PtxPrimaryCPICH 33dBm
PtxPrimaryCPICH – CPICHtoRefRABoffset = 31 dBm
PtxDLabsMax 50 dBm
Calculated max RL pwrCalculated max RL pwr - DLOptimisationPwrOffset
• This is where DyLO triggers. (If PtxDLabsMax is set high)
Default hidden value is 2dB
reftxP ,
max,txP
Ptx, threshold
(Existing WBTS Parameter PtxTotalMax (maximum total BTS power) is deleted)
80 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Example DyLO scheme 2: PtxDLabsMax 38 dBm, PtxTotalMax 43dBmDL
pw
r(dB
m)
PtxTotalMax 43dBm
PtxPrimaryCPICH 33dBm
PtxPrimaryCPICH – CPICHtoRefRABoffset = 31 dBm
PtxDLabsMax 38 dBm
Calculated max RL pwr
PtxDLabsMax - DLOptimisationPwrOffset = 36 dBm
• PtxDLabsMax is reduced from 50dBm to 38dBm•This is where DyLO now triggers.
max,txP
reftxP ,
Ptx, threshold
81 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Packet Scheduling• Overview
• Packet Transfer States & Parameters• Bitrate Allocation• Capacity Request & Traffic Volume Measurements • Channel Type Selection• Processing a Capacity Request• Packet Scheduler Interuption Timer
• Bitrate Upgrade
• Overload Control
• Dynamic Link Optimisation (DyLo)
• Activation Time optimization
82 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Activation Time
• Activation time length is defined as a sum:
ActivationTime = ActivationTimeOffset + SignalingDelayOffset
• ActivationTimeOffset (Range: 0..2550 ms, step 10 ms) It represents the processing delay of RNC and BTS. It is function of timer_poll and includes RLC retransmissions
• The SignalingDelayOffset is RNC internal parameter that implies a required offset based on e.g. the SRB bit rate, the actual procedure and the lenght of a RRC message
• Call Setup time can be improved by tuning the parameter ActivationTimeOffset since it affects the behavior of Radio Bearer Setup and Radio Bearer Reconfiguration procedures
83 © NOKIA RANPAR Version 2.0 / 02.2006 / rlim
Activation Time improvement in RAN04
Service SRB3,4 SRB13,6
SDO in RAN04 CD2.1
AMR 320 80
CS 160 40
NRT PS 320 80
ATO recommended in RAN04 GCD3.0
All the services
700 700
20660NRT PS
ATO recommended in RAN04 GCD3.0
SRB13,6SRB3,4Service
300300All the services
0500CS
20660AMR
SDO in RAN04 GCD3.0
Activation time for AMR:SRB3.4: 320+700 = 1020 msSRB13.6: 80+700 = 780 ms
• In RAN04 the Activation Time is optimized from GCD3.0 on due to the shorter duration of the Activation Time Offset
Activation time for AMR:SRB3.4: 660+300 = 960 msSRB13.6: 20+300 = 320 ms
Call Setup delay
improved in 0.5 sec for SRB13.6!!
top related