UTRAN Simplification

Nortel Confidential Information


UTRAN Functional Simplification in UA5.0Configuration & Impact AnalysisSonia Martínez


UTRAN Functional Simplification

> Introduction

> UA 4.1 Features Becoming Mandatory in UA05

> Features to Remove; Configuration & Impact

> 2 Steps HHO Removal

> iRM Table Simplification

> iRM Scheduling

> Always On Evolution; DCH state removal

Index



> Introduction• Scope• Objectives• Benefits• Features Removed or Simplified





> iRM Scheduling


Index


Introduction

> The scope of this package is to provide status on features related to UTRAN Simplification and establish action plans for identified issues.

> This package provides details only for UTRAN Simplification. There are other non Iso functionality features that will not be covered.

Scope


Introduction

> UTRAN Simplification• Reduce tests efforts by reducing the configuration options or removing

unused features• Simplify features datafill by reducing the number of parameter

> Securing Upgrades:• Ensure iso-functionality when possible (through engineering datafill actions)• Ensure iso-performances (KPI stability) from UA4.2 to UA5.0 when

applicable

Successful Successful UpgradeUpgrade

Successful Successful UpgradeUpgrade

Pre-check and Corrective Eng Actions

Iso Performance ?

Iso Functional ?

Objective


Introduction

> Reduce new features introduction cost. • An important part of the cost of a UTRAN S/W release comes from the

interactions between new and existing features.

> Improve R&D effectiveness (design and tests).

> Reduce recurring maintenance cost.

Benefit


Introduction

> Removal of non-DTX AMR Configurations

> Removal of two-Steps HHO Procedure

> Removal of Partial Event-Triggered measurements mode

> Removal of 3G to 2G redirection (at RAB Assignment)

> Removal of inter-frequency “mobility/capacity” blind HHO

> Removal of Call establishment on Cell FACH

> Removal of Always-on on Cell DCH 8/8 for Mono service

> Removal of iRM Scheduling based on RLC monitoring

> Removal of Downlink Power Partitioning Option

> Simplification of iRM table Provisioning

Impacted Features



> Introduction

> UA 4.1 Features Becoming Mandatory in UA05• Introduction• Iur Features• Iub Features




> iRM Scheduling


Index


UA4.1 Features Becoming Mandatory in UA05

> Low to none operational impact

> Iur Interface: Three drift V4.1 IOT features systematically activated activation flags disappears in V5.0• FRS 26138 Extension of RB configuration supported by DRNC (activation

already requested by a GPS bulletin)• FRS 26140 Transport bearer reconfiguration on Iur • FRS 27505 Compressed Mode activation over multi-vendor Iur

> Iub: One feature to be activated to prepare flag removal in next release • FRS 25647 AAL2 CAC Evolution

Introduction


> FRS 26138: Extension of RB configuration supported by DRNC• Flag: isSupportofExtendedRbAllowedOnDRNC• Activation already requested by a GPS bulletin to prevent inter-working

issues over Iur between RNC V4.1 and RNC V4.2.

• Activation impact: None. • Feature can only be triggered if requested by SRNC (non-Nortel or Nortel UA4.2,

UA5.0).

• Activation required for successful inter-working with UA4.2, UA5.0, E///, Nokia, Alcatel SRNCs.

• If not activated call failures when moving over Iur expected.

• Vodafone PT Status: isSupportofExtendedRbAllowedOnDRNC = TRUE

11

Iur FeaturesUA4.1 Features Becoming Mandatory in UA05


> FRS 26140: Transport bearer reconfiguration on Iur• Flag: isAal2BearerReplacementAllowedonDrnc

• Activation impact: None• Feature can only be triggered if requested by SRNC (non-Nortel or Nortel > UA5.0).

• Activation required for successful inter-working with E/// SRNC.• If not activated synchronised radio link reconfiguration on E/// SRNC for RRM

purposes will fail.

• Vodafone PT Status: isAal2BearerReplacementAllowedonDrnc = FALSE

12



> FRS 27505: Compressed Mode activation over multi-vendor Iur• Flag: isCModeActivationWithReconfAllowedOnDrnc

• Activation impact: None.• Feature can only be triggered if requested by SRNC (non-Nortel).

• Activation required for successful inter-working with E///, possibly also Nokia SRNCs.

• If not activated compressed mode activation failure over Iur.• Allows on the DRNC to accept configuration and activation of the

compressed mode by using the Synchronised Radio Link Reconfiguration Procedure (as opposed to compressed mode command).

• Vodafone PT Status: isCModeActivationWithReconfAllowedOnDrnc = FALSE

13



> FRS 25647 AAL2 CAC Evolution• Flag: isAal2BearerRenegotiationAllowed

• Activation impact: Low. • Better Iub bandwidth management.

• If not activated then AAL2 CAC will no longer be accurate. Calls may get rejected although there my be sufficient Iub bandwidth to accommodate them.

