Você está na página 1de 53

The latest version of this material can be found here

For internal use


1 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Mass Event Solution
Table of Contents

Introduction Dynamic Solution


1 Mass Event definition 5 Enabling additional features

Special Event Support Solution RAN2879 Mass Event Handler


2 NSN additional service
6 Feature description and parametrization

Network Impact RAN2954 Voice Call Prioritization


3 Network element and Performance impact
7 Feature description and parametrization

Static solution RAN1202 24 kbps PCH


4 Global parameter modification and optimization
8 Feature description and parametrization

RAN2480 Automatic Access Class Restriction


9 Feature description and parametrization

NEI Contact: Bartosz Bieda / Michał Barański

For internal use


3 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Introduction Main Menu
Mass Event Definition

• A special event is defined as any:


o cultural,
o religious,
o political,
o economic,
o sport gathering
where an increased number of end users within a service area are expected.

• Special events are usually concentrated at certain geographical location, but can also be
distributed over larger areas, countries or even world wide.

• During special events a drastic increase of voice and data together with unconventional traffic is
expected. This gives additional revenue potential for the operator.

• Network quality, high performance, but especially availability of common services are required.
• During international events, lots of roaming users are expected, high pressure is not only for the
network operator (brand impact), but also for the hosting nations or cities.

• Special events require extra effort and preparations by the network operator usually with limited
budget (higher than normal requirements need to be used in network dimensioning and configuration
to ensure service availability).

For internal use


4 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Introduction Main Menu
Mass Event Preparation

• Identify the cluster to be impacted with Mass Event Mass Event area

• Audit network elements that may be impacted


BTS
BTS

• Prepare traffic forecast


BTS

• Compare traffic forecast to the actual network


capacity
• Identify KPIs which may be impacted
• Define threshold compromise for KPIs Increased Revenue
opportunity
• Modify network settings to handle traffic demand Traffic Demand

Traffic
• Ensure high service availability while keeping your
budget frame
Traffic handling
without event
• Maximize additional revenue potential from visiting readiness
subscribers and international roamers
Event period

For internal use


5 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Network Impact Main Menu
Main focus areas of identification

Hardware Hardware
• Insufficient capacity • Add COWs - high capacity temp sites
• Insufficient power • Add new sectors / sites
• Commissioning or synch issues • Modify HW components
Baseband Baseband
• Insufficient baseband capacity • Add licenses and/or HW
• Too many users per cell / scheduler / LCG • Add / modify LCG configuration
• Insufficient licenses keys • Baseband parameter modification
Radio Radio
• Overload in air interface • Revision of UL AC settings
• Power Spiking and high UL interference (RTWP) • Other Parameter tuning and optimization
• RACH/FACH/PCH overload and UL AC blocking

Transport / RNC Transport / RNC


• Transport capacity • Add VC on all interfaces (ATM)
• CAC blocking on the Iur interfaces • Modifying DMPG Pooling
• ICSU / DMPG / USPU /CSPU load
Planning Planning
• Modify planning assumptions • Modify planning assumptions
• URA updates problem • Remove unnecessary neighbor relationships
• RF modification - coverage holes • RF modification - improve coverage along event area

For internal use


6 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Special Event Support Solution Main Menu
Program background

Preventive
activities to Conduct post-
Plan support prepare for Monitor the event analysis
activities during increased network during and Network
special events network traffic the event restoration work

Preparation Implementation Monitoring Closing

 Project Planning  Network  NE / KPI  Return to


 Event Cluster Reconfiguration surveillance business-as-usual
Analysis  Capacity Adds  On-Site / remote configuration

 Traffic Analysis  NE checks and support  Reporting


implementation of  Increased  Closing, debrief
corrections emergency and lessons-
 NE data backup support readiness learned Meeting
Special Event Support Solution  Implementation

For internal use


7 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
For internal use
8 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Impact on KPIs Main Menu
Voice and Packet Call related KPIs

Good Session
Success Ratio
High number of
attempts during
Mass Event Poor CSSR CS
Voice due to AC Poor PSSSR due
to AC

Small traffic day


before High number of
attempts during
Mass Event

For internal use


9 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Impact on KPIs Main Menu
Noise Rise

Mass Event High RTWP on


duration selected sites • HSUPA scheduling target is 12 dB
• During peak (20 dB to 30 dB noise rise):
o Class 16 range (-86 dBm <=RTWP< -83 dBm): 99% of time above
Sites serving o Class 17 range (-83 dBm <=RTWP< -80 dBm): 70% of time above
Mass Event o Class 18 range (-80 dBm <=RTWP< -75 dBm) : 5% of time above
• UL power out of control
• Average R99 DL power reached 43 dBm (maximum cell
power 44.8 dBm)

Distribution over a busy cell


DL power
consumed by R99
Dominant
RTWP class

For internal use


10 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
MBB solution for Mass Event Main Menu
Radio Part

MBB solution for


Mass Event

Static Solution Dynamic Solution

Parameter Tuning: Feature Activation:


• UL AC parameter optimization • Mass Event Features
• Mass Event Technical Notes • Load related features

For internal use


12 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Global Solution Main Menu
Product line recommendations

Technical Note 159:


o NSN recommended parameter for admission control and packet scheduling functionalities.
o It is used to improve AC and PS functionalities in loaded networks
o TN159 parameter values are divides to:
• General settings
• Mass Event settings
o Values were optimized in NSN laboratories and live pilot networks.
o All values should be adopted locally by the radio network planners when local conditions
are known

Technical Note 137:


o Describes an improvement of original Admission Control (AC)
implementation
o New functions are controlled with the PRFILE parameter switches
o Most of the modifications are done in order to mitigate AC failure
rate increase

For internal use


13 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Product line recommendations Main Menu
Overview

Uplink noise level and interference margin Target for the total wideband interference

Initial SIR Target for the UL DPCCHs Wait time in RRC Connection Reject

RRM Uplink DCH Activity Factors Initial Bit Rate parametrization

Uplink NRT DCH overload control Packet Scheduling settings

For internal use


