UTRAN Simplification

Nortel Confidential Information
UTRAN Functional Simplification in UA5.0 Configuration & Impact Analysis

Sonia Martnez
UTRAN Functional Simplification

Index > 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
> Features to Remove; Configuration & Impact

> 2 Steps HHO Removal > iRM Table Simplification > iRM Scheduling
> Always On Evolution; DCH state removal
Introduction
Scope
> 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.
Introduction
Objective
> 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 Iso Performance ? Iso Functional ?
Successful Upgrade Pre-check and Corrective Eng Actions
Introduction
Benefit
> 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.
Introduction
Impacted Features
> 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

Index
> Introduction
Introduction Iur Features Iub Features
> Features to Remove; Configuration & Impact > 2 Steps HHO Removal > iRM Table Simplification
> iRM Scheduling

UA4.1 Features Becoming Mandatory in UA05 Introduction

> 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
UA4.1 Features Becoming Mandatory in UA05 Iur Features

> 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

> 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
UA4.1 Features Becoming Mandatory in UA05 Iub Feature

> 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

Index
> Introduction
Scope Objectives Benefits Features Removed or Simplified

> Features to Remove; Configuration & Impact > 2 Steps HHO Removal > iRM Table Simplification
> iRM Scheduling

Features to Remove
Non-DTX AMR Configurations
> 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
Features to Remove
Two-steps HHO procedure
> 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
Features to Remove
Partial Event Triggered Measurement Mode
> 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 isofunctionality between UA4.1 & UA4.2).
> Pre-check:
Configuration:
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
Features to Remove
3G to 2G redirection (at RAB Assignment)
> 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
> Pre-check:
Configuration:
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.
Features to Remove
Inter Frequency mobility/capacity blind HHO
> Inter Frequency Intra NodeB blind HHO is enhanced and integrated into global iMCTA feature.
> This feature was no more recommended from UA4.2. > Pre-check:
Configuration:
InterFreqHhoFddCell cap2MobPathLossBorder = <unset> InterFreqHhoFddCell mob2CapPathLossBorder = <unset>
> Vodafone PT Status: Not used > Recommendation:

Check values (unset) in network.
Features to Remove
Call Establishment on Cell FACH option
> 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
> Pre-check:
Configuration:
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
Features to Remove
Always On on Cell DCH 8/8 for mono Service
> 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
> Pre-check:
Configuration:
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)
Features to Remove
iRM Scheduling based on RLC
> 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
Features to Remove
Downlink Power Partitioning
> Power partitioning is removed, since this feature does not provide any benefits (feature behaviour not compliant with expected one). > Pre-check:
Configuration:
powerPartConfClass minspeechPowerratio = 0 powerPartConfClass minDataPowerratio = 0 powerPartConfClass minSignallingpowerratio = 0
> Vodafone PT Status: Not used > 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.
Features to Remove
Simplification of iRM Table provisioning
> 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
Features to Remove
Conclusion
> 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.

Index
> > > > 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
2 Steps HHO Removal

UA4.2 implementation of Alarm HHO
> 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
2 Steps HHO Removal

Two-steps algorithm overview
> First step to trigger Alarm Measurement
Object
AlarmMeasActivation (first step)
Parameter
counter stepDown stepUp cpichEcNoThreshold cpichRscpThreshold
Granularity
FDD cell
AlarmHardHoConf
counter
DlAsConf
(second step)
stepDown
stepUp cpichEcNoThreshold cpichRscpThreshold
> Second step to trigger HHO
2 Steps HHO Removal

Fast Alarm algorithm overview
> 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
Object
Parameter fastAlarmHoEnabled counter stepDown / stepUp
Granularity
> 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
RadioAccessService FastAlarmHardHoConf
DlAsConf
cpichEcNoThreshold / cpichRscpThreshold
blindHhoTimerForFdd / blindHhoTimerForGsm
2 Steps HHO Removal