• Vodafone PT Status: isAal2BearerRenegotiationAllowed = TRUE

14

Iub FeatureUA4.1 Features Becoming Mandatory in UA05



> Introduction• Scope• Objectives• Benefits• Features Removed or Simplified





> iRM Scheduling


Index


Features to Remove

> In UA4.2 RNC supports two types of configuration for CS Speech:• CS 12.2k CBR• CS 12.2k DTX = Standard voice call configuration

> Pre-check:• 1st check = Monitoring:

• Check that no CBR CS 12.2k is allocated.• 2nd check = Configuration (once customer is sure not to use this bearers):

• DlRbSetConf/CSDTCH12_2k enabledForRabMatching = False• UlRbSetConf/CSDTCH12_2k enabledForRabMatching = False

> Vodafone PT Status: Not used

> Recommendation:• Change parameters settings (Parameters are class 3, no impact on

network)• No impact on KPI

Non-DTX AMR Configurations


Features to Remove

> Two steps HHO procedure is replaced from UA4.1 by Fast Alarm HHO procedure. Fast Alarm provides:• Better reactivity• Capacity Increase• Simplified Configuration

> Pre-check:• Configuration:

• RadioAccessService FastAlarmHoEnabled = True

> Vodafone PT Status: Fast Alarm has not been activated yet Action needed

> Recommendation:• Fast Alarm HHO is mandatory to activate before UA5.0• No impact on KPI• Iso Performance

Two-steps HHO procedure


Features to Remove

> From UA4.2, partial event triggered is replaced by Full Event Triggered measurement Mode. • In UA4.2, partial mode was no more accessible (case of non iso-

functionality between UA4.1 & UA4.2).


• FDDCell nbReportsBeforeSwitchingToEventMode = 0

> Vodafone PT Status: Partial event is no more available from UA4.2 (except MIB change), so not used. Pre check to ensure a clean upgrade

> Recommendation:• Change parameters settings (class 3), no impact on network• No KPI Impact

Partial Event Triggered Measurement Mode


Features to Remove

> 3G to 2G redirection at RAB Assignment is integrated in global iMCTA feature in UA5.0.• 3G-2G redirection is still possible at RRC phase


• RadioAccessService is3Gto2GVoiceCallRedirectOnRabEstabFailAllowed = False

> Vodafone PT Status: Currently this feature is not used by Vodafone PT although it is planned to use it during Christmas period

> Recommendation:• In case the feature is activated, it is necessary to disable it before the

upgrade to UA5.0• Check value (false) in network.

3G to 2G redirection (at RAB Assignment)


Features to Remove

> Inter Frequency Intra NodeB blind HHO is enhanced and integrated into global iMCTA feature.

> This feature was no more recommended from UA4.2.


• InterFreqHhoFddCell cap2MobPathLossBorder = <unset>• InterFreqHhoFddCell mob2CapPathLossBorder = <unset>


> Recommendation:• Check values (unset) in network.

Inter Frequency “mobility/capacity” blind HHO


Features to Remove

> Call establishment on Cell FACH removed and replaced by call establishment on Cell DCH SRB 13.6k (recommendation, or SRB 3.4k otherwise), which provides:• Fast call setup• Robust accessibility


• userServices dluserServiceId <> standAloneSRBinCellFACH• userServices dluserServiceId <> standAloneSRBinCellFACH

> Vodafone PT Status: Not used• Still under discussion (R&D, PLM) to keep Cell FACH as an option for 4

establishment causes (registration, detach, low priority signaling)

> Recommendation:• Parameters are class 3, no impact on service.• Iso performance on Important causes (user visible)• Limited impact or less critical for the 4 remaining causes

Call Establishment on Cell FACH option


Features to Remove

> Always On on cell FACH needed to:• Integrate X-PCH States (no Cell_DCH to x_PCH transition)• Integrate PS 8k in the RB Rate Adaptation feature


• AlwaysOnConf preferredTransportTypeForAlwaysOn = FACH

> Vodafone PT Status: Always On on Cell DCH is still being used, but changes are mandatory.• In UA5.0, with the introduction of x_PCH states, the impact of Cell FACH

could be reduced

> Recommendation:• Always On on Cell FACH MUST be activated before Upgrade to UA5.0

(several weeks before to have stable monitoring).• Iso Performance for the Upgrade• Iso configuration (recommendations are given in UPUG)

Always On on Cell DCH 8/8 for mono Service


Features to Remove

> The BLER Trigger for downgrading a PS call is replaced by a dedicated transmitted Power trigger.

• In UA4.2, it is recommended to use this feature in 2 cases:• Over Iur (no txCP over Iur in UA4.2)• When TxCP can not be configured over SRNC

> Pre-check:• Configuration: RadioAccessService isRlcMacBasedIrmSchedulingAllowed = False