14 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Global Solution Main Menu
Uplink noise level and interference margin

• Wrong PrxNoise causes error in power estimation algorithms


99.5% of PrxNoise values
(PIE/PDE) - casing power spiking in the UL spectrum. under autotuning range
• Activation of auto tuning algorithm is recommended (stricter policy

Cell Count
can be applied in loaded HSPA cells)
• Increase of DeltaPrxMaxdown gives faster decrease of the Mean = ~ -104.9 dBm
interference
• During Mass Event throughput based RRM should be used, to
avoid as heavy noise rise due to RACH. TN159 Recommended
MO Class Abbreviated name Default value value
WCEL PrxNoise -105.0 dB -105.0 dB
Lmin_cell
WCEL PrxNoiseMaxTuneAbsolute Not limited 2 dB

WCEL DeltaPrxMaxUp 1.2 dB 1.2 dB

WCEL DeltaPrxMaxdown 0.8 dB 2 dB

WCEL PrxLoadMarginDCH 2 dB 2 … 5.8 dB


PrxTarget
TN159
Legacy
PRFILE Recommended Comment
DeltaPrxMaxUp setting
value
DeltaPrxMaxdown RN40_MAINT_013 PrxNoise autotuning without
Bit9 = 1 Bit9 = 0
(007:0283) CELL_DCH traffic
PrxLoadMarginDCH
RN40_MAINT_013 PrxNoise autotuning in
∆L Bit10 = 1 Bit10 = 0
(007:0283) unloaded cell

PrxNoise RN40_MAINT_013
Bit13 = 1 Bit13 = 0
PrxTarget/PrxTotal reference
(007:0283) for DeltaPrxMaxUp

For internal use


15 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Global Solution Main Menu
Target for the total wideband interference power

Lmin_cell Max load for HSUPA scheduling TN159 Recommended


MO Class Abbreviated name Default value
value
PrxMaxTargetBTS WCEL PrxMaxTargetBTS 6 dB 8 dB
In normal case should be
> PrxTarget + PrxOffset WCEL PrxTarget 4 dB 12 dB

WCEL PrxTargetPSMin 4 dB 12 dB
PrxTarget
WCEL PrxTargetPSMax 4 dB 12 dB

• System has been designed based upon the assumption


that PrxMaxTargetBTS > PrxTarget and
PrxTargetPS
PrxNoise
• If PrxMaxTargetBTS < PrxTarget and PrxTargetPS
Mass Event Configuration and the RNC schedules DCH, then the Node B will not
PrxTarget / PrxTargetPS have resources to allocate for HSUPA:
o RNC does not check resources available for HSUPA
PrxMaxTargetBTS when allocating an HSUPA connection
o Connections can be allocated HSUPA but then be
Node B has no
Resource allocated by resources to unable to transfer any data
RNC allocate
o Connections will be released due to low utilization or
throughput, and will be moved to CELL_FACH

For internal use


16 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Global Solution Main Menu
Initial SIR Target for the UL DPCCHs

MO TN159
Abbreviated name Default value
RTWP classes Class Recommended value
decrease WRAB SIRDPCCHInitialDCHHS4 12 dB 9 dB
25 – 30
dB spike WRAB SIRDPCCHInitialDCHHS8 11 dB 8 dB
WRAB SIRDPCCHInitialDCHHS16 10.5 dB 7.5 dB

1-2 dB WRAB SIRDPCCHInitialDCHHS32 9 dB 6 dB


base load WRAB SIRDPCCHInitialDCHHS64 7.5 dB 4.5 dB
WRAB SIRDPCCHInitialDCHHS128 7.5 dB 4.5 dB
WRAB SIRDPCCHInitialDCHHS256 7.5 dB 4.5 dB
Too high initial power for the RL causing WRAB SIRDPCCHInitialDCHOffset 0 dB -2 dB
high power spiking PRFILE Default TN159 Comment
Channel type switch to
DCH is not triggered due
RN40_MAINT_014 Bit0 = 0 Bit0 = 1
to UL SIR error
measurement

• Initial SIR target for the UL DPCCHs are used for


uplink transfer direction
• Reduction in uplink load level (better HSDPA call
Slight decrease of
setup success rate), not just spiking
MAC-hs efficiency • Slight increase of the E-DCH re-transmission rate
CQI decoding
fails increase
• HSDPA throughput is impacted, lower UL DPCCHs
power levels may cause CQI decoding errors

For internal use


17 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Global Solution Main Menu
Wait time in RRC Connection Reject

RU20 / RU30 RU40


Abbreviated name TN159
MOC Default MOC Default SRNC
UE
WaitTimeRRCconversational RNC / RNAC 3s WAC 3s 4s
WaitTimeRRCstreaming RNC / RNAC 3s WAC 3s 4s RACH: RRC CONNECTION
T300 REQUEST
WaitTimeRRCinteractive RNC / RNAC 5s WAC 8s 8s start

WaitTimeRRCbackground RNC / RNAC 5s WAC 8s 8s


WaitTimeRRCsubscribed
RACH: RRC CONNECTION
RNC / RNAC 3s WAC 3s 8s T300 REQUEST
WaitTimeRRCemergency RNC / RNAC 1s WAC 1s 1s stop

WaitTimeRRCinterRATreselection RNC / RNAC 3s WAC 3s 8s FACH: RRC CONNECTION REJECT


WaitTimeRRCregistration RNC / RNAC 1s WAC 5s 8s
WaitTimeRRChighPrioritySignalling RNC / RNAC 1s WAC 1s 8s WaitTimeRRC
WaitTimeRRClowPrioritySignalling RNC / RNAC 5s WAC 5s 8s RACH: RRC CONNECTION
REQUEST
WaitTimeRRCunknown RNC / RNAC 1s WAC 1s 8s
WaitTimeRRCother
FACH: RRC CONNECTION REJECT
RNC / RNAC 0s WAC 0s 8s

• After expiration of WaitTimerRRC another RRC