Fast Alarm added value
> AlarmMeasActivation settings are applied to FastAlarmHardHoConf setting
Object AlarmMeasActivation 2 steps algo AlarmHardHoConf Fast Alarm algo FastAlarmHardHoConf Parameter cpichEcNoThreshold cpichRscpThreshold cpichEcNoThreshold cpichRscpThreshold cpichEcNoThreshold cpichRscpThreshold Value -15 -100 CS: -12 / PS: -16 CS: -90 / PS: -105 -15 -100
> Two-steps Vs. Fast Alarm:

Fast Alarm decreases the number of CM activations per call Fast 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
2 Steps HHO Removal

UA5.0 evolutions
> 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,
2 Steps HHO Removal

Proposed approach
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. 4.
UA4.2 to UA5.0 upgrade iMCTA configuration

Out of scope of the present document
OAM5.0 / UA4.2
-2Assessment and optimization
OAM5.1 / UA5.0
-1Two-steps to Fast Alarm migration
-3UA4.2 to UA5.0 upgrade

-4 iMCTA configuration
2 Steps HHO Removal

Proposed approach
> 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
Object AlarmMeasActivation Parameter counter stepDown stepUp cpichEcNoThreshold cpichRscpThreshold AlarmHardHoConf counter stepDown stepUp AlarmHardHoConf cpichEcNoThreshold Value 1 2 1 -13 dB -102 dBm 1 2 1 -13 dB Values for CS DlAsConf for which 3G2G HHO is allowed All DlAsConfs FDD cell Granularity / Comment
cpichRscpThreshold
AlarmHardHoConf cpichEcNoThreshold cpichRscpThreshold RadioAccessService isBlindHoRescueAllowed
-102 dBm
-13 dB -100dBm FALSE Values for CS+PS I/B DlAsConfs for which 3G2G HHO is allowed: CS+PS8, CS+PS64 and CS+PS128 3G-2G Blind handover is not configured
Not Fast_Alarm like settings and more relaxed than Voice, even tough pure PS HHO is not allowed
Fast_Alarm-like Strategy Used
2 Steps HHO Removal

Proposed approach
> Proposed Fast Alarm setting for RNC BOA1RN
isInterFreqCModeActivationAllowed and isGsmCModeActivationAllowed remain the same for each DlAsConf
Object
FastAlarmHardHo
Parameter
counter stepDown stepUp blindHhoTimerForFdd blindHhoTimerForGsm
Value
1 2 1 5500 ms 7500 ms -13 dB -102 dBm
Granularity / Comment
All DlAsConfs
FastAlarmHardHo
cpichEcNoThreshold cpichRscpThreshold
Values for all the DlAsConfs for which 3G2G HHO is allowed: - CS - CS+PS8, CS+PS64 and CS+PS128
RadioAccessService RadioAccessService
fastAlarmHoEnabled isBlindHoRescueAllowed
TRUE FALSE As 3G-2G Blind handover is not configured, blindHhoTimers are not used
Behaviour will be different only for CS+PS RABs: the HHO procedure will start for lower RSCP values

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

UA4.2 behavior & configuration reminder UA5.0 Evolution
Algorithm Upgrade
Upgrade Example for VDF PT
> iRM Scheduling > Always On Evolution; DCH state removal
iRM Table Simplification

iRM Algo: RL Colour & Cell Colour
Requested RAB 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
Allocated RAB

Introduction of Iub Load
OVSF code tree load 100%
Yellow2Red CLCthreshold Green2Yellow CLCthreshold Red2Yellow CLCthreshold Yellow2Green CLCthreshold
DL Power load 100%

Yellow2Red PLCthreshold Green2Yellow PLCthreshold Red2Yellow PLCthreshold Yellow2Green PLCthreshold
DL Iub load 100%

Yellow2Red DlTLCthreshold Green2Yellow DlTLCthreshold Red2Yellow DlTLCthreshold Yellow2Green DlTLCthreshold
0%
0%
0%
OVSF code load colour
Max
Power load colour
Radio colour
Iub load colour
Max
Cell colour
All the cells of a same NodeB have the same colour.