> Vodafone PT Status: RLC trigger is still used in all cases.

> Recommendation:• TxCp Trigger must be activated before the upgrade (several weeks before to have stable

monitoring).• RLC trigger Feature to be deactivated short time before upgrade.• Impact on KPI and PS call management:

• Removing Iur trigger may increase CDR for calls over Iur (until the replacing feature is activated and Neighbor RNC upgraded to UA5.0)

• Other Impact due to TxCP trigger change (from absolute to relative)• Action plan to be set up, to clarify strategy and actions (under development).• No Iso Performance and No Iso Funtionality

iRM Scheduling based on RLC


Features to Remove

> Power partitioning is removed, since this feature does not provide any benefits (feature behaviour not compliant with expected one).


• powerPartConfClass minspeechPowerratio = 0• powerPartConfClass minDataPowerratio = 0• powerPartConfClass minSignallingpowerratio = 0


> Recommendation:• Iso functional if not used, iso performance if not used• Even if configured, no parameters modification (class 0, RNC build

needed), the risk on this non iso functionality upgrade is very limited.

Downlink Power Partitioning


Features to Remove

> Objective is to simplify the iRM Table Configuration from 90 instances to datafill down to 10

> Issue:• Loss of one level of flexibility for the iRM preemption configuration• Study on iRM table & Preemption needed to provide evolution on

recommendations

> Pre-check:• No pre-check, specific study for each customer to be done.

> Vodafone PT Status: • Action plan to be set up to clarify strategy.• Specific study and re-engineering customization needed

> Recommendation:• Iso functionality and Iso performance if the configuration is in line with

updated recommendations

Simplification of iRM Table provisioning


Features to Remove

> Upgrade to UA5.0 can not be iso-functional.

> Actions on live networks are needed prior to the upgrade to:• adapt configurations with upgrade requirements• minimize system impact• derisk upgrade procedure

> Actions will be needed after the upgrade, to ensure KPI continuity.

Conclusion



> Introduction> UA 4.1 Features Becoming Mandatory in UA05> Features to Remove; Configuration & Impact> 2 Steps HHO Removal

• UA4.2 Implementation of Alarm HHO• Two-steps algorithm overview• Fast Alarm algorithm overview• Fast Alarm added value

• UA5.0 evolutions• Two-steps algorithm removal• iMCTA introduction

• Proposed approach for VDF PT

> iRM Table Simplification> iRM Scheduling> Always On Evolution; DCH state removal

Index


2 Steps HHO Removal

> 2 different algorithms for Inter-frequency and Inter-RAT HHO decision• Two-steps algorithm

• Algorithm originally implemented for HHO• Uses 2 different radio criterion:

• Request of Inter-frequency or Inter-system measurements to UE• HHO Triggering

• Fast Alarm algorithm (from UA4.1)• One single radio criteria to trigger CM then Alarm HHO

> Working hypothesis: measurement reporting in PERIODIC MODE• FET is not provisioned in VDF Portugal yet (even though FET is the

recommendation from UA4.2)

> The following overviews deal with Periodic Mode

UA4.2 implementation of Alarm HHO


2 Steps HHO Removal

> First step to trigger Alarm Measurement

> Second step to trigger HHO

Two-steps algorithm overview Object Parameter Granularity

AlarmMeasActivation

(first step)

counter

stepDown

stepUp

cpichEcNoThreshold

cpichRscpThreshold

FDD cell

AlarmHardHoConf

(second step)

counter

stepDown

stepUp

cpichEcNoThreshold

cpichRscpThreshold

DlAsConf


2 Steps HHO Removal

> Only one algorithm to trigger CM• Similar algorithm as for two-steps to trigger CM• Applicable to Periodic Mode only• Specific parameters defined per DlUserService

> HHO is processed as soon as a valid neighbouring cell is reported

• Better reactivity as only 1 radio criteria is used• Capacity is increased as CM duration may be limited• Parameter setting is simplified

Fast Alarm algorithm overview

Object Parameter Granularity

RadioAccessService fastAlarmHoEnabled

FastAlarmHardHoConf counter

stepDown / stepUp

cpichEcNoThreshold / cpichRscpThreshold

blindHhoTimerForFdd / blindHhoTimerForGsm

DlAsConf


2 Steps HHO Removal

> AlarmMeasActivation settings are applied to FastAlarmHardHoConf setting

> Two-steps Vs. Fast Alarm:Fast Alarm decreases the number of CM activations per callFast Alarm does not impact global performance of the network such as call drop rate or HHO

success rate

> Feature parameters & usage to be optimized in order to take advantage of all feature capabilities, especially a configuration / DL AsConf which is also a benefit of the Fast Alarm feature

Fast Alarm added value

Object Parameter Value

cpichEcNoThreshold -15cpichRscpThreshold -100cpichEcNoThreshold CS: -12 / PS: -16cpichRscpThreshold CS: -90 / PS: -105cpichEcNoThreshold -15cpichRscpThreshold -100