• RRC Connection Request message:
Connection Request is sent
o Timer T300 (default = 2s) is started
• RRC Connection Reject message not received: • RRC Connection Request is retransmitted maximum N300
o Wait upon Timer T300 expired times (default = 3)
o RRC Connection Request message retransmission • If all RRC Connection Requests retransmission fail, UE
• RRC Connection Reject message received: waits T3211 and restarts procedure.
o Timer T300 is stopped
• Increased wait time in RRC connections setup decreases
o The message includes the mandatory Wait time IE,
the WaitTimeRRC is started rush in the RACH.

For internal use


18 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Global Solution Main Menu
RRM Uplink DCH Activity Factors

power power TN159


MO Class Abbreviated name Default value Recommended
max planned power max planned power value

max planned load

max planned load


WBTS RRMULDCHActivityFactorCSAMR 50 % 50 %
∆LAF90% RRMULDCHActivityFactorPSBackgr
∆LAF50% WBTS 95 % 50 %

WBTS RRMULDCHActivityFactorPSStream 95 % 50 %

∆LREAL ∆LREAL WBTS RRMULDCHActivityFactorPSTHP1 95 % 50 %

∆LAF90% > ∆LREAL RRMULDCHActivityFactorPSTHP2


load ∆LAF90% ~ ∆LREAL load WBTS 95 % 50 %

WBTS RRMULDCHActivityFactorPSTHP3 95 % 50 %

• Activity Factor describe the average utilization of the of the UL DCH


• AF = 1 worst case scenario, overestimation of the every individual user
impact capacity reduction
• AF < 1, closer to the real situation of discontinuous activity (typical in
interactive services)
• Lower AF values give:
o Lower estimated load,
o more allocations are allowed where the actual traffic is low but RTWP is high
(less rejection rates)
o Improved call setup success rate
• Too low value of the AF will underestimate the impact of every user
• Wrong load estimations and indirect this may impact on Setup fail UL DCH
For internal use
19 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Global Solution Main Menu
Initial Bit Rate parametrization

PBS: Priority based scheduling TN159


MO
Overload FLXU: Flexible upgrade Abbreviated name Default value Recommended Other
Class
Load Margin EOLC: Enhanced Overload value
control
PS5: Inactivity  RRC state RNC/
Normal load transition RNHSPA / HSDPAinitialBitrateUL 64 kbps 16 kbps
WAC
Allocated bit rate PS4 PS5 RNC/
RNHSPA / HSDPAminAllowedBitrateUL 64 kbps 16 kbps
PS2 PS3
Max. bit rate WAC
8 kbps
WCEL InitialBitRateUL 64 kbps -
PS1 16 kbps

Initial bit rate WCEL MinAllowedBitRateUL 8 kbps - 8 kbps


AC
Minimum bit rate
Actual throughput
PBS FLXU EOLC FLXU
64 min, 128 initial

• Lower values allow more capacity but user throughput is more limited. 64 LminDCH or
64 (PrxTarget and LmaxDCH)
• Modifications can improve the: 64
128 64
o Success ratios of the PS call setups 128 64
o PS session setups, 64
64
o HSDPA Resource Retainabilities for the PS NRT calls 128 64 64
128 128
• In congestion PBS candidates are prioritized: 64
64 64
o PS NRT DCHs with higher than initial bit rate users, in the QoS priority order.
256 128 128 128
o PS NRT DCHs with higher than min bit rate users, in the QoS priority order. 64 64
o Finally the minimum bit rate users, in the QoS priority order.

For internal use


20 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Global Solution Main Menu
Uplink NRT DCH overload control and PS parametrization

bit rate WCEL:OCULNRTDCHGrantedMinAllocT Overload detection


RU20
TN159
/RU30
Abbreviated name Default value Recommended
MO
value
Class
DL DCH Allocation The DCH modification is not allowed
for NRT RB Bit rate upgraded due to LoadControlPeriodPS timer
WCEL OCULNRTDCHGrantedMinAllocT 10 s 20 s
WBTS:LoadControlPeriodPS
WBTS SchedulingPeriod 100 ms 100 ms
Initial bit rate
WBTS LoadControlPeriodPS 2000 ms -
Min allowed bit
rate
RNC TrafVolPendingTimeUL 2s 8s

time RNC /RNPS CrQueuingTimeUL 4s -


Bit rate decreased due to overload. Bit rate decreased and SF increased, RL
WBTS:SchedulingPeriod TFC subset method is used. RL reconfiguration is used (or switched to
reconfiguration is not allowed. CCH)

• In overload TFC is used at first (it is faster and more reliable)


Transport Channel
Traffic Volume • Upon OCULNRTDCHGrantedMinAllocT expires, the RL
(= UE Buffer Load) reconfiguration is allowed on NRT DCH when an E-DCH MAC-d flow
No report Report2
is established in the cell.
Report1
• Higher timer value increases the probability of TFC procedure usage
• Shorter SchedulingPeriod improves the accuracy of the resource
allocation decisions of the PS interactive and background services
• TrafVolPendingTimeUL increased pending time helps to reduce
the number of capacity requests that the RNC has to process
time
TrafVolPendingTimeUL

For internal use


21 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
RAN2879 Mass Event Handler
RAN2954 Voice Call Prioritization
RAN1202 24 kbps PCH
RAN2480 Automatic Access Class Restriction

For internal use


22 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Features for mass events Main Menu
Overview

Mass Event Handler Voice Call Priorization


Solution to improve UL performance for mass events Solution to improve Voice performance for mass events
Increased TVM pending time Enhanced Admission Control for Voice users
Temporary maximum bit rate for UL DCH
Temporary maximum number of HSUPA users
Increased CQI feedback cycle
Load based E-DCH 2 ms TTI prevention
UL load based AC for HSPA+ features RU30 EP2 RU40
24 kbps PCH Automatic Access Class Restriction
Solution to improve paging performance for mass events Solution to prevent overload in network
Due to High received total wideband power
Due to Increased length of the NRT scheduling queue
Due to CN specific overload received by the RNC
Due to RNC overload trigger due to failed RNTI allocation
RU20 RU40

For internal use


23 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
RAN2879

For internal use


