Upload
nuno-fernandes
View
57
Download
9
Embed Size (px)
Citation preview
Nortel Confidential Information
Nortel Confidential Information
UTRAN Functional Simplification in UA5.0Configuration & Impact AnalysisSonia Martínez
Nortel Confidential Information
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
Nortel Confidential Information
UTRAN Functional Simplification
> Introduction• Scope• Objectives• Benefits• Features Removed or Simplified
> 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
Nortel Confidential Information
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
Nortel Confidential Information
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
Nortel Confidential Information
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
Nortel Confidential Information
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
Nortel Confidential Information
UTRAN Functional Simplification
> Introduction
> UA 4.1 Features Becoming Mandatory in UA05• Introduction• Iur Features• Iub Features
> Features to Remove; Configuration & Impact
> 2 Steps HHO Removal
> iRM Table Simplification
> iRM Scheduling
> Always On Evolution; DCH state removal
Index
Nortel Confidential Information
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
Nortel Confidential Information
> 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
Nortel Confidential Information
> 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
Iur FeaturesUA4.1 Features Becoming Mandatory in UA05
Nortel Confidential Information
> 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
Iur FeaturesUA4.1 Features Becoming Mandatory in UA05
Nortel Confidential Information
> 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
Nortel Confidential Information
UTRAN Functional Simplification
> Introduction• Scope• Objectives• Benefits• Features Removed or Simplified
> 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
Nortel Confidential Information
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
Nortel Confidential Information
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
Nortel Confidential Information
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).
> 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
Partial Event Triggered Measurement Mode
Nortel Confidential Information
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
> 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.
3G to 2G redirection (at RAB Assignment)
Nortel Confidential Information
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.
> Pre-check:• Configuration:
• InterFreqHhoFddCell cap2MobPathLossBorder = <unset>• InterFreqHhoFddCell mob2CapPathLossBorder = <unset>
> Vodafone PT Status: Not used
> Recommendation:• Check values (unset) in network.
Inter Frequency “mobility/capacity” blind HHO
Nortel Confidential Information
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
> 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
Call Establishment on Cell FACH option
Nortel Confidential Information
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
> 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)
Always On on Cell DCH 8/8 for mono Service
Nortel Confidential Information
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
Nortel Confidential Information
Features to Remove
> 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.
Downlink Power Partitioning
Nortel Confidential Information
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
Nortel Confidential Information
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
Nortel Confidential Information
UTRAN Functional Simplification
> 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
Nortel Confidential Information
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
Nortel Confidential Information
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
Nortel Confidential Information
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
Nortel Confidential Information
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
Nortel Confidential Information
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
Nortel Confidential Information
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
Nortel Confidential Information
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
Nortel Confidential Information
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
Nortel Confidential Information
UTRAN Functional Simplification
> 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
Index
Nortel Confidential Information
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
Nortel Confidential Information
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.
Nortel Confidential Information
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
Nortel Confidential Information
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
Nortel Confidential Information
iRM Table SimplificationUA4.2 iRM Table (Vodafone PT example)
Nortel Confidential Information
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)}
Nortel Confidential Information
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}
PS 256k Min {256, iRM Sched TxCP Fallback rate}
STR 256k Min {256, iRM Sched TxCP Fallback rate}
PS 128k Min {128, iRM Sched TxCP Fallback rate}
MUX 128k Min {128, iRM Sched TxCP Fallback rate}
STR 128k Min {128, iRM Sched TxCP Fallback rate}
PS 64k Min {64, iRM Sched TxCP Fallback rate}
Mux 64k Min {64, iRM Sched TxCP Fallback rate}
PS 32K Min {32, iRM Sched TxCP Fallback rate}
Nortel Confidential Information
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
Nortel Confidential Information
iRM Table Simplification
> 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
Nortel Confidential Information
iRM Table Simplification
> 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
Nortel Confidential Information
iRM Table Simplification
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
Nortel Confidential Information
iRM Table SimplificationUpgrade Example for VDF PT
Nortel Confidential Information
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• UA4.2 Behavior & Configuration• UA5.0 Evolution• Upgrade UA4.2 UA5.0
> Always On Evolution; DCH state removal
Index
Nortel Confidential Information
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
Nortel Confidential Information
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
Nortel Confidential Information
iRM Scheduling
> iRM Scheduling Downgrade based on TxCP
UA4.2 Behavior & Configuration Parameters
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
Nortel Confidential Information
iRM Scheduling
> iRM Scheduling Upgrade based on TxCP
UA4.2 Behavior & Configuration Parameters
Parameters used UA4.2(primary cell on SRNC)
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
Nortel Confidential Information
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
Nortel Confidential Information
iRM Scheduling
> iRM Scheduling Downgrade based on TxCP
UA5.0 Evolution Parameters
FDDCell
Parameters used UA5.0(primary cell on SRNC)
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
Nortel Confidential Information
iRM Scheduling
> iRM Scheduling Upgrade based on TxCP
UA5.0 Evolution Parameters
Parameters used UA5.0(primary cell on SRNC)
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)
Nortel Confidential Information
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
Nortel Confidential Information
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
Nortel Confidential Information
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• UA4.2 Implementation of Always_ON
• AON_DCH overview• AON_FACH overview• AON_FACH added value
• UA5.0 evolution• Proposed migration approach
Index
Nortel Confidential Information
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
Nortel Confidential Information
Always On Evolution; DCH state removal
> 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
Nortel Confidential Information
Always On Evolution; DCH state removal
> 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
Nortel Confidential Information
Always On Evolution; DCH state removal
> 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
Nortel Confidential Information
Always On Evolution; DCH state removal
> 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
Nortel Confidential Information
Always On Evolution; DCH state removal
> 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)
Nortel Confidential Information
Always On Evolution; DCH state removal
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
Nortel Confidential Information
BACKUP
Nortel Confidential Information
> 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
Nortel Confidential Information