AlarmMeasActivation

AlarmHardHoConf

FastAlarmHardHoConf

2 steps algo

Fast Alarm algo


2 Steps HHO Removal

> Two-steps algorithm is removed• UTRAN simplification The less code, the less interaction, the less

maintenance…• Incompatible with FET (Full Event Trigger)

• FET measurement reporting is the recommendation from UA4.2• As a consequence, some OAM5.0 parameters are removed:

• fastAlarmHoEnabled parameter• AlarmMeasActivation and AlarmHardHoConf objects

Impact on VDF Portugal• Migration to Fast Alarm is mandatory

> iMCTA introduction• Exhaustive algorithm to handle multi carrier networks• Different triggers to process Inter-frequency and Inter-System HO

• iMCTA Alarm will replace UA4.2 Alarm algorithm• Some UA4.2 parameters will be replaced by iMCTA parameters in OAM5.1

• blindHhoTimerForFdd, blindHhoTimerForGsm, FastAlarmHhoStrategy,…

UA5.0 evolutions


2 Steps HHO Removal

1. Migration from Two-steps to Fast Alarm in UA4.2 timeframe• Defining new settings for FastAlarmHardHo setting• Cf. next slide

2. Assessment and optimization• Performance metrics monitoring Check that no degradation occurs• Optimization if needed

3. UA4.2 to UA5.0 upgrade

4. iMCTA configuration• Out of scope of the present document

Proposed approach

- 3 -UA4.2 to UA5.0

upgrade

- 1 -Two-steps to

Fast Alarm migration

-4 - iMCTA

configuration

OAM5.0 / UA4.2 OAM5.1 / UA5.0

- 2 -Assessment and

optimization


2 Steps HHO Removal

> Actual Two-steps setting for RNC BOA1RN• No Inter-Frequency neighbourhood• isGsmCModeActivationAllowed set to TRUE only for a restricted set of DlAsConfs:

• CS and CS+PS I/B RABs

Proposed approach

Object Parameter Value Granularity / Comment

AlarmMeasActivation counter

stepDown

stepUp

cpichEcNoThreshold

cpichRscpThreshold

1

2

1

-13 dB

-102 dBm

FDD cell

AlarmHardHoConf counter

stepDown

stepUp

1

2

1

All DlAsConfs

AlarmHardHoConf cpichEcNoThreshold

cpichRscpThreshold

-13 dB

-102 dBm

Values for CS DlAsConf for which 3G2G HHO is allowed

AlarmHardHoConf cpichEcNoThreshold

cpichRscpThreshold

-13 dB

-100dBm

Values for CS+PS I/B DlAsConfs for which 3G2G HHO is allowed:

CS+PS8, CS+PS64 and CS+PS128

RadioAccessService isBlindHoRescueAllowed FALSE 3G-2G Blind handover is not configured

Fast_Alarm-like Strategy Used

Not Fast_Alarm like settings and more relaxed than Voice, even tough pure PS HHO is not allowed


2 Steps HHO Removal

> Proposed Fast Alarm setting for RNC BOA1RN• isInterFreqCModeActivationAllowed and isGsmCModeActivationAllowed remain the same

for each DlAsConf

• Behaviour will be different only for CS+PS RABs: the HHO procedure will start for lower RSCP values

Proposed approach

Object Parameter Value Granularity / Comment

FastAlarmHardHo counter

stepDown

stepUp

blindHhoTimerForFdd

blindHhoTimerForGsm

1

2

1

5500 ms

7500 ms

All DlAsConfs

FastAlarmHardHo cpichEcNoThreshold

cpichRscpThreshold

-13 dB

-102 dBm

Values for all the DlAsConfs for which 3G2G HHO is allowed:

- CS

- CS+PS8, CS+PS64 and CS+PS128

RadioAccessService fastAlarmHoEnabled TRUE

RadioAccessService isBlindHoRescueAllowed FALSE As 3G-2G Blind handover is not configured, blindHhoTimers are not used



> Introduction




> iRM Table Simplification• UA4.2 behavior & configuration reminder• UA5.0 Evolution

• Algorithm• Upgrade

• Upgrade Example for VDF PT

> iRM Scheduling


Index


iRM Table SimplificationiRM Algo: RL Colour & Cell Colour

Criteria:• Radio Link Condition:

• Green or Red

• Cell Color:• Green, Yellow or Red• Status based on:

• Power Load Colour:• Green, Yellow or Red

• OVSF Code Colour:• Green, Yellow or Red

• A/R Priority Level:• Gold, Silver, Bronze

Requested RAB

Allocated RAB


iRM Table SimplificationIntroduction of Iub Load

OVSF code tree load

Green2YellowCLCthreshold

Yellow2RedCLCthreshold