24 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Mass Event Handler in brief Main Menu
RAN2879 Mass Event Handler

Increased TVM pending time Increased CQI feedback cycle


Temporary maximum bit rate for UL DCH
Triggered by number of HSDPA users MEHHSDPAUserNbrCQI
Temporary maximum number of HSUPA users Decreases number of CQI sent in UL
Decreases load in UL
Triggered by number of users in PS NRT queue MEHQueueThreshold May affect HSDPA performance
Decreases load generated in UL
May affect HSUPA cell throughput

UL load based AC for HSPA+ features Load based E-DCH 2 ms TTI prevention

Triggered by number of HSPA users MEHULLHSDPAUALimit Triggered by number of HSUPA users MEHHSUPAUserNbr2msTTI
Limits number of HSPA+ users Limits number of HSUPA 2ms users
Decreases load generated in UL Decreases load generated in UL

Each functionality can be enabled and parameterized separately


Before activating Mass Event Handler values from Technical Note 159 should be reverted to
General TN159 settings (not TN159 Mass Event settings)
For internal use
25 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Mass Event Handler Main Menu
Increased TVM pending time, Temporary maximum bit rate for UL DCH, Temporary maximum number of HSUPA users

Functionalities activated:
Increased TVM pending time - Increased TVM pending time
- Temporary maximum bit rate for UL DCH
MEHTVMPendingTime used instead of 18.0 - Temporary maximum number of HSUPA users
TrafVolPendingTimeUL and TrafVolPendingTimeDL
16.0
Temporary maximum bit rate for UL DCH Functionalities stopped

Bitrate for UL DCH restricted to 14.0


HSDPAminAllowedBitrateUL, MinAllowedBitRateUL, MEHLoadStateTtT 2 * MEHLoadStateTtT

Scheduling queue
HSDPAMinBRULStrNrt 12.0
timer timer
MEHQueueThreshold
Temporary maximum number of HSUPA users 10.0

Number of HSUPA users restricted to MEHMaxHSUPAUsers 8.0


Restored to original value with MEHHSUPAUserIncr per
second 6.0
Sub-functionality not recommended if TN159 HSUPA
initial SIR target improvements and HSUPA low bit rate 4.0
optimized power offsets are already introduced
2.0
Triggered by queue length determined by MEHQueueThreshold
Decreases load generated in UL 0.0
Time [s]
May affect HSUPA cell throughput

Abbreviation MOC Range Default


MEHQueueThreshold WCEL 0..20, step 1 10
MEHLoadStateTtT WCEL 0..900 s, step 1 s 30s
MEHTVMPendingTime RNPS 250 ms, 500 ms, 1000 ms, 2000 ms, 4000 ms, 8000 ms, 16000 ms 8000 ms
MEHMaxHSUPAusers WCEL 0..128 users, step 1 users 10 users
MEHHSUPAUserIncr RNHSPA 1..10 users, step 1 user 1 user
For internal use
26 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Mass Event Handler Main Menu
Increased CQI feedback cycle

Increased CQI feedback cycle 18


Feedback cycle increased from 4ms to value of
MEHCQIFeedbackCycle 16

14
Triggered by number of HSDPA users MEHHSDPAUserNbrCQI

#HSDPA users
Decreases number of CQI sent in UL
12
Decreases load in UL
May affect HSDPA performance MEHHSDPAUserNbrCQI
10

2 Normal Increased Normal


CQI reporting cycle CQI reporting cycle CQI reporting cycle
0
MEHCQIFeedbackCycle Time [s]
used
Abbreviation MOC Range Default
MEHCQIFeedbackCycle RNHSPA 4 ms, 8 ms, 10 ms, 20 ms 8 ms
MEHHSDPAUserNbrCQI WCEL 0..128 users, step 1 user 10 users

For internal use


27 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Mass Event Handler Main Menu
UL load based AC for HSPA+ features

UL load based AC for HSPA+ features


Users not allowed to be configured with DC-HSDPA, 50
MIMO or DC-HSDPA with MIMO
Instead users will be configured with Single Carrier only
40
Triggered by number of HSPA users MEHULLHSDPAUALimit

#HSPA+ users
Limits number of HSPA+ users MEHULLHSDPAUALimit
Decreases load generated in UL 30

20

DC-HSDPA, Only Single Carrier allowed DC-HSDPA,


10
MIMO and MIMO and
DC-HSDPA+MIMO DC-HSDPA+MIMO
allowed for new users allowed for new users
0
Time [s]

Abbreviation MOC Range Default


MEHULLHSDPAUALimit WCEL 1...512, step 1 30 users

For internal use


28 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Mass Event Handler Main Menu
Load based E-DCH 2 ms TTI prevention

Load based E-DCH 2 ms TTI prevention


35
Users not allowed to be configured with 2ms TTI
Instead users will be configured with 10ms HSUPA only
30

Triggered by number of HSUPA users MEHHSUPAUserNbr2msTTI


25
Limits number of HSUPA 2ms users

#HSUPA users
Decreases load generated in UL
MEHHSUPAUserNbr2msTTI
20

15

10

5
2 ms TTI 2ms TTI not allowed for 2 ms TTI
allowed new HSUPA users allowed
0
Time [s]

Abbreviation MOC Range Default


MEHHSUPAUserNbr2msTTI WCEL 0..128 users, step 1 user 20 users

For internal use


29 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Mass Event Handler Main Menu
Temporary maximum bit rate for UL DCH - impact

Temporary maximum bit rate for UL DCH MEH activation

More users are allocated with lower UL


DCH for busy hour after Mass Event
Handler implementation
More PS8 and PS16 are allocated
Load generated in UL is expected to be
lower
With same load in UL more users can be
allocated

For internal use


30 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Mass Event Handler Main Menu
Increased CQI feedback cycle - impact

MEH implemented
Increased CQI feedback cycle

No significant difference is observed


during low and medium load hours
Number of reported CQIs is decreased
during highest load
Reduced number of CQIs impact UL load
During busy hour this sub-functionality can
significantly help high UL load

For internal use