RAN Model extract
RNC NodeB
> NodeBConfId NodeBConfClass > Green2YellowDlTLCThreshold > Yellow2RedDlTLCThreshold > Red2YellowDlTCLCThreshold > Yellow2GreenDlTLCThreshold
FDDcell
> CacConfId
radioAccessService
DlRbSetConf
dedicatedConf
RLCondition
CacConfClass
CellColors IrmOnRLConditionsParameters > DlRbSetConfId >> IrmDlCoverageThreshold >> IrmDlPowerthreshold
ARPriorityLevel > DlRbSetConf >> CellColour >>> RLCondition >>>> PriorityLevel >>>>>> IrmDlRbSetId
IrmOnCellColoursParameters > Green2YellowCLCThreshold > Green2YellowPLCThreshold > Yellow2RedPLCThreshold > Yellow2RedCLCThreshold > Red2YellowPLCThreshold > Red2YellowCLCThreshold > Yellow2GreenPLCThreshold > Yellow2GreenPLCThreshold

UA4.2 iRM Table
> 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 (Vodafone PT example)

UA5.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)}

UA5.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}
DlRbSetConf PS 384k MUX 384k PS 256k STR 256k PS 128k MUX 128k FallBackRate Min {384, iRM Sched TxCP Fallback rate} Min {384, iRM Sched TxCP Fallback rate} Min {256, iRM Sched TxCP Fallback rate} Min {256, iRM Sched TxCP Fallback rate} Min {128, iRM Sched TxCP Fallback rate} Min {128, iRM Sched TxCP Fallback rate} Gold Silver Bronze
384 384 384 128 128 128 64 64 64
DlIrmTable OLS Cell Colour = Green Cell Colour = Yellow Cell Colour = Red
STR 128k
PS 64k Mux 64k PS 32K
Min {128, iRM Sched TxCP Fallback rate}

Min {64, iRM Sched TxCP Fallback rate} Min {64, iRM Sched TxCP Fallback rate} Min {32, iRM Sched TxCP Fallback rate}

UA5.0 RAN Model Extract
RNC
NodeB
> NodeBConfId NodeBConfClass > Green2YellowDlTLCThreshold > Yellow2RedDlTLCThreshold > Red2YellowDlTCLCThreshold > Yellow2GreenDlTLCThreshold
FDDcell
> CacConfId
radioAccessService
dedicatedConf
1..15
DlRbSetConf > fallbackRbRate DlIrmTableConfClass IrmRbRateList New IrmRbRateEntry
1..15
CacConfClass
IrmOnRLConditionsParameters > DlRbSetConfId >> IrmDlCoverageThreshold >> IrmDlPowerthreshold

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

UA5.0 Evolutions
> 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.

> 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

DlRbSetConf PS 384k MUX 384k FallBackRate 384 128 384 128
> 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
PS 256k
STR 256k PS 128k MUX 128k STR 128k PS 64k Mux 64k PS 32K
256 128
256 128 128 128 128 64 64 32
> Minimum impact in loss of iRM preemption flexibility

DlIrmTable
OLS
Cell Colour = Green

384 384 384
Cell Colour = Yellow

128 128 128
Cell Colour = Red

64 64 64
Gold Silver Bronze