Yellow2GreenCLCthreshold

Red2YellowCLCthreshold

100%

0%

Radio colour

MaxOVSF code load colour

Power load colour

Iub load colour

DL Power load

Green2YellowPLCthreshold

Yellow2RedPLCthreshold

Yellow2GreenPLCthreshold

Red2YellowPLCthreshold

100%

0%

DL Iub load

Green2YellowDlTLCthreshold

Yellow2RedDlTLCthreshold

Yellow2GreenDlTLCthreshold

Red2YellowDlTLCthreshold

100%

0%

Max

Cell colour All the cells of a same NodeB have the same colour.


iRM Table SimplificationRAN Model extract

RNC

DlRbSetConf

RLCondition

CellColors

ARPriorityLevel> DlRbSetConf>> CellColour>>> RLCondition>>>> PriorityLevel>>>>>> IrmDlRbSetId

CacConfClass

IrmOnRLConditionsParameters> DlRbSetConfId>> IrmDlCoverageThreshold>> IrmDlPowerthreshold

IrmOnCellColoursParameters> Green2YellowCLCThreshold> Green2YellowPLCThreshold> Yellow2RedPLCThreshold> Yellow2RedCLCThreshold> Red2YellowPLCThreshold> Red2YellowCLCThreshold> Yellow2GreenPLCThreshold> Yellow2GreenPLCThreshold

FDDcell> CacConfId

NodeBConfClass> Green2YellowDlTLCThreshold> Yellow2RedDlTLCThreshold> Red2YellowDlTCLCThreshold> Yellow2GreenDlTLCThreshold

NodeB> NodeBConfId

radioAccessService dedicatedConf


iRM Table Simplification

> The following bearers are eligible to iRM Table:• PS 32K• PS 64K & PS_64K_Mux• PS 128K• PS 256K• PS 384K

> For each bearer to apply iRM table, the subtree is:• 2 RL Condition instances• 3 Cell Color instances per RL Condition• 3 AR Priority Level per Cell Color 18 output of the iRM table per Bearer!

> The RL Bad / Cell Color Red output is used for iRM preemption configuration

UA4.2 iRM Table


iRM Table SimplificationUA4.2 iRM Table (Vodafone PT example)


iRM Table SimplificationUA5.0 Evolutions

> No evolution on Cell Color and Iub Color configuration

> Only iRM Table (downgrading function) is impacted by UTRAN Simplification feature:• Bearers eligible to iRM Table will point toward iRM Table ConfClass.• Radio Link part is removed from Table, replaced by a single parameter

(fallBackRbRate)

> The RB allocated is:

Min {Requested Rb, iRM Table output, fallback bearer (if RL is bad)}


iRM Table SimplificationUA5.0 Evolutions

> Upgrade Behavior• The upgrade rule implemented in WAUT is the following:

• To take the maximum of benefit of UTRAN Simplification, all RB will point to the same instance of iRM Table, based on UA4.2 PS 384k instance.

• fallbackRbRate is calculated as:min {Current RB Bit Rate, iRM Scheduling TxCP FallBack Bit rate}

OLS

DlIrmTable

Cell Colour = Green

Cell Colour = Yellow

Cell Colour = Red

Gold 384 128 64

Silver 384 128 64

Bronze 384 128 64

DlRbSetConfDlRbSetConf FallBackRateFallBackRate

PS 384k Min {384, iRM Sched TxCP Fallback rate}

MUX 384k Min {384, iRM Sched TxCP Fallback rate}


STR 256k Min {256, iRM Sched TxCP Fallback rate}


MUX 128k Min {128, iRM Sched TxCP Fallback rate}

STR 128k Min {128, iRM Sched TxCP Fallback rate}


Mux 64k Min {64, iRM Sched TxCP Fallback rate}

PS 32K Min {32, iRM Sched TxCP Fallback rate}


iRM Table SimplificationUA5.0 RAN Model Extract

RNC

DlRbSetConf> fallbackRbRate

CacConfClass

IrmOnRLConditionsParameters> DlRbSetConfId>> IrmDlCoverageThreshold>> IrmDlPowerthreshold

IrmOnCellColoursParameters> Green2YellowCLCThreshold> Green2YellowPLCThreshold> Yellow2RedPLCThreshold> Yellow2RedCLCThreshold> Red2YellowPLCThreshold> Red2YellowCLCThreshold> Yellow2GreenPLCThreshold> Yellow2GreenPLCThreshold

FDDcell> CacConfId

NodeBConfClass> Green2YellowDlTLCThreshold> Yellow2RedDlTLCThreshold> Red2YellowDlTCLCThreshold> Yellow2GreenDlTLCThreshold

NodeB> NodeBConfId

radioAccessService dedicatedConf

DlIrmTableConfClass

IrmRbRateList

IrmRbRateEntryNewNew

1..151..15