31 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Mass Event Handler Main Menu
Temporary maximum number of HSUPA users - impact

Temporary maximum number of HSUPA users MEH activation MEHLoadStateTtT = 10s

HSUPA accessibility increased for busy


hour after Mass Event Handler
implementation
Less users are configured with HSUPA
Further optimization can be done by
decreasing MEHLoadStateTtT
parameter, triggering HSUPA limitation
faster

Implementing MEH with


MEHLoadStateTtT parameter tuning
reduces HSUPA allocation thus HSUPA
Accessibility is significantly improved

For internal use


32 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Mass Event Handler Main Menu

HSUPA Failures decreased for busy hour MEH activation MEHLoadStateTtT = 10s
after Mass Event Handler
implementation
Further optimization can be done by
decreasing MEHLoadStateTtT
parameter, triggering HSUPA limitation
faster
Decreased MEHLoadStateTtT can
additionally improve HSUPA failure rate

For internal use


33 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
RAN2954

For internal use


34 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Voice Call Prioritization Main Menu

Voice Call Prioritization during High Traffic Load NEW target for AC for voice users

VCP starts at PtxTarget – VCPPtxOffset level


VCP stops below PtxTarget – VCPPtxOffset level if PtxTarget + PtxOffset

PtxNC – DL non-controllable load


VCPHSDPAPrevDuration timer expires
New Admission Control target for Voice users
PtxTarget + PtxOffset PtxTarget
Number of HSDPA users restricted to
VCPMaxHSDPAUsers
Restored to original value with VCPHSDPAUserIncr per PtxTarget - VCPPtxOffset
second VCPHSDPAPrevDuration VCPHSDPAPrevDuration
timer timer

Allows automatic control of the HSDPA traffic load on high loaded cells
Improved call success rate for AMR users accessing the network during
the mass event Number of HSDPA users restricted to
May affect HSDPA cell throughput VCPMaxHSDPAUsers

Time [s]
Abbreviation MOC Range Default
VoiceCallPriority WCEL 0 (Disabled), 1 (Enabled) 0
VCPHSDPAPrevDuration RNHSPA 1.. 120 s, step 1 s 10 s
VCPMaxHSDPAUsers WCEL 0..128 users, step 1 user 30 users
VCPHSDPAUserIncr RNHSPA 1..10 users, step 1 user 1 user
VCPPtxOffset WCEL 0..6 dB, step 0.1 dB 0 dB
For internal use
35 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
36
92.00
96.00
98.00

88.00
90.00
94.00
102.00

100.00
03.27.2013 22:00:00
03.28.2013 12:00:00
03.29.2013 02:00:00
03.29.2013 16:00:00

For internal use


03.30.2013 06:00:00
03.30.2013 20:00:00

1st red bar

4th red bar


3rd red bar
2nd red bar
03.31.2013 10:00:00
04.01.2013 00:00:00
Voice traffic impact

04.01.2013 14:00:00
04.02.2013 04:00:00
04.02.2013 18:00:00
04.03.2013 08:00:00
04.03.2013 22:00:00
04.04.2013 12:00:00
04.05.2013 02:00:00

© Nokia Solutions and Networks 2014


04.05.2013 16:00:00
04.06.2013 06:00:00

Action taken
04.06.2013 20:00:00
04.07.2013 10:00:00
04.08.2013 00:00:00
04.08.2013 14:00:00
04.09.2013 04:00:00
Voice Call Prioritization

04.09.2013 18:00:00
04.10.2013 08:00:00

VCPMaxHSDPAUsers = 70
04.10.2013 22:00:00
04.11.2013 12:00:00
04.12.2013 02:00:00
04.12.2013 16:00:00
CSSR AMR Voice

04.13.2013 06:00:00

Initial implementation of RAN2594,


04.13.2013 20:00:00

TrafVolPendingTimeUL/DL = 8s
04.14.2013 10:00:00
04.15.2013 00:00:00
04.15.2013 14:00:00
04.16.2013 04:00:00
0
20000
40000
60000
80000
100000
120000
140000
160000

RAB att Voice RNC_229a


CSSR Voice, (RRC+CU) RNC_5093b

10.00
20.00
25.00
35.00

15.00
30.00

0.00
5.00

03.27.2013 21:00:00
VCPMaxHSDPAUsers 30, VCPHSDPAPrevDuration 30s, VCPHSDPAUserIncr 1/s

03.28.2013 10:00:00
03.28.2013 23:00:00
03.29.2013 12:00:00
03.30.2013 01:00:00
03.30.2013 14:00:00
03.31.2013 03:00:00
03.31.2013 16:00:00
04.01.2013 05:00:00
VCPMaxHSDPAUsers 45, VCPHSDPAPrevDuration 30s => 10s, VCPHSDPAUserIncr 1/s => 2/s

04.01.2013 18:00:00
04.02.2013 07:00:00
04.02.2013 20:00:00
04.03.2013 09:00:00
04.03.2013 22:00:00
04.04.2013 11:00:00
Result

04.05.2013 00:00:00
04.05.2013 13:00:00
04.06.2013 02:00:00
04.06.2013 15:00:00
MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014

04.07.2013 04:00:00
04.07.2013 17:00:00
04.08.2013 06:00:00
04.08.2013 19:00:00
04.09.2013 08:00:00
04.09.2013 21:00:00
04.10.2013 10:00:00
04.10.2013 23:00:00
04.11.2013 12:00:00
AMR CSSR slightly decreased

04.12.2013 01:00:00
No further change in AMR CSSR
No further change in AMR CSSR

04.12.2013 14:00:00
AMR CSSR significantly improved
RRC voice call, setup failures

04.13.2013 03:00:00
04.13.2013 16:00:00
04.14.2013 05:00:00
04.14.2013 18:00:00
04.15.2013 07:00:00
04.15.2013 20:00:00
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
20000

FR RNC_2498a
Att failed RNC_2499a
Main Menu
Voice Call Prioritization Main Menu
Voice traffic impact