Index
> Introduction
> UA 4.1 Features Becoming Mandatory in UA05 > Features to Remove; Configuration & Impact > 2 Steps HHO Removal > iRM Table Simplification > iRM Scheduling
UA4.2 Behavior & Configuration UA5.0 Evolution Upgrade UA4.2 UA5.0
iRM Scheduling
UA4.2 Behavior & Configuration Triggers
> 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
iRM Scheduling
UA4.2 Behavior & Configuration Parameters
> iRM Scheduling Downgrade based on radio conditions (RLC BLER)
RNC
1..1 RadioAccessService
1..32 DlRbSetConf
0..1 IrmSchedulingConf
fallbackThroughput targetDlRbSetForIrmScheduling timeToTrigger
Parameters used UA4.2 At RNC level
iRM Scheduling
> iRM Scheduling Downgrade based on TxCP
Thresholds are defined as : relative values to (cpichpower + maxDlTxPower) (primary cell on SRNC) absolute values in dB (primary cell on DRNC)
1..30
RNC
1..1
RadioAccessService
irmSchedDowngradeTxcpMaxBitRate
1..*
DlUserService
DedicatedConf
1..1
1..15
IrmSchedulingDowngradeTransCodePower
PowerConfClass
FDDCell
Parameters for use over Iur (not supported in UA4.2) At RNC level
1..1
1..40
LowRbA
DlUsPowerConf
Parameters used UA4.2 (primary cell on SRNC) At Cell level
maxBitrate thresholdTransCodePowerDefinitionParam dlIrmSchedDowngradeTxcpTrigger_threshold_delta dlIrmSchedDowngradeTxcpTrigger_timeToTrigger
timeToTrigger
iRM Scheduling
> iRM Scheduling Upgrade based on TxCP
RNC
1..30 DlUserService
Thresholds are defined as absolute values in dB
Parameters used UA4.2 (primary cell on SRNC) At RNC level
0..1 IrmSchedulingUpgrade
1..1 DHighRbB1
1..1 MediumRbB2
highBitRate thresholdTransCodePower timeToTrigger
intermediateBitRate deltaThresholdTransCodePower deltaTimeToTrigger
iRM Scheduling
UA5.0 Evolution Triggers & Iur support
> 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)
iRM Scheduling
UA5.0 Evolution Parameters
> iRM Scheduling Downgrade based on TxCP
Thresholds are defined as : relative values to cpichpower + maxDlTxPower (primary cell on SRNC) absolute values in dB (primary cell on DRNC)
1..30
RNC
1..1
RadioAccessService
irmSchedDowngradeTxcpMaxBitRate
1..*
DlUserService
DedicatedConf
1..15
1..1
PowerConfClass
1..40
IrmSchedulingDowngradeTransCodePower
FDDCell
Parameters used over Iur UA5.0 At RNC level
DlUsPowerConf
1..1
LowRbA
DlIrmSchedDowngradeTxcp
thresholdTransCodePowerDefinitionParam timeToTrigger
threshold_delta timeToTrigger
iRM Scheduling
UA5.0 Evolution Parameters
> iRM Scheduling Upgrade based on TxCP
Thresholds defined as absolute values in DB
RNC
Thresholds defined as relative values to (cpichpower + maxDlTxPower) (primary cell on SRNC)

1..*
1..30 DlUserService
DedicatedConf
1..15
0..1
PowerConfClass
1..40
IrmSchedulingUpgrade
DlUsPowerConf 1..1 DHighRbB1 1..1 MediumRbB2 DlIrmSchedUpgrade
Parameters used UA5.0 (primary cell on DRNC) At RNC level
highB1ThresholdDelta highB1TimeToTrigger mediumB2ThresholdDeltaOverHighB1 mediumB2TimeToTriggerOverHighB1

iRM Scheduling
Upgrade UA4.2 UA5.0; Principles
> 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)
iRM Scheduling
Upgrade UA4.2 UA5.0; Conclusions
> 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

Index
> 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
UA4.2 Implementation of Always_ON
AON_DCH overview AON_FACH overview AON_FACH added value
UA5.0 evolution Proposed migration approach

Always On Evolution; DCH state removal

UA4.2 implementation of Always On
> 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. Alwayson 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.
>
In UA4.2 there are 2 different options for AON downsize (first step)
1. 2. 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 bearer downsized radio bearer uses a shared resource: CELL_FACH. This option is available since UA4.0 and uses FACH/RACH