> Risks of non Iso-Funtionality• iRM preemption now uses the red cell state, while it was using “Red Cell /

bad Radio Link” in UA4.2 less flexibility. iRM preemption settings will not be so aggressive.

• At upgrade, only one table is kept. It shall be possible after the upgrade to recreate several instances of the iRM table, to get back some behavior.

• Re-tuning & Re-engineering of the iRM Cac feature & iRM preemption feature will be needed

> Engineering Actions• As part of the preparation to UA5.0, it is recommended to ensure an iso

functionality for the upgrade:• Analyze the current configuration• Propose a new set of parameters• Apply these new settings and check network performance

• Several months before the upgrade.

UA5.0 Evolutions



> iRM Table activated on:• PS 384k• PS 256k• PS 128k• PS 64k & MUX 64k (but setting equivalent to deactivated)• PS 32k

> iRM Scheduling fall Back rate:• TxCP: 128 (deactivated)• BLER Trigger: 128

Upgrade Example for VDF PT



OLS

DlIrmTable

Cell Colour = Green

Cell Colour = Yellow

Cell Colour = Red

Gold 384 128 64

Silver 384 128 64

Bronze 384 128 64

DlRbSetConfDlRbSetConf FallBackRatFallBackRatee

PS 384k 384 128

MUX 384k 384 128

PS 256k 256 128

STR 256k 256 128

PS 128k 128

MUX 128k 128

STR 128k 128

PS 64k 64

Mux 64k 64

PS 32K 32

> Upgrade to UA5.0 will be not be isofunctional• PS 256K and PS 32K impacted, tough not

in use• VDF PT special settings: OLS is not used! • No impact if iRM table is previously

modified

> Minimum impact in loss of iRM preemption flexibility

Upgrade Example for VDF PT


iRM Table SimplificationUpgrade Example for VDF PT



> Introduction





> iRM Scheduling• UA4.2 Behavior & Configuration• UA5.0 Evolution• Upgrade UA4.2 UA5.0


Index


iRM Scheduling

> iRM Scheduling Downgrade : 2 different triggers• RLC BLER (retransmissions)• TxCP Dedicated Measurements (Event A)

> iRM Scheduling Upgrade : 1 trigger• TxCP Dedicated Measurements (Event B1 & B2)

> Support on Iur• Dedicated Measurements not supported on Iur• Only iRM Scheduling Downgrade based on radio conditions (RLC BLER)

available when primary cell is on a drift RNC

UA4.2 Behavior & Configuration Triggers


iRM Scheduling

> iRM Scheduling Downgrade based on radio conditions (RLC BLER)

UA4.2 Behavior & Configuration Parameters

Parameters used UA4.2At RNC level

RadioAccessService

RNC

IrmSchedulingConf

DlRbSetConf

0..1

1..32

1..1

• fallbackThroughput• targetDlRbSetForIrmScheduling• timeToTrigger


iRM Scheduling

> iRM Scheduling Downgrade based on TxCP


FDDCell

Parameters used UA4.2(primary cell on SRNC)

At Cell level

• dlIrmSchedDowngradeTxcpTrigger_threshold_delta

• dlIrmSchedDowngradeTxcpTrigger_timeToTrigger

• maxBitrate

• thresholdTransCodePowerDefinitionParam

• timeToTrigger

• irmSchedDowngradeTxcpMaxBitRate

Thresholds are defined as :• relative values to (cpichpower + maxDlTxPower) (primary cell on SRNC)• absolute values in dB (primary cell on DRNC)

Parameters for use over Iur(not supported in UA4.2)

At RNC level

RadioAccessService

RNC

DlUserService

1..30

IrmSchedulingDowngradeTransCodePower

1..1

LowRbA

1..1

1..1

DedicatedConf

1..*

PowerConfClass

DlUsPowerConf

1..15

1..40


iRM Scheduling

> iRM Scheduling Upgrade based on TxCP



At RNC level

• highBitRate

• thresholdTransCodePower

• timeToTrigger

• intermediateBitRate

• deltaThresholdTransCodePower

• deltaTimeToTrigger

RadioAccessService

RNC

IrmSchedulingUpgrade

DlUserService

0..1

1..30

1..1

MediumRbB2DHighRbB1

1..1

1..1

Thresholds are defined as absolute

values in dB


iRM Scheduling

> iRM Scheduling Downgrade : only 1 trigger from UA5.0• RLC BLER (retransmissions) is removed• TxCP Dedicated Measurements (Event A)

> iRM Scheduling Upgrade : 1 trigger• TxCP Dedicated Measurements (Event B1 & B2)

> Support on Iur• Dedicated Measurements supported on Iur• Different parameters used if primary cell is on SRNC or on Iur (primary cell

on DRNC)

UA5.0 Evolution Triggers & Iur support


iRM Scheduling

> iRM Scheduling Downgrade based on TxCP

UA5.0 Evolution Parameters