(M1001C80)
RAB_CS_Voice_Establishment_Failure_Rate ( with causes)
RAB_STP_FAIL_CS_VOICE_AC RAB_STP_FAIL_CS_VOICE_BTS RAB_STP_FAIL_CS_VOICE_TRANS
RAB_STP_FAIL_CS_VOICE_RNC RAB_STP_FAIL_CS_VOICE_FROZBS RAB_STP_FAIL_CS_VOICE_LIC
RAB_ACC_FAIL_CS_VOICE_MS RAB_ACC_FAIL_CS_VOICE_RNC RAB_CS_Voice_Establ_FR

35000 2.0
VCP
1.8
30000

RAB CS Voice Setup FR [%]


1.6
~ 1.36 %
25000 1.4
1.2
20000
1.0
15000
0.8
~ 0.58 %
10000 0.6
0.4
5000
0.2
0 0.0
3-Jun-13

4-Jun-13

5-Jun-13

6-Jun-13

7-Jun-13

8-Jun-13

9-Jun-13

10-Jun-13

11-Jun-13

12-Jun-13

13-Jun-13

14-Jun-13

15-Jun-13

16-Jun-13

17-Jun-13

18-Jun-13

19-Jun-13

20-Jun-13

21-Jun-13

22-Jun-13

23-Jun-13

24-Jun-13
For internal use
37 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
38
Axis Title

20
40
60
80

0
100
120
03.27.2013 22:00:00
03.28.2013 12:00:00
03.29.2013 02:00:00
03.29.2013 16:00:00
03.30.2013 06:00:00
03.30.2013 20:00:00
03.31.2013 10:00:00
04.01.2013 00:00:00

For internal use


04.01.2013 14:00:00

1st red bar

4th red bar


3rd red bar
2nd red bar
04.02.2013 04:00:00
04.02.2013 18:00:00
04.03.2013 08:00:00
04.03.2013 22:00:00
Packet traffic impact

04.04.2013 12:00:00
04.05.2013 02:00:00
04.05.2013 16:00:00
04.06.2013 06:00:00
04.06.2013 20:00:00

© Nokia Solutions and Networks 2014


04.07.2013 10:00:00

Action taken
04.08.2013 00:00:00
04.08.2013 14:00:00
04.09.2013 04:00:00
04.09.2013 18:00:00
04.10.2013 08:00:00
04.10.2013 22:00:00
Voice Call Prioritization

04.11.2013 12:00:00

VCPMaxHSDPAUsers = 70
04.12.2013 02:00:00
04.12.2013 16:00:00
04.13.2013 06:00:00
04.13.2013 20:00:00
04.14.2013 10:00:00

Initial implementation of RAN2594,


HSDPA session setup success rate

TrafVolPendingTimeUL/DL = 8s
04.15.2013 00:00:00
04.15.2013 14:00:00
04.16.2013 04:00:00
0
500000
1000000
1500000
2000000
2500000
3000000

HSDPA att RNC_926b


HSDPA stp SR RNC_914c

Axis Title
20
40
60
80

0
100
120

03.27.2013 21:00:00
03.28.2013 10:00:00
03.28.2013 23:00:00
03.29.2013 12:00:00
VCPMaxHSDPAUsers 30, VCPHSDPAPrevDuration 30s, VCPHSDPAUserIncr 1/s

03.30.2013 01:00:00
03.30.2013 14:00:00
03.31.2013 03:00:00
03.31.2013 16:00:00
04.01.2013 05:00:00
04.01.2013 18:00:00
04.02.2013 07:00:00
04.02.2013 20:00:00
VCPMaxHSDPAUsers 45, VCPHSDPAPrevDuration 30s => 10s, VCPHSDPAUserIncr 1/s => 2/s

04.03.2013 09:00:00
04.03.2013 22:00:00
04.04.2013 11:00:00
04.05.2013 00:00:00
04.05.2013 13:00:00
04.06.2013 02:00:00
Result

04.06.2013 15:00:00
04.07.2013 04:00:00
04.07.2013 17:00:00
04.08.2013 06:00:00
04.08.2013 19:00:00
MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014

04.09.2013 08:00:00
04.09.2013 21:00:00
04.10.2013 10:00:00
04.10.2013 23:00:00
04.11.2013 12:00:00
04.12.2013 01:00:00
04.12.2013 14:00:00
Packet Session setup success rate

04.13.2013 03:00:00
04.13.2013 16:00:00
04.14.2013 05:00:00
04.14.2013 18:00:00
HSDPA max users failures improved
HSDPA max users failures improved

04.15.2013 07:00:00
04.15.2013 20:00:00
HSDPA resource accessibility improved
HSDPA resource accessibility improved
Packet session setup success rate normal
0

HSDPA resources accessibility deterioration


500000
1000000
1500000
2000000
2500000
3000000

HSDPA max users failures improved to normal level


HSDPA resource accessibility improved to normal level
SR RNC_916b
Att RNC_930b
Main Menu
RAN1202

For internal use


39 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
24 kbps PCH Main Menu
Brief description

PCH allocated to its own SCCPCH


PCH message block increased from 80bits to 240bits
PCH bitrate increased from 8kbps to 24kbps DTCH DCCH CCCH BCCH PCCH
Up to 4 .. 6 paging records can be now included in paging
message Logical channel
SCCPCH load can is decreased for Mass Events
Paging success rate is increased for high paging load which
occurs for Mass Events
FACH-u FACH-c PCH
NOTE: 15 HS-PDSCH codes cannot be used when HSUPA 24 kbps PCH
2 ms TTI is enabled with 24 kbps PCH
Transport channel

SCCPCH 1 SCCPCH 2
SF 64 SF 128
Physical channel

Abbreviation MOC Range Default


PCH24kbpsEnabled WCEL 0 (Disabled), 1 (Enabled) 0

For internal use


40 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
24 kbps PCH Main Menu
Paging success rate for 8kbps PCH

VLR Paging Success Rate vs. PCH Throughput


Max PCH capacity
• For 8kbps max=100 msg/s
• For 24kbps max=400..600 msg/s

Paging Success Rate [%]