AON_DCH Overview
>

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
>
The downlink/uplink downsize criterion is met if:

nbTB * TBSize Step1ThroughputThreshold Step1AverageWin dow
During, at least, TimerT1 seconds
UL or DL Traffic
downsizing
upsizing
>
The downlink/uplink upsize criterion is met if:
Threshold
nbTBxTBsize Step1ThroughputThreshold Step1AverageWindow
downsizing timer
downsizing timer

AON_FACH Overview
> 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:

nbTb * TBsize Step1DlUlThroug hputThreshold Step1AverageWin dow
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
Transport Channel Traffic Volume Threshold
>
The UL upsize criteria is met if:

UL_BufferOccupancy > RepThreshold at least during TimeToTrigger sec
>
Time
The DL upsize criteria is met if:

DL_BufferOccupancy > Step1DlRlcBoThreshold
Reporting event 4A
Reporting event 4A

AON_FACH added value
> 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

UA5.0 evolution
> 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.
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)

Proposed migration approach
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
OAM5.0 / UA4.2
-2Assessment and optimization
OAM5.1 / UA5.0
-1AON_DCH to AON_FACH migration
-3UA4.2 to UA5.0 upgrade
-4URA/Cell_PCH configuration
BACKUP
UA4.1 Features Becoming Mandatory in UA05 Iub Feature

> 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

UTRAN Simplification

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UTRAN Simplification

Uploaded by

Copyright:

Available Formats

Nortel Confidential Information

UTRAN Functional Simplification in UA5.0 Configuration & Impact Analysis

Nortel Confidential Information

UTRAN Functional Simplification

> UA 4.1 Features Becoming Mandatory in UA05

> iRM Table Simplification

Nortel Confidential Information

UTRAN Functional Simplification

> UA 4.1 Features Becoming Mandatory in UA05

> Features to Remove; Configuration & Impact

> Always On Evolution; DCH state removal

Nortel Confidential Information

Nortel Confidential Information

> Securing Upgrades:

Nortel Confidential Information

> Removal of inter-frequency mobility/capacity blind HHO

Nortel Confidential Information

UTRAN Functional Simplification

> iRM Scheduling

Nortel Confidential Information

UA4.1 Features Becoming Mandatory in UA05 Introduction

Nortel Confidential Information

UA4.1 Features Becoming Mandatory in UA05 Iur Features

Vodafone PT Status: isSupportofExtendedRbAllowedOnDRNC = TRUE

Nortel Confidential Information

UA4.1 Features Becoming Mandatory in UA05 Iur Features

Nortel Confidential Information

UA4.1 Features Becoming Mandatory in UA05 Iur Features

Vodafone PT Status: isCModeActivationWithReconfAllowedOnDrnc = FALSE

Nortel Confidential Information

UA4.1 Features Becoming Mandatory in UA05 Iub Feature

Nortel Confidential Information

UTRAN Functional Simplification

> UA 4.1 Features Becoming Mandatory in UA05

> iRM Scheduling

Nortel Confidential Information

> Vodafone PT Status: Not used

Nortel Confidential Information

Nortel Confidential Information

Nortel Confidential Information

> Vodafone PT Status: Not used > Recommendation:

Nortel Confidential Information

> Vodafone PT Status: Not used

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

> Vodafone PT Status: Not used > Recommendation:

Nortel Confidential Information

> Vodafone PT Status:

Nortel Confidential Information

UTRAN Functional Simplification

Proposed approach for VDF PT

2 Steps HHO Removal

Fast Alarm algorithm (from UA4.1)

> Working hypothesis: measurement reporting in PERIODIC MODE

> The following overviews deal with Periodic Mode

Nortel Confidential Information

2 Steps HHO Removal

> Second step to trigger HHO

Nortel Confidential Information

2 Steps HHO Removal

Parameter fastAlarmHoEnabled counter stepDown / stepUp

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

Nortel Confidential Information

2 Steps HHO Removal