FDDCell


At Cell level

• threshold_delta

• timeToTrigger

•thresholdTransCodePowerDefinitionParam

• timeToTrigger

• irmSchedDowngradeTxcpMaxBitRate

Thresholds are defined as :• relative values to cpichpower + maxDlTxPower (primary cell on SRNC)• absolute values in dB (primary cell on DRNC)

Parameters used over IurUA5.0

At RNC level

RadioAccessService

RNC

DlUserService

1..30

IrmSchedulingDowngradeTransCodePower

1..1

LowRbA

1..1

1..1

DedicatedConf

1..*

PowerConfClass

DlUsPowerConf

1..15

1..40

DlIrmSchedDowngradeTxcp


iRM Scheduling

> iRM Scheduling Upgrade based on TxCP

UA5.0 Evolution Parameters


At Cell level

RadioAccessService

RNC

IrmSchedulingUpgrade

DlUserService

0..1

1..30

1..1

MediumRbB2DHighRbB1

1..1

1..1

DedicatedConf

1..*

PowerConfClass

DlUsPowerConf

1..15

1..40

DlIrmSchedUpgrade

• highB1ThresholdDelta

• highB1TimeToTrigger

•mediumB2ThresholdDeltaOverHighB1

•mediumB2TimeToTriggerOverHighB1

Parameters used UA5.0(primary cell on DRNC)

At RNC level

Thresholds defined as absolute values in DB

Thresholds defined as relative values to (cpichpower + maxDlTxPower) (primary cell on SRNC)


iRM Scheduling

> iRM Scheduling Downgrade• Iso-functionality• Same parameters, some of them on different objects

> iRM Scheduling Upgrade• No iso-functionality• Old absolute values are kept for use over Iur• New relative thresholds are set through upgrade tool using a specific rule

> iRM Scheduling over Iur• No iso-functionality: after upgrade, no more iRM Scheduling over Iur (DRNC

must support Dedicated Measurement before activation)• Risk of call drop over Iur because no more downgrade can be performed

(RLC trigger is removed) • The activation of iRM Scheduling over Iur is done through the parameter

isIrmSchedulingUpgradeAllowedFromThisUS (DlUserService/PS_384k)

Upgrade UA4.2 UA5.0; Principles


iRM Scheduling

> iRM Scheduling when primary cell is on SRNC• Not iso-functional (due to iRM Scheduling Upgrade)• But better efficiency due to consistency between triggers of downgrade &

upgrade• Network performance shall be monitored after the upgrade to validate the

behaviour of the feature

> iRM Scheduling when primary cell is on DRNC• Complete downgrade/upgrade mechanism compared to UA4.2 (only

downgrade)• With SRNS relocation, this case will be less frequent• Drawback : all RNCs have to support Dedicated Measurements

Upgrade UA4.2 UA5.0; Conclusions



> Introduction





> iRM Scheduling

> Always On Evolution; DCH state removal• UA4.2 Implementation of Always_ON

• AON_DCH overview• AON_FACH overview• AON_FACH added value

• UA5.0 evolution• Proposed migration approach

Index


Always On Evolution; DCH state removal

> Always‑On is a solution to manage PS users connected for a long period of time with sporadic traffic profile (e.g. web browsing). It allows saving radio resources as well as RNC processing resources.

> Always On is mainly based on RNC ability to monitor traffic activity. Always-on concept in 2 steps:

• After a first period of inactivity, the bearer is reconfigured to a predefined downsized bearer configuration, which consumes less resources. If a traffic activity is detected, the bearer is upgraded back to its initial configuration

• If no traffic activity is detected during a second period of time, then the bearer is released from the UTRAN prospective, but is still “on” from the core network perspective.

UA4.2 implementation of Always On

> In UA4.2 there are 2 different options for AON downsize (first step)1. downsized radio bearer uses a dedicated resource: CELL_DCH. This option is

available since UA2.1 and uses as downsize RB the IB PS 8/8 bearer2. downsized radio bearer uses a shared resource: CELL_FACH. This option is

available since UA4.0 and uses FACH/RACH



> For the decision process, upsize and downsize criteria are defined for both directions, UL & DL. They are based on traffic volume monitoring on non-sliding time windows and use the following parameters:

• Step1AverageWindow: length of the time window in TTI• NbTB: Number of Transport Blocks transferred during the time window• TBsize: size of a L1 Transport Block (in bits)• TimerT1: downsizing timer (in s). This timer is actually a multiple of Step1AverageWindow• Step1ThroughputThreshold: throughput threshold for step 1 downsize

AON_DCH Overview

downsizing timer

UL or DL Traffic

Threshold

downsizing timer

downsizing upsizing

> The downlink/uplink downsize criterion is met if:

•

During, at least, TimerT1 seconds > The downlink/uplink upsize

criterion is met if:

ThresholdThroughputStepdowAverageWinStep