Paging Success Rate drop noticed if PCH
load >50%
• For 8kbps 50 msg/s
• For 24kbps 200..300 msg/s

PCH Throughput [bps]

For internal use


41 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
24 kbps PCH Main Menu
Paging success rate with 24 kbps PCH

24 kbps PCH feature activation cause


significant paging success rate Paging Success Rate per LAC
PCH messages mapped to separate 100
SCCPCH don’t have to share resources 99
with FACH messages
98
Even ~5 more paging records can be sent
in one message it significantly increase 97

success rate event in quite loaded 96


networks
95

94
Diagram proves feature efficiency
93

92

91

90

1.12

2.12

3.12

4.12

5.12

6.12

7.12

8.12

9.12
29.11

30.11

10.12

11.12

12.12

13.12

14.12

15.12

16.12

17.12

18.12

19.12
For internal use
42 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
24 kbps PCH Main Menu
Paging messages per paging

24 kbps PCH feature activation cause


significant change in paging messages Paging messages per paging
1.7
per paging (paging repetition factor)
Paging is sent more efficient, less 1.6
repetitions are needed
1.5

1.4
Clear benefit from applying 24 kbps PCH
is observed 1.3

1.2

1.1

1.0

For internal use


43 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
24 kbps PCH Main Menu
PCH load

Sites with 24kbps PCH enabled


24kbps PCH 8kbps PCH
experience lower PCH load
Sites with 24kbps PCH disabled
experience higher PCH load
Further PCH load optimization can be
achieved with inactivity timers change
Success probiability higher with lower load

Clear gain can be observed from PCH load


point of view after 24kbps PCH enabling

For internal use


44 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
RAN2480

For internal use


45 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Automatic Access Class Restriction Main Menu
RAN2480 Automatic Access Class Restriction

UL overload detection in the cell due to NRT UL overload detection in the cell due to
scheduling queue length Received total wideband power (PrxTotal)

Triggered by scheduling queue length (higher than MEHQueueThreshold) Triggered by level of RTWP (PrxTotal)

RNC overload trigger OVERLOAD message from CN

Triggered by number S-RNTI allocation failed Triggered by core network overload - RANAP:Overload message

Each functionality can be enabled and parameterized separately

For internal use


46 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Automatic Access Class Restriction Main Menu

In severe overload conditions the access to the network is limited for a number of UE access classes to reduce load
The access class for every ordinary UE is randomly chosen digit from range between 0 and 9 and it is stored in the (U)SIM card
Number of access classes is automatically and dynamically set to a barring state due to overload from the following triggers: Barred AC
• High received total wideband power
• Increased length of the NRT scheduling queue
• CN specific overload received by the RNC
• RNC overload trigger due to failed RNTI allocation
The access restriction level is cell based and depends from the trigger and for which domain (PS or CS) the access restriction level is raised
The number of access classes which are restricted is automatically increased or decreased as the overload condition continues or relaxes Public Subscribers
The feature is particularly beneficial during mass events, so when there are many subscribers in a small area

Overload detected and Overload continues Barred Access Classes are cycled to avoid specific Overload recovers so the
one Access Class so the number UE from being barred for long periods of time number of barred Access
barred of barred Access
Classes is reduced and released
Classes is increased

- Emergency Calls
- PLMN Use
- Security Services
- Public Utilities
- Emergency Services
- PLMN Staff

For internal use


47 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Automatic Access Class Restriction Main Menu
Access Classes

Access Class barring is applied to appropriate area, e.g. cell level if there is high uplink noise or RNC level if
there is core network overload SIB3 with AC pattern
All UEs read general Access Class barring instructions within SIB3
These instructions bar the UE from accessing the system for both CS and PS connections RNC
Release 6 and newer UE support Domain Specific Access Class Restriction Lists (for PS and CS
separately)
UE read SIB3 (access class patterns) in Idle Mode, CELL_FACH, CELL_PCH and URA_PCH states
UE checks restrictions before it makes new RRC connection
UE checks DSAC restriction before it makes new connection to the certain CN domain (REL6 or newer UEs)

Abbreviation MOC Range Default


AutoACResEnabled RNFC Bit 0: Received total wideband power 0b00000000
Bit 1: NRT scheduling queue length
Bit 2: CN overload,
Bit 3: RNC overload
CN
AutoACDSACRestriction WCEL Restrict CS and PS domain (0) Restrict PS domain (1)
Restrict PS domain (1)
Restrict CS domain (2)
Restrict PS domain and Cell Access (3)
Restrict CS domain and Cell Access (4)
Restrict PS and CS domain and Cell Access (5)
Cell Access Restriction (6) RNC

Setting relevant for Rel6 and newer UEs Setting relevant for Rel5 and older UEs
SIB3 with AC pattern

For internal use


48 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Introduction Main Menu
UL overload detection in the cell due to NRT scheduling queue length

Cell specific overload can be triggered by NRT scheduling queue 20

Restriction level is increased by one access class every 18


AutoACRLevelUpdInt if NRT scheduling queue is constantly longer
than MEHQueueThreshold over AutoAcIncRestHysNRTQ time 16
Restriction level is decreased by two access classes every

NRT Scheduling queue length


AutoACRLevelUpdInt if NRT scheduling queue is constantly shorter
14
than MEHQueueThreshold over AutoACDecRestHysNRTQ time AutoAcIncRestHysNRTQ AutoACDecRestHysNRTQ
If none of conditions above are met then restriction level is sustained timer (default 30s) timer (default 20s)
12
MEHQueueThreshold
AutoACMaxRestLevel controls highest possible restriction level
RestrictionInterval is used to cycle barred access classes 10

6
Increase the current Decrease the current
4 Restriction level by one Restriction level by
step if not yet reached two steps if not yet
AutoACMaxRestLevel reached 0
2

0
Abbreviation MOC Range Default Time [s]
AutoACMaxRestLevel RNAC 10...90 %, step 10 % 90%

AutoAcIncRestHysNRTQ RNAC 5...60 s, step 1 s 30s

AutoACDecRestHysNRTQ RNAC 5...60 s, step 1 s 20s

