06_PacketScheduling_2004
-
Upload
hosnan-fath -
Category
Documents
-
view
4 -
download
1
description
Transcript of 06_PacketScheduling_2004
1 © NOKIA 31/10/2003 RANPAR Version 1.0
Course Content
• Radio Resource Management Overview
• Parameter Configuration
• Common Channels & Power Control
• Load Control
• Admission Control
• Packet Scheduling
• Handover Control
• Resource Manager
2 © 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
3 © NOKIA 31/10/2003 RANPAR Version 1.0
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)
4 © NOKIA 31/10/2003 RANPAR Version 1.0
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 31/10/2003 RANPAR Version 1.0
Why Packet Scheduling?It is characteristic for RT traffic that it’s load cannot be controlled in efficient way. Load caused by RT
traffic, interference from other cell users and noise together is called non-controllable load. The available capacity, which is not used by non-controllable load, can be used for NRT radio bearers on best effort basis. To fill the whole load budget and achieve the maximum capacity, the allocation of NRT traffic needs to be fast.
The Packet scheduler is a general feature, which takes care of scheduling radio resources for NRT radio bearers for both uplink and downlink directions; Packet scheduling happens periodically (with the period of tens of milliseconds) and is implemented for both dedicated (DCH) and common control transport channels (RACH/FACH).
Scheduled capacity depends on the UE capabilities, Node B capabilities, current load of the cell as well as the availability of the physical radio resources.
Packet scheduler and MAC layer together make the decision of the used channel type for downlink direction, data transmission on dedicated channel is initiated when MAC layer requests transmission capacity
For uplink direction the decision of the used channel type is based on UE measurements and parameters controlled by network. Data transmission on dedicated channels is initiated when a capacity request is received from UE.
The selection of the channel type is done fast - taking into account the data amount in the buffers and the current radio conditions
6 © NOKIA 31/10/2003 RANPAR Version 1.0
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
7 © NOKIA 31/10/2003 RANPAR Version 1.0
Packet Scheduling Principles
Power/ Load
time
non-controllable loadi.e. RT Traffic
controllable loadi.e. non RT Traffic
PtxTotal (variable) PrxTotal
PtxNrt PrxNrt
PtxTarget PrxTarget
PtxOffset PrxOffset
PtxTargetBTS PrxTargetBTS
overload
DesiredPrx/PtxValues
PtxRt PrxRt
8 © NOKIA 31/10/2003 RANPAR Version 1.0
Supported Radio Bearers in RANRAN1.5.1RAN1.5.1RAN1.5.1RAN1.5.1RAN1.5.1RAN1.5.1RAN1.5.1RAN1.5.1RAN1.5.1RAN1.5.1RAN1.5.1RAN1.5.1 RAN1.5.2ED2RAN1.5.2ED2RAN1.5.2ED2RAN1.5.2ED2RAN1.5.2ED2RAN1.5.2ED2RAN1.5.2ED2RAN1.5.2ED2RAN1.5.2ED2RAN1.5.2ED2RAN1.5.2ED2RAN1.5.2ED2 RAN’04RAN’04RAN’04RAN’04RAN’04RAN’04RAN’04RAN’04RAN’04RAN’04RAN’04RAN’04 RAN’05RAN’05RAN’05RAN’05RAN’05RAN’05RAN’05RAN’05RAN’05RAN’05RAN’05RAN’05 RAN’06RAN’06RAN’06RAN’06RAN’06RAN’06RAN’06RAN’06RAN’06RAN’06RAN’06RAN’06
AMR = Conversational CS speechTransparent CS data = Conversational CS dataNon-transparent CS data = Streaming CS dataNRT PS data = Interactive/Background PS data
Implementation of Nokia RAN shall support asymmetric combinations with all bit rates. The combinations supported by terminals are verified in system verification and inter-operability testing between Nokia RAN and Nokia & third party terminals.
AMR AMR AMR AMR 12.212.212.212.2AMR AMR AMR AMR 12.212.212.212.2
TransparentTransparentTransparentTransparent CS data CS data CS data CS data 64646464TransparentTransparentTransparentTransparent CS data CS data CS data CS data 64646464
NonNonNonNon----transparenttransparenttransparenttransparent CS data CS data CS data CS data 57.657.657.657.6NonNonNonNon----transparenttransparenttransparenttransparent CS data CS data CS data CS data 57.657.657.657.6
NRT PS data NRT PS data NRT PS data NRT PS data UL:64, DL(64,128,384)UL:64, DL(64,128,384)UL:64, DL(64,128,384)UL:64, DL(64,128,384)NRT PS data NRT PS data NRT PS data NRT PS data UL:64, DL(64,128,384)UL:64, DL(64,128,384)UL:64, DL(64,128,384)UL:64, DL(64,128,384)
NonNonNonNon----transparenttransparenttransparenttransparent CS dataCS dataCS dataCS data 14.414.414.414.4NonNonNonNon----transparenttransparenttransparenttransparent CS dataCS dataCS dataCS data 14.414.414.414.4
AMR AMR AMR AMR 10.2, 7.95, 7.40, 6.70, 5.90. 5.15, 4.7510.2, 7.95, 7.40, 6.70, 5.90. 5.15, 4.7510.2, 7.95, 7.40, 6.70, 5.90. 5.15, 4.7510.2, 7.95, 7.40, 6.70, 5.90. 5.15, 4.75AMR AMR AMR AMR 10.2, 7.95, 7.40, 6.70, 5.90. 5.15, 4.7510.2, 7.95, 7.40, 6.70, 5.90. 5.15, 4.7510.2, 7.95, 7.40, 6.70, 5.90. 5.15, 4.7510.2, 7.95, 7.40, 6.70, 5.90. 5.15, 4.75
TransparentTransparentTransparentTransparent CS data CS data CS data CS data 33.6, 32, 28.833.6, 32, 28.833.6, 32, 28.833.6, 32, 28.8TransparentTransparentTransparentTransparent CS data CS data CS data CS data 33.6, 32, 28.833.6, 32, 28.833.6, 32, 28.833.6, 32, 28.8
NRT PS data NRT PS data NRT PS data NRT PS data 8, 16, 328, 16, 328, 16, 328, 16, 32NRT PS data NRT PS data NRT PS data NRT PS data 8, 16, 328, 16, 328, 16, 328, 16, 32
StreamingStreamingStreamingStreaming PS data PS data PS data PS data UL/DL(8, 16, 32, 64, 128), DL:256UL/DL(8, 16, 32, 64, 128), DL:256UL/DL(8, 16, 32, 64, 128), DL:256UL/DL(8, 16, 32, 64, 128), DL:256StreamingStreamingStreamingStreaming PS data PS data PS data PS data UL/DL(8, 16, 32, 64, 128), DL:256UL/DL(8, 16, 32, 64, 128), DL:256UL/DL(8, 16, 32, 64, 128), DL:256UL/DL(8, 16, 32, 64, 128), DL:256
NRT PS data NRT PS data NRT PS data NRT PS data 256256256256NRT PS data NRT PS data NRT PS data NRT PS data 256256256256
ConversationalConversationalConversationalConversational PS PS PS PS QoSQoSQoSQoS is a is a is a is a study itemstudy itemstudy itemstudy itemin RAN’06in RAN’06in RAN’06in RAN’06
ConversationalConversationalConversationalConversational PS PS PS PS QoSQoSQoSQoS is a is a is a is a study itemstudy itemstudy itemstudy itemin RAN’06in RAN’06in RAN’06in RAN’06
9 © NOKIA 31/10/2003 RANPAR Version 1.0
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)
10 © NOKIA 31/10/2003 RANPAR Version 1.0
RRC Modes with Parameters
Release RRCConnection
Release RRCConnection
URA_PCH
CELL_DCH CELL_FACH
CELL_PCH
Establish RRCConnection
UTRA RRC Connected Mode
Idle Mode
(UE camps on UTRAN cell)
Available in RAN1.5.2ED2
Available in RAN’04
cellUpdate, UL Tx
UL_DL_activation_timer
#cellUpdates
UL Tx
UL_DL_activation_timer(workaround)
DRX DRX
Tx/RxinactivityTimer
Tx/Rx FACH/RACH
trafficVolume
Release RRCConnection
Release RRCConnection
URA_PCH
CELL_DCH CELL_FACH
CELL_PCH
Establish RRCConnection
UTRA RRC Connected Mode
Idle Mode
(UE camps on UTRAN cell)
Available in RAN1.5.2ED2
Available in the future
cellUpdate, UL Tx
UL_DL_activation_timer
#cellUpdates
UL Tx
UL_DL_activation_timer(workaround, in RAN1.5.2 ED)
DRX DRX
Tx/RxinactivityTimer
Tx/Rx FACH/RACH
trafficVolume
11 © NOKIA 31/10/2003 RANPAR Version 1.0
RRC Modes and Packet SchedulingThe packet access procedure in WCDMA should keep the interference caused to other users as small as
possible.Since there is no connection between the base station and the UE before the access procedure, initial
access is not closed loop power controlled and thus the information transmitted during this period should be kept at minimum.
There are three scenarios for WCDMA packet access: • infrequent transmission of small packets• frequent transmission of small packets and• transmission of large packetsPacket data transfer in WCDMA can be performed using common or dedicated transport channels.
Since the establishment of a dedicated transport channel itself requires signalling and thus consumes radio resources, it is reasonable to transmit infrequent and small NRT user data packets using common transport channels without closed loop power control.Then the random access channel (RACH) in uplink and the forward access channel (FACH) in downlink are the transport channels used for packet access
When the packet data is transferred on common channels, the UE is in CELL_FACH state.Large or frequent user data blocks are transmitted using dedicated transport channels (DCH).When the packet data is performed on dedicated channels, the UE is in CELL_DCH state.
12 © NOKIA 31/10/2003 RANPAR Version 1.0
PS Connection EstablishmentIn the RRC connection setup procedure the UE is always transferred directly to CELL_DCH state in RAN1 (see previous slide).
The RRC connection setup and “a service establishment” for NRT RAB(s) is performed as follows:•After the UE has completed a RRC Connection setup procedure with the RNC, dedicated channel resources are allocated to the UE (a DCH for the signalling link is setup).
•The UE performs a NAS connection establishment to the PS CN.•After the service negotiation has been carried out between the UE and PS CN, the PS CN sends a RAB assignment to the RNC.
•The RNC’s RRC signalling entity performs a radio bearer setup with a RRC:Radio Bearer Setupprocedure.
The traffic volume measurement parameters (RLC buffer level, reporting criteria, etc.) are sent to the UE by using a RRC:Measurement Control procedure
•Based on this information the UE is able report the need of UL capacity (request the allocation of the DCH) by sending a RRC:MEASUREMENT REPORT message to the RNC
The RNC’s RRC signalling entity starts a supervision timers RB_InactivityTimer and SignallingLinkInactivityTimer
If the capacity request is received from the UE or from the RNC’s within the RB_InactivityTimer, the DCH for NRT RB(s) is allocated.
If there is no activity in RB(s) within the RB_InactivityTimer and the inactivity of signalling link is detected (‘SignallingLinkInactivityTimer’ has also expired), the state transition from CELL_DCH to CELL_FACH is initiated
13 © NOKIA 31/10/2003 RANPAR Version 1.0
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 31/10/2003 RANPAR Version 1.0
Transition from CELL_DCH to CELL_FACHThe UE connection can be moved from dedicated channel (CELL_DCH state) to common channel (CELL_FACH state) either through the expiration of an inactivity timer or via explicit signalling
At the beginning of the transition from CELL_DCH to CELL_FACH state the cell must be selected (or RNC can allow the UE make cell selection)
•The cell can be the same cell where the MS was in CELL_DCH state.•If the MS had also soft/softer HO branches then so-called reference (=the best) branch is used for the cell selection (or the RNC can command MS to make cell selection).
•The RNC's RRC signalling includes the latest known ‘Main Cell (Cell-ID)’ information in to the RRC message (i.e. RRC: RADIO BEARER RECONFIGURATION). Only the Cell-IDs of SRNC are used.
The inactivity timers for uplink and downlink are RNC configuration parameters InactivityTimerUplinkDCH and InactivityTimerDownlinkDCH.
When UE is in CELL_DCH state the UL and DL data streams are monitored by the RNC.•In case the RNC detects inactivity (nothing sent or received), it will indicate this to the RRM and RRC signalling entities of the RNC.
After receiving the inactivity indication, the RRC signalling entity defines and starts an inactivity timer (InactivityTimerUplinkDCH or InactivityTimerDownlinkDCH).
(continued)
15 © NOKIA 31/10/2003 RANPAR Version 1.0
Transition from CELL_DCH to CELL_FACHAfter the inactivity timer expires the RRC radio bearer reconfiguration–procedure is performed.RRC sends an RRC: RADIO BEARER RECONFIGURATION message to the UE.UE acknowledges by sending the RRC: RADIO BEARER RECONFIGURATION COMPLETE –message to the RRC signaling entity of the RNC
•which starts L2 reconfiguration (as well as PS is informed about the cell state change).
Radio link and AAL2 resources are then released and UE is changed to CELL_FACH state.
In case the UE is having RT RB which has become inactive and at the same time it is having inactive NRT RB then RADIO BEARER RELEASE procedure is used (instead of RADIO BEARER RECONFIGURATION).
16 © NOKIA 31/10/2003 RANPAR Version 1.0
Transition from CELL_DCH to CELL_FACH
RNCUECELL_DCH Node B
PDU Transport on the DCH/DPCH
All data is sent andRLC-U buffer is empty
Inactivity detected Start
InactivityTimerUplinkDCHInactivityTimerDownlinkDCH
Radio Bearer Reconfiguration
Radio Bearer Reconfiguration Complete
ExpiryCELL_FACH
L2 configuration
Radio Bearer Release
StartMAC: Inactivity detected
UL/DL activation timer
17 © NOKIA 31/10/2003 RANPAR Version 1.0
Transition from CELL_FACH to CELL_PCHCELL_FACH state is entered, by transition from URA_PCH state, by transition from CELL_PCH state or by transition from CELL_DCH state. In CELL_FACH state the MS performs the following actions:
• Performs (FDD intra-frequency) measurements and cell reselections• Listens all FACH transport channels on the selected S-CCPCH (Secondary Common
Control Physical Channel)Since the MS performs continuous reception of FACH in CELL_FACH state, it should be moved to the CELL_PCH state if the data service has not been active for a while.
This state transition is done when the RNC’s RRC timer UL/DL activation timer expires.• This timer is started when the RNC's MAC entity for MS indicates observed inactivity in
UL and DL direction.• Also, the state transition from CELL_FACH to CELL_PCH is done immediately after
successful Cell Update procedure due to 'cell reselection' or 'periodic cell update' in case the UE was in CELL_PCH before executing Cell Update procedure.
(continued)
18 © NOKIA 31/10/2003 RANPAR Version 1.0
The RNC's RRC signaling entity counts the number of cell reselections and number of periodic cell updates while the UE is in CELL_FACH state or CELL_PCH state.
If number of cell reselections exceeds a threshold value MaxCellReselections within timer CellReselectionObservingTime then the RNC's RRC signaling entity will command the UE to change its state after cell update procedure from CELL_FACH state to URA_PCH state instead of CELL_PCH state.
If the number of periodic cell updates exceeds MaxPeriodicalCellUpdates then the UE is ordered to change the state to URA_PCH.
The state change happens via normal cell updating procedure (in response to CELL UPDATE message i.e. CELL UPDATE CONFIRM message).
When the UE is transferred to CELL_PCH/URA_PCH state, the RNC’s RRC signaling entity shall start a state supervision timer MSActivitySupervision.
The RRC signaling entity stops the state supervision timer when state transition from CELL_PCH/URA_PCH state is initiated. The state supervision timer is reset when a periodic Cell Update is received and a RRC:CELL UPDATE CONFIRM message is sent to the UE.
After expiry of the supervision timer (no periodic Cell Update received from the UE, or any other UL activity detected) all reserved resources for this UE are released.
RRC State Transitions
19 © NOKIA 31/10/2003 RANPAR Version 1.0
Transition from CELL_FACH to ...
StartMAC: Inactivity detected
UL/DL activation timer
UECELL_FACH
CELL_FACH Cell Update
Cell UpdateCell Update Confirm
URA_PCH
MaxCellReselectionsCellReselectionObservingTimeandMaxPeriodicalCellUpdates
Start
Expiry
Expiry
RNC
analog inCELL_PCH
URA Update
URA UpdateURA Update Confirm
Inactivity detected
Transition to URA_PCH
MSActivitySupervision
URA_PCH
RRC-IDLE
CELL_PCH Radio Bearer Reconfiguration
20 © NOKIA 31/10/2003 RANPAR Version 1.0
The UE connection can be moved from common channel (CELL_FACH state) to dedicated channel (CELL_DCH state) if RNC has data waiting for the transmission in downlink or UE requests dedicated uplink capacity.
In uplink direction the need for the capacity is detected by the MAC of UE.UE makes the decision whether the common or dedicated channel type is used in uplink.UE requests dedicated capacity by sending an RRC: MEASUREMENT REPORT message on RACH to the
RRC signaling entity of RNC, which forwards the message to the RRM.After the procedure, data transmission on DCH can begin and UE is in CELL_DCH state.
In downlink direction the capacity need is detected by the UE MAC entity of RNC. It sends downlink capacity request directly to RRM.
After uplink and downlink packet scheduling, due to Uplink or Downlink capacity request PS requests resources from the RM.
PS requests the RRC signaling entity of RNC to start transport channel reconfiguration –procedure• The RRC signaling entity sends an RRC: TRANSPORT CHANNEL RECONFIGURATION message to
the UE on FACH, which is acknowledged with an RRC: TRANSPORT CHANNEL RECONFIGURATION COMPLETE
After the procedure, data transmission on DCH can begin and UE is in CELL_DCH state.
Transition from CELL_FACH to CELL_DCH
21 © NOKIA 31/10/2003 RANPAR Version 1.0
Transition from CELL_FACH to CELL_DCH
RNCUECELL_FACH Node B
UL & DL packet scheduling
Radio Bearer Reconfiguration
Measurement Report (Traffic Volume Event)
CELL_DCH
Radio Link Setup
Radio Bearer Reconfiguration Complete
UE initiated
22 © NOKIA 31/10/2003 RANPAR Version 1.0
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
23 © NOKIA 31/10/2003 RANPAR Version 1.0
Nokia ParametersRB_InactivityTimer• The timer is set after a DCH for a signaling link is allocated in RRC connection setup phase.
The timer is reset when any DL/UL activity detected (i.e. capacity request received from the MS or RNC's MAC-c). In expiry of the timer, the state transition from CELL_DCH to CELL_FACH is initiated when also the SignallingLinkInactivityTimer has expired.default value: 2s; range: 0 ... 20 s; step 0.5 s
SignallingLinkInactivityTimer• The timer is used for inactivity detection of the signaling link in CELL_DCH and CELL_FACH
states. The timer is set after inactivity of the signaling link is detected and reset when any activity detected. In expiry of the timer, a state transition from CELL_DCH to CELL_FACH (or from CELL_FACH to CELL_PCH) state is initiated when also the corresponding RB inactivity timer(s) expired. default value: 2s; range: 0 ... 20 s; step 0.5 s
24 © NOKIA 31/10/2003 RANPAR Version 1.0
Nokia ParametersInactivityTimerUplinkDCH• The time indicating how long the radio and transmission resources are reserved after silence
detection on uplink DCH before release proceduresrange: 8 kbps: 5 s, 16 kbps: 5 s, 32 kbps: 5 s, 64 kbps: 3 s, 128 kbps: 2 s, 256 kbps: 2 s, 320 kbps: 2 s, 384 kbps: 2 s
InactivityTimerDownlinkDCH• The time indicating how long the radio and transmission resources are reserved after silence
detection on downlink DCH before release proceduresrange: 8 kbps: 5 s, 16 kbps: 5 s, 32 kbps: 5 s, 64 kbps: 3 s, 128 kbps: 2 s, 256 kbps: 2 s, 320 kbps: 2 s, 384 kbps: 2 s
• Recommendation is to use 20 s for all services
25 © NOKIA 31/10/2003 RANPAR Version 1.0
Nokia ParametersUL/DL activation timer• This timer is set when the MS is transferred to CELL_FACH state due to inactivity, or MS
inactivity is detected in CELL_FACH state (CELL_FACH-> IDLE)default value: : 2s; Recommendation is to set this to 10srange: 50 ... 10000 ms; step 50 ms
MSActivitySupervision• The RNC supervises traffic of MS with only NRT RABs. When no data transfer is performed
during the defined time period, the RNC asks SGSN to release Iudefault value: 30 min; range: 0 ... 1440 min; step 1 min
26 © NOKIA 31/10/2003 RANPAR Version 1.0
Nokia ParametersCellReselectionObservingTime• Detailed description: The timer is set when first Cell Update message due to 'cell
reselection' is received while MS is in CELL_FACH or CELL_PCH state. In expiry of the timer, the counter MaxCellReselections is reset.default value: 10s; range: 0 ... 60 s; step 1 s
MaxCellReselections• The number of Cell Reselections in CELL_FACH or CELL_PCH state during
CellReselectionObservingTime before transition to URA_PCH state.default value: 3 times; This is set to 0 in RAN1.5.2ED2, cannot be changedrange: 0 ... 100 times; step 1 times
MaxPeriodicalCellUpdates• Counter for a number of Periodical Cell Updates in CELL_FACH or CELL_PCH state before
transition to URA_PCH statedefault value: 1 time; range: 0 ... 10 times; step 1 times
27 © NOKIA 31/10/2003 RANPAR Version 1.0
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
28 © NOKIA 31/10/2003 RANPAR Version 1.0
Cell_PCH
Cell_FACH
IdleMode
URA_PCH
Cell_DCH
RRC State TransitionExercise: Add parameters to all transitions!!!!
29 © NOKIA 31/10/2003 RANPAR Version 1.0
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)
30 © NOKIA 31/10/2003 RANPAR Version 1.0
• In uplink direction the current total received interference power of a cell (PrxTotal) can be expressed as the sum of the non-controllable power (PrxNc) and the controllable power (PrxNrt).
• PrxNc consists of the powers of real-time users, other-cell users and noise.• PrxNrt consists of the powers influenced by PS
• In downlink direction the current total transmitted power of a cell (PtxTotal) can be expressed as the sum of the non-controllable power (PtxNc) and the controllable power, which is caused by NRT traffic (PtxNrt).
• The controllable power is used for NRT users on best effort basis by the packet scheduler.• The power available for best effort NRT traffic is the load target subtracted by the non-
controllable power.
• The bit rate allocation algorithm includes load increase and load decrease algorithms, which are the same in both uplink and downlink directions
nrtrxncrxtotalrx PPP ___ +=
nrttxnctxtotaltx PPP ___ +=
Power Budget for Packet Scheduling
31 © NOKIA 31/10/2003 RANPAR Version 1.0
Decrease loadingIncrease loading
Bit rate allocation algorithm
PrxTotal < PrxTarget NOYES
PrxTotal <PrxTarget + PrxOffsetYES
Allocate bit rates
end
NO
Calculate PrxAllowed
Bit Rate Allocation - Overview
nrtrxncrxtotalrx PPP ___ +=
non-controllable power
controllable power
inactivertrxinactivenrtrx
totalrxettrxallowedrx
PPPPP
____
_arg__
−−
−=
estimated received power of admitted RT bearers still in the in the establishment phase
estimated received power of RT admitted but currently inactive bearers
Example: UL
32 © NOKIA 31/10/2003 RANPAR Version 1.0
• In first phase PrxAllowed and PtxAllowed must be calculated by using:
where• PrxRtInative is the estimated received power of admitted RT bearers, which are not active yet
because establishment phase is still ongoing.• PrxNRTInative is the estimation of the the received power that inactive bearers would cause
when they are active.
• In the second phase the PrxTotal is compared to the PrxTarget and PtxTotal to PtxTarget• In case PrxTotal < PrxTarget then loading in UL is increased• In case PtxTotal < PtxTarget then loading in DL is increased
In case above two cases are full-filled either bitrate of existing NRT users is increased or new NRT user will get allocated bitrate.
• In case PrxTotal > PrxTarget then next checking is performed PrxTotal < PrxTarget + PrxOffset• In case PtxTotal > PtxTarget then next checking is performed PtxTotal < PtxTarget + PtxOffset
inactivertrxinactivenrtrxtotalrxettrxallowedrx PPPPP _____arg__ −−−=
inactiverttxinactivenrttxtotaltxetttxallowedtx PPPPP _____arg__ −−−=
Bit Rate Allocation - Overview
33 © NOKIA 31/10/2003 RANPAR Version 1.0
• Packet scheduling is done on a per-cell basis.
• Since asymmetric traffic is supported and the load may vary a lot between uplink and downlink, capacity is allocated separately for both directions
• When DCH is allocated to one direction, it also has to be allocated to the other direction as well even if there is no user data to be sent
• PS allocates low data rate to the DCH in "idle" direction for higher layer acknowledgements (TCP acknowledgements), L2 acknowledgements, L2 control and power control
• This low bit rate channel is called "return channel“.• Minimum allowed bit rate is the bit rate allocated for return channel.• The RNC configuration parameters MinAllowedBitRateUL and MinAllowedBitRateDL define the
bit rate that is allocated for return channel.
• PS operates periodically (same actions are repeated within a specified period).• This period is an RNC configuration parameter called SchedulingPeriod.• The scheduling period is normally the period between two cell based load information
messages received from LC (radio resource indication period, RRIndPeriod), but different value can also be configured.
Packet Scheduling Principles
34 © NOKIA 31/10/2003 RANPAR Version 1.0
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
35 © NOKIA 31/10/2003 RANPAR Version 1.0
• Averaged PrxTotal and PtxTotal values are used by PS.
• PSAveragingWindowSize is a BTS specific RNC configuration parameter that defines how many PrxTotal/PtxTotal measurements, which are received in the NBAP: RADIO RESOURCE INDICATION –messages, are included in the sliding window used in averaging of PS
• PrxTotal used in PS estimations is averaged using the following formula:
nntPtPtP
P totalrxtotalrxtotalrxtotalrx
))1((...)1()( ____
−−++−+=
• where Prx_total(t) is the latest received PrxTotal measurement and n equals to PSAveragingWindowSize
• PtxTotal is averaged same way
Packet Scheduling and Load Control
n = PSAveragingWindowSize
36 © NOKIA 31/10/2003 RANPAR Version 1.0
Parameters for Packet SchedulingMinAllowedBitRateUL• This parameter defines the minimum allowed bit rate in uplink that can be allocated by the
PS.default value: 8 kbps; range: 8 kbps, 16 kbps, 32 kbps, 64 kbps, 128 kbps, 256 kbps, 384 kbps
MinAllowedBitRateDL• This parameter defines the minimum allowed bit rate in downlink that can be allocated by
the PS. default value: 32 kbps; range: 8 kbps, 16 kbps, 32 kbps, 64 kbps, 128 kbps, 256 kbps, 384 kbps
• In RAN1.5.2 MinAllowerBitrateUL is always 64 kbits/s and MinallowedbitrateDL can be 64,128 or 384 kbits/s
37 © NOKIA 31/10/2003 RANPAR Version 1.0
Parameters for Packet SchedulingSchedulingPeriod• This parameter defines how often the packet scheduler makes scheduling decisions, and
when it can start doing allocations.default value: 200 ms; range: 100 ... 2000 ms, step 100 ms
• Note: The value of the scheduling period should be set longer than (or equal) the Radio Resource Indication period (RRIndPeriod) in order to have the latest load information available for packet scheduling.
RRIndPeriod• The parameter defines the reporting period of the Radio Resource Indication messages,
which are used for cell based load measurements.default value: 200 ms; range: 0 ... 2000 ms, step 100 ms.
• With the Radio Resource Indication message the BTS reports periodically the total uplink interference power of the cells and the total transmitted power of the cell and RACH.
38 © NOKIA 31/10/2003 RANPAR Version 1.0
PSAveragingWindowSize• The parameter defines how many PrxTotal/PtxTotal measurements, which are received in
the NBAP: RADIO RESOURCE INDICATION - messages, are included in the sliding window averagingdefault value: 5; range: 1 ... 20 , step 1
Parameters for Packet Scheduling
Individual Measurement Values 4 1 3 5 7 10 6Averaging Window Size = 3 5.0 7.3 7.7Averaging Window Size = 4 4.0 6.3 7.0Averaging Window Size = 5 4.0 5.2 6.2
39 © NOKIA 31/10/2003 RANPAR Version 1.0
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)
40 © NOKIA 31/10/2003 RANPAR Version 1.0
• In the uplink direction the UE sends a traffic volume event trigger RRC measurement report to the RNC, if:
• the data amount in the RLC buffer exceeds/drops below TrafVolThresholdULLow, the UE sends a traffic volume measurement (used in the state CELL_FACH).
• the data amount in the RLC buffer exceeds/drops below TrafVolThresholdULHigh the UE sends a traffic volume measurement (used in the state CELL_DCH).
• the UE does not receive a DCH allocation or bit rate upgrade, it resends the traffic volume measurement after a time period defined by TrafVolPendingTimeUL
• RNC participates to the uplink channel type selection procedure by setting the relevant parameters to UE for traffic volume measurements, which are included in the RRC: MEASUREMENT CONTROL message. Given traffic volume events reported by the UE, the RNC can decide, whether a state transmission takes place.
UE is in CELL_FACH state• When data amount in RLC transmission buffer exceeds a threshold value, UE sends traffic volume
measurement report including 'RB identity' and 'RLC transmission buffer payload‘.• The lower threshold value, which sets the traffic volume measurement reporting criteria is a radio
network planning parameter (TrafVolThresholdULLow)• Traffic volume measurement report from UE is handled as uplink capacity request in RNC, which
means request for DCH allocation when DCH is not allocated and DCH bit rate upgrade request when low bit rate DCH is allocated.
• Uplink traffic volume measurement report is included in the RRC: MEASUREMENT REPORT message.
UL Traffic Volume Based RRC State Transition
41 © NOKIA 31/10/2003 RANPAR Version 1.0
UL Traffic Volume Based RRC State TransitionReporting event:
4A: Transport Channel Traffic Volume becomes larger than an absolute threshold
time
Transport ChannelTraffic Volume
(= UE Ruffer Load)
Thresholds
4A 4A 4A
RNCUEMeasurement Report (Traffic Volume Event)
UE in CELL_FACH: TrafVolThresholdULLow (128 Bytes)UE in CELL_DCH: TrafVolThresholdULHigh (1024 Bytes)
Measurement Report (Traffic Volume Event)TrafVolPendingTimeUL (2s)
4A 4AMeasurement
report has information about
currentUE buffer load
42 © NOKIA 31/10/2003 RANPAR Version 1.0
In the downlink the process is the same:• When the data amount in the RLC buffer exceeds TrafVolThresholdDLLow, the UE specific entity
within the RNC reports a traffic volume measurement.• When the amount in the RLC buffer exceeds TrafVolThresholdDLHigh the UE specific entity
within the RNC reports a traffic volume measurement.• If the UE does not receive a DCH allocation or bit rate upgrade, UE specific entity within the
RNC reports the traffic volume measurement after a time period defined by TrafVolPendingTimeDL again.
DL Traffic Volume Based RRC State Transition
43 © NOKIA 31/10/2003 RANPAR Version 1.0
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
44 © NOKIA 31/10/2003 RANPAR Version 1.0
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
45 © NOKIA 31/10/2003 RANPAR Version 1.0
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
46 © NOKIA 31/10/2003 RANPAR Version 1.0
Possible cases for packet scheduling function
Preconditions Postconditions
Channel allocation Channel allocation Case UE state
UL DL
Trigger UE state UL DL
1 Cell_FACH - - Data arrives to UE RLC buffer
data_amount < TrafVolThresholdULLow (ul capacity request not triggered)
Cell_FACH RACH FACH
2 Cell_FACH - - Data arrives to RNC RLC buffer
data_amount < TrafVolThresholdDLLow (dl capacity request not triggered)
Cell_FACH RACH FACH
Data transmission on common channels in CELL_FACH stateData transmission on common channels in CELL_FACH state
47 © NOKIA 31/10/2003 RANPAR Version 1.0
Preconditions Postconditions
Channel allocation Channel allocationCase UE state
UL DL
Trigger UE stateUL DL
3 Cell_FACH - -
Data arrives to UE RLC bufferTrafVolThresholdULLow
< data_amount < TrafVolThresholdULHigh(ul capacity request triggered )
Cell_DCH DCHlow
DCHlow
4 Cell_FACH - -
Data arrives to RNC RLC bufferTrafVolThresholdDLLow
< data_amount < TrafVolThresholdDLHigh(dl capacity request triggered)
Cell_DCH DCHlow
DCHlow
5 Cell_FACH - -Data arrives to UE RLC buffer
data_amount > TrafVolThresholdULHigh(ul capacity request triggered)
Cell_DCH DCHhigh
DCHlow
6 Cell_FACH - -Data arrives to RNC RLC buffer
data_amount > TrafVolThresholdDLHigh(dl capacity request triggered)
Cell_DCH DCHlow
DCHhigh
Channel switching from CELL_FACH to CELL_DCH stateChannel switching from CELL_FACH to CELL_DCH state
Possible cases for packet scheduling function
• 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).
48 © NOKIA 31/10/2003 RANPAR Version 1.0
Preconditions Postconditions
Channel allocation ChannelallocationCase UE state
UL DL
Trigger UE stateUL DL
7 Cell_DCH - -Data arrives to UE RLC buffer
data_amount < TrafVolThresholdULHigh(ul capacity request triggered)
Cell_DCH DCHlow
DCHlow
8 Cell_DCH - -Data arrives to RNC RLC buffer
data_amount < TrafVolThresholdDLHigh(dl capacity request triggered)
Cell_DCH DCHlow
DCHlow
9 Cell_DCH - -Data arrives to UE RLC buffer
data_amount > TrafVolThresholdULHigh(ul capacity request triggered)
Cell_DCH DCHhigh
DCHlow
10 Cell_DCH - -Data arrives to RNC RLC buffer
data_amount > TrafVolThresholdDLHigh(dl capacity request triggered)
Cell_DCH DCHlow
DCHhigh
DCH setup in CELL_DCH stateDCH setup in CELL_DCH state
Possible cases for packet scheduling function
49 © NOKIA 31/10/2003 RANPAR Version 1.0
Preconditions Postconditions
Channel allocation Channel allocation Case UE state
UL DL
Trigger UE state UL DL
11 Cell_DCH DCH low
DCH low
Data arrives to UE RLC buffer data_amount > TrafVolThresholdULHigh
(ul capacity request triggered) Cell_DCH DCH
high DCH low
12 Cell_DCH DCH low
DCH low
Data arrives to RNC RLC buffer data_amount > TrafVolThresholdDLHigh
(dl capacity request triggered) Cell_DCH DCH
low DCH high
13 Cell_DCH DCH low
DCH high
Data arrives to UE RLC buffer data_amount > TrafVolThresholdULHigh
(ul capacity request triggered) Cell_DCH DCH
high DCH high
14 Cell_DCH DCH high
DCH low
Data arrives to RNC RLC buffer data_amount > TrafVolThresholdDLHigh
(dl capacity request triggered) Cell_DCH DCH
high DCH high
DCH reconfiguration (bit rate upgrade) in CELL_DCH stateDCH reconfiguration (bit rate upgrade) in CELL_DCH state
Possible cases for packet scheduling function
50 © NOKIA 31/10/2003 RANPAR Version 1.0
TrafVolThresholdULLow• This parameter defines, in bytes, the threshold of data in the RLC buffer of RB that triggers
the uplink traffic volume measurement report, when the UE is in Cell_FACH state.
• Otherwise, UE sends data on RACH.
• This parameter is sent to the UE using an RRC: MEASUREMENT CONTROL message.
default value: 128 bytes; range: 8 bytes, 16 bytes, 32 bytes, 64 bytes, 128 bytes, 256 bytes, 512 bytes, 1024 bytes (1 KB)
TrafVolThresholdULHigh• The parameter defines the threshold of data in RLC buffer of RB in bytes.
• The parameter is sent to the UE using the RRC: MEASUREMENT CONTROL message.
default value: 1024 bytes; range: 8 bytes, 16 bytes, 32 bytes, 64 bytes, 128 bytes, 256 bytes, 512 bytes, 1024 bytes (1 KB), 2048 bytes (2 KB), 3072 bytes (3 KB), 4096 bytes (4 KB)
UL Traffic Volume Based RRC State Transition
51 © NOKIA 31/10/2003 RANPAR Version 1.0
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
52 © NOKIA 31/10/2003 RANPAR Version 1.0
TrafVolThresholdDLLow• This parameter defines, in bytes, the threshold of data in the RLC buffer of RB that triggers
the downlink traffic volume measurement report (capacity request) on MAC, when UE is in Cell_FACH state. Otherwise, RNC sends data on FACHdefault value: 128 bytes;range: 0 bytes, 8 bytes, 16 bytes, 32 bytes, 64 bytes, 128 bytes, 256 bytes, 512 bytes, 1024 bytes (1 KB)
TrafVolThresholdDLHigh• This parameter defines the threshold of data in the RLC buffer of RB in bytes which triggers
downlink traffic volume measurement report (capacity request) on MAC, when UE is in a Cell_DCH state and the initial bit rate DCH is allocated for the radio bearerdefault value: 1024 bytes;range: 0 bytes, 8 bytes, 16 bytes, 32 bytes, 64 bytes, 128 bytes, 256 bytes, 512 bytes, 1024 bytes (1 KB), 2048 bytes (2 KB), 3072 bytes (3 KB), 4096 bytes (4 KB)
DL Traffic Volume Based RRC State Transition
53 © NOKIA 31/10/2003 RANPAR Version 1.0
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
54 © NOKIA 31/10/2003 RANPAR Version 1.0
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)
55 © NOKIA 31/10/2003 RANPAR Version 1.0
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
56 © NOKIA 31/10/2003 RANPAR Version 1.0
FACH is in overload when FACH load exceeds FachLoadThresholdCCH. FACH usage is possible again when the FACH load is decreased under threshold by margin FachLoadMarginCCH.
FACH usage is forbidden by PS when RACH load exceeds RachLoadThresholdCCH or when PtxTotalexceeds PtxThresholdCCH. When one or both of the conditions are fulfilled, PS indicates that FACH usage is forbidden.
FACH usage is possible again when the RACH load and PtxTotal are decreased below thresholds set by margins RachLoadMarginCCH and PtxMarginCCH.
DL Traffic Type Selection
57 © NOKIA 31/10/2003 RANPAR Version 1.0
DL Traffic Type Selection
time
FACH overload FachLoadThresholdCCH/RachLoadThresholdCCH
FachLoadMarginCCH/RachLoadMarginCCH
FACH in overload
FACH usage ok
time
FACH forbidden
FACH in overload
FACH usage ok
PtxThresholdCCH
PtxMarginCCH
Load
Power / Load
58 © NOKIA 31/10/2003 RANPAR Version 1.0
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
59 © NOKIA 31/10/2003 RANPAR Version 1.0
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
60 © NOKIA 31/10/2003 RANPAR Version 1.0
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
61 © NOKIA 31/10/2003 RANPAR Version 1.0
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
62 © NOKIA 31/10/2003 RANPAR Version 1.0
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)
63 © NOKIA 31/10/2003 RANPAR Version 1.0
There are separate queues for uplink and downlink capacity request messages.
If the packet scheduler is not able to allocate capacity requests for every radio bearer, these un-full-filled requests remain in the queue.
There is a time limit how long the request can stay in the queue• This limit is set by using RNC configuration parameters CrQueuingTimeUL and
CrQueuingTimeDL, separately for uplink and downlink.• When the limit is exceeded for the certain capacity request, it is permanently
removed from the queue.• New capacity request is then required when allocation is needed for that bearer
CrQueuingTimeUL and CrQueuingTimeDL parameters are related to the parameters TrafVolPendingTimeUL and TrafVolPendingTimeDL, which define the time between consecutive capacity requests
• These parameters should be set accordingly
Processing of Capacity Request
64 © NOKIA 31/10/2003 RANPAR Version 1.0
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)
Processing of Capacity Request
CrQueuingTimeULCrQueuingTimeDL
based on• Arrival time• Bearer class• Traffic handling priority
CrHandlingPolicyULCrHandlingPolicyDL
65 © NOKIA 31/10/2003 RANPAR Version 1.0
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.
Processing of Capacity Request
66 © NOKIA 31/10/2003 RANPAR Version 1.0
CrQueuingTimeUL• This parameter defines how long an uplink capacity request can stay in the queue
before it is permanently removed.default value: 4 sec; range: 1 ... 30 sec; step 1 sec
• Note: This value should be the same as TrafVolPendingTimeUL
TrafVolPendingTimeUL• This parameter indicates the period of time, in seconds, during which it is forbidden
to send any new traffic volume measurement reports with the same measurement ID, even if the triggering condition is fulfilled again. Parameter is sent to UE using an RRC: SYSTEM INFORMATION or an RRC: MEASUREMENT CONTROL message.
default value 4000 ms; range: 250 ms, 500 ms, 1000 ms, 2000 ms, 4000 ms, 8000 ms, 16000 ms
• Note: This value should be set the same in all cells within a BTS
Processing of Capacity Request
67 © NOKIA 31/10/2003 RANPAR Version 1.0
CrQueuingTimeDL• This parameter defines how long an downlink capacity request can stay in the
queue before it is permanently removed.default value:4 sec; range: 1 ... 30 sec; step 1 sec
• Note: This value should be the same as TrafVolPendingTimeDL
TrafVolPendingTimeDL• This parameter indicates the period of time, in milliseconds, during which it is
forbidden to send any new downlink capacity requests with the same RB id, even if the triggering condition is fulfilled again.default value: 4000 ms; range: 250 ms, 500 ms, 1000 ms, 2000 ms, 4000 ms, 8000 ms, 16000 ms
• Note: This value should be set the same in all cells within a BTS
Processing of Capacity Request
68 © NOKIA 31/10/2003 RANPAR Version 1.0
CrHandlingPolicyUL• This parameter defines the criteria which are taken into account when the capacity
requests are arranged for DCH scheduling.
default value: 2
range: 1 (arrival time only), 2 (arrival time and bearer class), 3 (arrival time, bearer class and traffic handling priority)
CrHandlingPolicyDL• This parameter defines the criteria which are taken into account when the capacity
requests are arranged for DCH scheduling.
default value: 2range: 1 (arrival time only), 2 (arrival time and bearer class), 3 (arrival time,
bearer class and traffic handling priority)
Processing of Capacity Request
69 © NOKIA 31/10/2003 RANPAR Version 1.0
Packet Scheduling• Overview
• Packet Transfer States & Parameters• Bitrate Allocation• Channel Type Selection• Capacity Request & Traffic Volume Measurements • Processing a Capacity Request
• Bitrate Upgrade
• Overload Control
• Dynamic Link Optimisation (DyLo)
70 © NOKIA 31/10/2003 RANPAR Version 1.0
• In case PrxTotal < PrxTarget and/or PtxTotal < PtxTarget then the load increase algorithm will take place (UL and/or DL):First the Capacity Requests (CRs) in queue are checked and in case there are NRT CRsthey are first accepted in priority order. For each CR PrxTotalNew and PtxTotalNew, are calculated:
where: P_totalchange is the power change estimation.For each CR PrxNrtNew and PtxNrtNew are calculated based on the new or bitrateincrease (to be scheduled) radio bearer Eb/No requirement (bitrate requirement).
• Note : the upgrade will happen in the case of RLC buffer payload =>TrafVolThresholdDLHigh or TrafVolThresholdULHigh
Initial bitrate allocation & Bitrate upgrade
changetotalrxtotalrxnewtotalrx PPP _____ +=
changetotaltxtotaltxnewtotaltx PPP _____ +=
71 © NOKIA 31/10/2003 RANPAR Version 1.0
Any CRs in queueStart from
CR #1
Estimate PrxTotalNew andPrxNrtNew
Bit rate = MinAllowedBitRate
Increase loading
(A) PtxTotalNew < PtxTarget ANDPtxTotalChange < DeltaPtxMaxUpPtxNrtNew < PtxAllowed
(A)
End
Yes
NoNo
Bitrate Upgrade Process
changetotaltxtotaltxnewtotaltx PPP _____ +=
Example: DL
Yesmore CRsin queue
Move toNext CR inQueue
HigherAllowed Bitrates
Move toNext higher
bitrate
NoYes
72 © NOKIA 31/10/2003 RANPAR Version 1.0
• In the next phase the calculated PrxTotalNew, PtxTotalNew, PrxTotalChange, PtxTotalChange,PrxNrtNew and PtxNrtNew are compared against thresholds and bitrates are increased (orbitrate allocated to the new CR) in case:
• UL• PrxTotalNew < PrxTarget (RNC parameter)• PrxTotalChange < DeltaPrxMaxUp (RNC parameter)• PrxNrtNew < PrxAllowed (calculated in Power budget for packet scheduling UL
section)• DL
• PtxTotalNew < PtxTarget (RNC parameter)• PtxTotalChange < DeltaPtxMaxUp (RNC parameter)• PtxNrtNew < PtxAllowed (calculated in Power budget for packet scheduling UL
section)• It should be noted that in case DCH is allocated it must always be bi directional (at least
minimum bitrate must be possible, increase algorithm can work in either direction independently).
• Based on the load increase algorithm following examples can be made (minimum allowedbitrate 128kbps assumed) – see next slide:
Bit Rate upgrade process
73 © NOKIA 31/10/2003 RANPAR Version 1.0
128 (1) 256 (1) 384 (1)
PrxTarget
Step 1 Step 2 Step 3
No higher bit rateavailable, allocationaccording to step 3
128 (1)
128 (2)256 (1)
128 (2)
256 (1)
256 (2)
384 (1)
256 (2)PrxTarget
Step 1 Step 2 Step 3 Step 4
128 (1)
Step 5
Target exceeded,allocation according
to step 4
case 1: 1 CR in queue
case 2: 2 CRs in queue
128 (1)128 (2)
128 (3)
256 (1)
256 (2)
PrxTarget
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
74 © NOKIA 31/10/2003 RANPAR Version 1.0
• If case PrxTotal > PrxTarget or if PtxTotal > PtxTarget then next checking is performed PtxTotal (PrxTotal)< PtxTarget (PrxTarget) + PtxOffset (PrxOffset) (=PrxTargetBTS & PtxTargetBTS).
• In case the latter equation PtxTotal > PtxTargetBTS (or PrxTotal >PrxTargetBTS) then loading is decreased if not then previously scheduled loading is maintained i.e. no increase in bitrate.
• If the load is too high PS starts to decrease the bit rates of the NRT bearers.The bit rates can not be decreased lower than the MinAllowedBitRateUL or MinAllowedBitRateDL.
Bit Rate Allocation – Increase Load
75 © NOKIA 31/10/2003 RANPAR Version 1.0
Packet Scheduling• Overview
• Packet Transfer States & Parameters• Bitrate Allocation• Channel Type Selection• Capacity Request & Traffic Volume Measurements • Processing a Capacity Request
• Bitrate Upgrade
• Overload Control
• Dynamic Link Optimisation (DyLo)
76 © NOKIA 31/10/2003 RANPAR Version 1.0
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
77 © NOKIA 31/10/2003 RANPAR Version 1.0
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
78 © NOKIA 31/10/2003 RANPAR Version 1.0
• When overload is detected and dedicated channel is modified using Transport Format Combination Control(TFCC) –procedure, physical resources are not modified. it takes some time before the decrease in load (PrxTotal and PtxTotal) as can be seen in RNC from the NBAP: RADIO RESOURCE INDICATION messages.
• This delay may be longer than scheduling period and therefore it is necessary to wait that load control actions have effected, in order to prevent new unnecessary load control actions in the next scheduling period
• The parameter LoadControlPeriodPS determines the period how often PS can perform load control actions
• The selection of the bearers, whose transport formats combinations are modified, is done randomly but Bearer classes are taken into account so that the load decreased is performed in the following order:
1. DCH Bit rates of the Background class bearers are decreased in random order (not belowMinAllowedBitRateUL or MinAllowedBitRateDL)
2. DCH Bit rates of the Interactive class bearers are decreased in random order (not belowMinAllowedBitRateUL or MinAllowedBitRateDL)
3. Background class bearers are switched from DCH to CCH in random order4. Interactive class bearers are switched from DCH to CCH in random order
Overload Control
79 © NOKIA 31/10/2003 RANPAR Version 1.0
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
80 © NOKIA 31/10/2003 RANPAR Version 1.0
• In the next phase it is checked whether the selected bearer is already having the lowest possiblebitrate (according to MinAllowedBitRateUL and MinAllowedBitRateDL).
• in case minimum is reached then CCH is selected• in case minimum is not reached then bit rate is decreased to the next lower level
• PrxNrtNew and PtxNrtNew are calculated as in load increase algorithm.
• In the next step the following checks are done to see whether performed bitrate modifications are enough to decrease the loading below the PtxTarget + PtxOffset / PrxTarget + PrxOffset
• PrxTotalNew > PrxTarget• PtxTotalNew > PtxTarget
&• PrxTotalChange < DeltaPrxMaxDown• PtxTotalChange < DeltaPtxMaxDown
In case the above equations are true then more bearers' bitrates should be decreased (in case no more bearers available then ModificationPeriod time must be expired before new modification can be done for the bearers in question).
• The following pictures describe the operation of load decrease algorithm.
Overload Control
81 © NOKIA 31/10/2003 RANPAR Version 1.0
• 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
82 © NOKIA 31/10/2003 RANPAR Version 1.0
• When the maximum bit rates of the NRT RBs are decreased (by TFCC procedure) and the overload situation is over, original bit rates are given back to those bearers, whose bit rates were decreased before new allocations are made
Overload Control
83 © NOKIA 31/10/2003 RANPAR Version 1.0
DeltaPrxMaxUp (not implemented in RAN1.5.2 ED2)• Defines the maximum received uplink power increase in a cell, used when bit rates are allocated or
increased by the packet scheduler, relative to PrxTotal.default value: 1.6dB; range: 0 ... 5 dB, step 0.2 dB
DeltaPtxMaxUp (not implemented in RAN1.5.2 ED2)• Defines the maximum transmitted downlink power increase in a cell, used when bit rates are
allocated or increased by the packet scheduler, relative to PtxTotal.default value: 1.6dB; range: 0 ... 5 dB, step 0.2 dB
Bit Rate Allocation
84 © NOKIA 31/10/2003 RANPAR Version 1.0
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
85 © NOKIA 31/10/2003 RANPAR Version 1.0
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)
86 © NOKIA 31/10/2003 RANPAR Version 1.0
Dynamic Link Optimisation(DLO) for NRT Traffic Coverage
BTSBTSBTSBTS
UEUEUEUE
384kbps384kbps384kbps384kbps128kbps128kbps128kbps128kbps
Improved NRT traffic coverage
distanceRadio link is modified to use lower
bit rate when WBTS Tx power is getting close to maximum
87 © NOKIA 31/10/2003 RANPAR Version 1.0
Triggering of Dynamic Link Optimisation
time
Ptx, RLdistance
Ptx, ave
Triggering of DyLO
Ptx, maxOffset
Ptx, ave is averaged radio link power, measured and reported to RNC by BTS
Ptx, max is determined by admission control
The value of the Offset is fixed, 2 dB
Dynamic link optimisationis triggered if
Ptx, ave > Ptx, max - Offset
88 © NOKIA 31/10/2003 RANPAR Version 1.0
Decision algorithmMeasurementReportPtx,ave
(Ptx,ave + Offset) >Ptx,max
Select DCH(s) to bedowngraded
Requirements OK(min allowed bitrate,
SF, puncturing)
Reduce DCH bitrate(s) Reconfiguration notpossible
Compressed Modeactive
Guard timer active
No
Yes
No
Yes
No
No
Yes
Yes
Triggering of DyLO
DyLO is not possible during compressed mode
DyLO is possible for NRT DCH allocations that have lasted at least 2 seconds (fixed guard time)
Not applicable in RAN1.5 (only 1 NRT DCH possible per UE)
• SF is doubled (physical channel bit rate reduced to half of the original)
• Additional puncturing is not allowed• DyLO cannot reduce bit rate below the Initial and
minimum allowed bit rate in downlink (RAN1.5.2ED CD19)
• DyLO can be started only if the current bit rate is higher than Maximum Allowed DL User Bitrate in HHO (enable compressed mode due to DL power)
89 © NOKIA 31/10/2003 RANPAR Version 1.0
Bit Rate Upgrade• After downgrade of DCH bit rate due to DyLO, upgrade of the bit rate
can be performed from the initial bit rate level• Cell level parameter Initial and minimum allowed bit rate in
downlink is configurable by operator• Bit rate upgrade from any other bit rate is not possible• Bit rate upgrade is based on downlink traffic volume measurement
reports (capacity requests)• The change of the radio link power conditions does not trigger
upgrade• Possible triggering of the DyLO is checked before the bit rate is
upgraded, in order to avoid ping-pong effect (RAN1.5.2ED2)• New Ptx, max is calculated by AC according to the new bit rate• Initial Tx power Ptx, init is calculated by AC according to the new
bit rate• DyLO is possible if Ptx, init < (Ptx, max – Offset)• If inequality is not valid, the next lower bit rate is tried
Fixed, 2 dB
90 © NOKIA 31/10/2003 RANPAR Version 1.0
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)
91 © NOKIA 31/10/2003 RANPAR Version 1.0
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
92 © NOKIA 31/10/2003 RANPAR Version 1.0
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
93 © NOKIA 31/10/2003 RANPAR Version 1.0
Bitrate Upgrade Possibilities in Nokia RAN
SF32(64k) SF8(384k) SF16(128k)
SF32(64k) SF8(384k)
CELL-FACH SF32(64k) SF8(384k)
SF32(64k) SF8(384k) SF16(128k) SF8(384k)×
○
○
With Max_Bit_Rate/Ini-Min_Bit_Rate = 384k/64k setting.
Need big Traffic Volume but cannot shift directly to SF8
Call can go back to SF8 when
- Downgrade to SF32 takes place due to DyLO
-Inactive timer expires and moves to Cell-FACH
94 © NOKIA 31/10/2003 RANPAR Version 1.0
Example DyLO scheme 1: PtxDLabsMax 50 dBm, PtxTotalMax 43dBmD
L pw
r (d
Bm)
PtxTotalMax 43dBm
PtxPrimaryCPICH 33dBm
PtxPrimaryCPICH – CPICHtoRefRABoffset = 31 dBm
PtxDLabsMax 50 dBm
Calculated max RL pwr Calculated max RL pwr - DLOptimisationPwrOffset
• This is where DyLO triggers. (If PtxDLabsMax is set high)
Default hidden value is 2dB
reftxP ,
max,txP
Ptx, threshold
95 © NOKIA 31/10/2003 RANPAR Version 1.0
Example DyLO scheme 2: PtxDLabsMax 38 dBm, PtxTotalMax 43dBmD
L pw
r (d
Bm)
PtxTotalMax 43dBm
PtxPrimaryCPICH 33dBm
PtxPrimaryCPICH – CPICHtoRefRABoffset = 31 dBm
PtxDLabsMax 38 dBm
Calculated max RL pwr
PtxDLabsMax - DLOptimisationPwrOffset = 36 dBm
• PtxDLabsMax is reduced from 50dBm to 38dBm•This is where DyLO now triggers.
max,txP
reftxP ,
Ptx, threshold
96 © NOKIA 31/10/2003 RANPAR Version 1.0
Chapter 5-Packet Scheduling-
1. Which channel types the PS selects based on traffic load and parameters?
2. Name the scenarios for the WCDMA packet access.
3. What are the adventages of the URA_PCH state?
4. What task does the cell specific part of the PS perform?
5. If RT RAB’s require temporarily the target transmission power of the node B, what will happen to the NRT RAB’s on the same node B at that time?
6. How the traffic volume measurements are sent to the UE?
7. What parameter will affect to the DyLo Operation ?