TBSizenbTB1

1

*

holdghputThresStep1ThrougeWindowStep1Avera

enbTBxTBsiz



> When Cell_FACH is used for downsizing, the criteria used follows the same principle as for Cell DCH, except that a different throughput threshold is introduced :

• Step1DlUlThroughputThreshold: throughput threshold for downsize Cell_Dch Cell_Fach

> The downlink/uplink downsize criterion is met if:

During, at least, TimerT1 seconds

> The downsized RB is supported on common channels (RACH/FACH), so the downsize does not involve a RL Reconfiguration, but rather a deletion of the dedicated RL.

> The Upsize conditions will be based on RLC buffer occupancy:• On UE side, the UL upsize condition relies on event triggered UE traffic volume measurement on RACH Transport

Channel (based on event 4A)• On RNC side, the FACH RLC buffer occupancy is measured

AON_FACH Overview

> The UL upsize criteria is met if:UL_BufferOccupancy > RepThresholdat least during TimeToTrigger sec

> The DL upsize criteria is met if: DL_BufferOccupancy > Step1DlRlcBoThreshold

oldhputThreshDlUlThrougStepdowAverageWinStep

TBsizenbTb1

1

*

Threshold

Transport Channel Traffic Volume

Reporting event 4A

Time

Reporting event 4A



> High Capacity gain:• OVSF Codes:

• No additional cost in case of AON_FACH (the RL is deleted). FACH is using one SF64 (no mater the number o f downsized RABs)

• In DCH mode, each downsized RAB is using one SF128 (1 voice call equivalent)

• CEM• No additional cost in case of AON_FACH (FACH cost is constant and included in

common channels cost)• In case of AON_DCH, each downsized PS call will use resources equivalent to 1

voice call

• Iub: RL is released so no dedicated resources used on Iub

• RNC:• Lower User plane usage (no more dedicated resources)• Lower Control plane usage (Cell update cost is lower that ASU + measurements)

AON_FACH added value



> Homogeneity: • it is the solution implemented by all other UTRAN vendors (Nortel is the only

one proposing a DCH based alternative)

> Drawbacks:• Lower protection in case of mobility & bad radio conditions (no benefit of

SHO multiple legs) negative impact on Cell Update success ratio

• Cell Update not supported on Iur RRC Connection Release & Reestablishment. No impact on User perception (only on monitoring results). The occurrence of this problem will be significantly reduced by SRNS Relocation in UA5.0

AON_FACH added value



> AON_DCH is removed. The only option available will be AON_FACH

> In terms of parameters evolution:• preferredTransportTypeForAlwaysOn in AlwaysOnConf object will disappear. The system will consider by default the value ”FACH“ for this parameter

> AON_FACH is mandatory to be activated before the UA4.2 UA5.0 upgrade. Otherwise the AON function will be deactivated during the upgrade:

• If preferredTransportTypeForAlwaysOn is detected “Dch” prior to upgrade, the flag isAlwaysOnAllowed is automatically set to “False”

> New RRC states are introduced in UA5.0 (URA/Cell_PCH) which will be in direct interaction with the AON_FACH mechanism

• Maintaining AON_DCH in a such a complex algorithm would generated heavy extra development/test costs and risk of destabilizing the load.

UA5.0 evolution

AON_FACH becomes the only option available in UA5.0

New RRC states implemented in UA5.0 (URA/Cell_PCH) directly impacting the AON algorithm (& requiring AON_FACH)



1. Migration from AON_DCH to AON_FACH in UA4.2 timeframe

2. Assessment and optimization• Performance metrics monitoring• Optimization if needed

3. UA4.2 to UA5.0 upgrade

4. URA/Cell_PCH configuration• Out of scope of the present document

Proposed migration approach

- 3 -UA4.2 to UA5.0

upgrade

- 1 -AON_DCH to AON_FACH

migration

- 4 -URA/Cell_PCH configuration

OAM5.0 / UA4.2 OAM5.1 / UA5.0

- 2 -Assessment and

optimization


BACKUP


> Basics on AAL2• When we allocate a CID (AAL2 connection) what do we actually reserve?

• A number (8-255 inside a provisioned VCC or path).• A certain amount of bandwidth we call EBR (Equivalent Bit Rate).

• What is AAL2 CAC for?• Make sure we do not accept more AAL2 connections (in terms of bandwidth) than

our transport pipe can accommodate.• Based on statistical multiplexing gains we do not allocate the actual max bandwidth

of a connection but rather an estimation called Equivalent Bit Rate allowing some overbooking.

• AAL2 CAC applies to Iu-cs, Iur and Iub regardless of the fact whether we use or not Q.AAL2 (ALCAP) to negotiate with the peer.

68

Iub FeatureUA4.1 Features Becoming Mandatory in UA05

UTRAN Simplification

Documents

Transcript of UTRAN Simplification