AutoACRLevelUpdInt RNAC 10...600 s, step 1 s 30s

For internal use


49 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Introduction Main Menu
UL overload detection in the cell due to Received total wideband power (PrxTotal)

Cell specific overload can be triggered by RTWP (PrxTotal)

Restriction level is increased by one access class every


AutoACRLevelUpdInt if RTWP (PrxTotal) is constantly greater than
PrxMaxTargetBTS + AutoACResULOLThr over
AutoACIncRestHysRTWP time

Total wide band power [dBm]


Restriction level is decreased by two access classes every
AutoACRLevelUpdInt if RTWP (PrxTotal) is constantly lower than AutoACIncRestHysRTWP AutoACDecRestHysRTWP
PrxMaxTargetBTS + AutoACResULOLThr over timer (default 30s) timer (default 20s)
AutoACDecRestHysRTWP time PrxMaxTargetBTS
If none of conditions above are met then restriction level is sustained + AutoACResULOLThr

AutoACMaxRestLevel controls highest possible restriction level


RestrictionInterval is used to cycle barred access classes

Increase the current Decrease the current


Restriction level by one Restriction level by
step if not yet reached two steps if not yet
AutoACMaxRestLevel reached 0

Abbreviation MOC Range Default Time [s]


AutoACResULOLThr WCEL -5...25 dB, step 0.1 dB 5dB

AutoACIncRestHysRTWP RNAC 5...60 s, step 1 s 30s

AutoACDecRestHysRTWP RNAC 5...60 s, step 1 s 20s

For internal use


50 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Introduction Main Menu
RNC overload trigger

The access class restriction level is defined based on failed S-RNTI allocation requests in RNC/mcRNC/ADA
Information about the number of successful/failed S-RNTI allocations is calculated by the RNC each AutoACRLevelUpdInt/2
seconds called Reporting Period (default 15 s)
The following conditions must be fulfilled during two consecutive reporting periods to trigger the Automatic Access Class
Restriction procedure due to RNC overload:
• 100 or more S-RNTI allocation attempts per UE traffic handling unit in RNC
UE BTS RNC
• S-RNTI allocation failure rate is above the AutoACRTrigRNCLoad threshold (default 10%)
• the abovementioned failure rate is true for at least half of the total number of UE traffic handling units RRC: Connection Request
If the above conditions are fulfilled, the RNC defines the access class restriction level as described in the below table

S-RNTI
allocation
failed

RRC: Connection Request Reject


Average S-RNTI
10..20% 20..30% 30..40% 40..50% 50..60% 60..70% 70..80% 80..90% 90..100%
failure rate
Access Class
Restriction Level 10% 20% 30% 40% 50% 60% 70% 80% 90%

Abbreviation MOC Range Default


AutoACRTrigRNCLoad RNAC 10...90 %, step 1 % 10%

AutoACIncRestHysRTWP RNAC 5...60 s, step 1 s 30s

AutoACDecRestHysRTWP RNAC 5...60 s, step 1 s 20s

For internal use


51 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
Introduction Main Menu
OVERLOAD message from CN

The CN domain specific access class restriction level is defined based on received „step” in „overload” messages
from CN
The steps are converted to the access class restriction level as included into the below table
RNC CN
RANAP: Overload
If step info is not provided via RANAP: Overload message the timers TigOR and TinTR are utilized by RNC
When TigOR is running the „overload” messages are ignored by RNC TigOR and TinTR
started
When TinTR expires, current overload step is decreased (if not yet 0) RANAP: Overload

RANAP: Overload
ignored

TigOR expiry
RANAP: Overload

„step” is converted
Both timers restarted by CRM

TinTR expiry

Step in Overload
message from CN 1 2 3 4 5 6 7 8 9...16
„step” is converted
Access Class by CRM
Restriction Level 10% 20% 30% 40% 50% 60% 70% 80% 90%

For internal use


52 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
53
counter

For internal use


Trial results

impacting accessibility KPIs

© Nokia Solutions and Networks 2014


Highest number occurs on cells most exposed to increased load
Depending on site different number of access classes is blocked
Diagram presents number of access classes blocked during mass event
Average number of access classes blocked by this feature can be derived from M1000C405

Users with blocked assess class are not sending RRC connection request message and are not

Average number of blocked access classes


1.0
2.0
3.0
4.0
5.0
6.0
8.0

0.0
7.0

0:00 20.07.2013
1:30 20.07.2013
3:00 20.07.2013
4:30 20.07.2013
6:00 20.07.2013
7:30 20.07.2013
9:00 20.07.2013
Cell 3
Cell 2
Cell 1

10:30 20.07.2013
12:00 20.07.2013
MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014

13:30 20.07.2013
15:00 20.07.2013
16:30 20.07.2013
18:00 20.07.2013
19:30 20.07.2013
21:00 20.07.2013
22:30 20.07.2013
0:00 21.07.2013
1:30 21.07.2013
3:00 21.07.2013
4:30 21.07.2013
6:00 21.07.2013
7:30 21.07.2013
9:00 21.07.2013
10:30 21.07.2013
12:00 21.07.2013
13:30 21.07.2013
15:00 21.07.2013
16:30 21.07.2013
18:00 21.07.2013
19:30 21.07.2013
21:00 21.07.2013
22:30 21.07.2013
0:00 22.07.2013
1:30 22.07.2013
Main Menu

3:00 22.07.2013
4:30 22.07.2013
6:00 22.07.2013
For internal use
54 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014
References Main Menu
Mass Event solution

Feature name Link to materials

https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/482850967
RAN2879 Mass Event Handler
https://sharenet-ims.inside.nokiasiemensnetworks.com/Overview/D490345188
https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/494879100
RAN2954 Voice Call Prioritization
https://sharenet-ims.inside.nokiasiemensnetworks.com/Overview/D502946553

RAN2480 Automatic Access Class Restriction https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/493374487

For internal use


55 © Nokia Solutions and Networks 2014 MBB CS Network Engineering / Bartosz Bieda & Michał Barański / 14.04.2014