Signaling Storm Solution

Security Level:
10/7/16
Smartphone Signaling
Storm Solution Training
www.huawei.com
HUAWEI TECHNOLOGIES CO., LTD.
Huawei Confidential
HSDPA
Solution Introduction
Smartphone Signaling Storm Assessment
Smart phone Signaling Storm Optimization
Case Study
Page 2
What is Signaling Storm
What is the signaling storm

Smartphone signaling requests are more than resource capacity of the current
network , leading to network congestion, snow-collapsing effect , and the network
unavailable
Resources including RNC SPU and PIU board, NodeB CNBAP and the SGSN
signaling processing board.
Which scene will trigger the signaling storm:

The increasing of Push Mail, SNS, blog, IM, browsing webpage, downloading , ondemanding video applications and so on.
Special events
How to deal with the signaling storm :

Smartphone signaling storm: assessment service, Huawei's signaling storm
solutions such as CELL_PCH and EFD features, resource expansion , RNC and
NodeB software upgrade
Special events: the integration of RNC and NodeB flow control, AC access
restrictions, the board flow control and other ways
Page 3
How to define Smartphone?

Based on User Behavior:
Users who initiate PS Session times more than 10 times per hour
Based on Operation System of the terminal:

Terminal using IOS, Android, RIM, Symbian, WM/WP7, WebOS smartphone operating
system
Page 4
Smartphone Power Saving Explode Signaling

Storm 1
Battery life is a key issue for Smartphone
Fast dormancy was introduced to save UE power but lead to more signaling
Fast dormancy function has been introduced to some

smartphones, such as iPhone OS3.0, Nokia N97 etc. to allow UEs
releasing Iu signaling connection and change to Idle mode ASAP to
save power
Traffic
Time
Without
Fast dormancy:
1 time data connection, few signaling
Short
battery life
Frequent connection, more signaling
Long
battery life
With
Fast Dormancy:
IDLE status (idle mode), UE power consumption < 5mA

CELL_DCH status (connect ion mode ), UE power consumption
> 200mA
HUAWEI TECHNOLOGIES CO.,

LTD.
HISILICON SEMICONDUCTOR
Page 5
Heart Beata Different Behavior of Smart Phone 2

Information updating
For Push Type Messages
1
2
3
iPhone
Apple Push Server
No Service
Service Client Service Server
MSN
Facebook
Twitter
iPhone
Every 10-15 minutes,

heart beat with apple
push server
5- 6s
Every 55 - 60
seconds
Every 50 seconds,
interaction with
twitter.com
HTC
Android
No heart beat
40-60s
User setting (in service client on

terminal)
The Heart Beats of smart phones are actually caused by

Services
LTD.
Page 6
Traffic Mode Benchmark of different Operators
Operator
RNC ID (measure in BH)
Smart phone penetration rate
User Number
Operator V in E.U. B in N.A. E in Asia
3021
8%
47786
PS
0.9322
PS Call times per User
2.4567
Total PS Throughput (kbps) per User
PS RAB Number
PS Call Duration (s)
AMR Traffic (Erl) per User
AMR Call Times per User
AMR Holding Time (s)
329
20%
49979
1.6139
5.9095
1789.692
1200.6320
4
82.3071 80.0488
CS
0.0053
0.0217
0.2128
0.7758
76.3465 78.026
3511
95%
168510
2303
>100%
23538
5.2965
0.9975
5.3452
58.18
19139.12 9449.6254
78.2447 270.3761
0.0322
0.0045
0.6487
0.02
134.8078 653.143
Signaling requirement increases more rapidly than data traffic with

smart phone increasing
LTD.
Page 7
Huawei Systematic Solution To Tackle Signaling Storm

Long-term Solution
Short-term Solution
Network
Evaluation
Resource & Capacity

Evaluation
Resource & Capacity

Optimization
RNC Resource Adjustment

NodeB Resource Adjustment
Smartphone Evaluation
Transmission Resource
Adjustment
Network Traffic Model
Evaluation
Analysis &
Prediction
Smartphone Historical
Trend Analysis
Capacity Enhancement
(Products)
Smartphone Traffic Model

Prediction
Capacity Enhancement
(Features)
Smartphone penetration
Forecast
Stability Enhancement
Expansion Suggestion in Small scale

Network Performance
Evaluation
Hardware & Software Capacity

Enhancement
Network resource
Prediction with
Smartphone development
Smart Signaling Optimization
Network Resource & Capacity Monitoring and Performance Assurance

LTD.
Network
Development Plan
Page 8
Smartphone Signaling Storm Solution

Introduction
Module
Content
Signaling Storm Assessment

Terminal Capability(DPA/UPA/GSM)
Terminal Model Penetration(Model/Brand/IOS)
Smartphone Terminal Model Penetration(per-R8/R8)
Terminal Evalution Terminal KPI Assessment
Terminal Traffic Model Assessment
Terminal Capability(EFACH/ERACH/CPC)
Cellpch/FD/EFD Feature Gain Assessment
RNC SPU/PIU
NODEB CNBAP
FACH/PCH Utility Audit
Resource & Capability URA Feature Gain Audit
RNC SPU/PIU Forecast(Consider Smartphone Penetration
Evaluation
Growth)
NODEB CNBAP Forecast(Consider Smartphone Penetration
Growth)
FACH/PCH Utility Forecast(Consider Smartphone
Penetration Growth)
Multi-Carrier Strategy Audit
Performance
Multi-RAB Service Audit(After CELLPCH/FACH Activation)
Evaluation
Result verification
Signaling Storm Optimization
EFD Feature
FD/EFD Feature Introduction
Introduction
Multi-RAB CS Service Quality Improvement
Smart Phone Feature
Smartphone Fast State Transition
Introduction
URA Planning

LTD.
RNC Version
Solution
Version
ALL
Later
Later
Later
Later
Later
Later
ALL
ALL
ALL
Later
V1R1
V1R1
V1R1
V1R1
V1R1
V1R2
V1R2
V1R1
V1R1
V1R1
V1R2
than
than
than
than
than
than
R11
R12
R11
R12
R12
R12
than R12
ALL
V1R2
ALL
V1R2
ALL
V1R2
ALL
Later than
R12SPC518
V1R1
Later than R12
V1R1
Later than R12

Later than R14
Later than R12
V1R2
V1R2
V1R2
Page 9
V1R2
HSDPA
Smart Phone Signaling Storm Optimization
Case Study

LTD.
Page 10
Page 10
Smartphone Signaling Storm Assessment Process -1

Tasks:
Check CN IMEI Reporting Configuration
Activate RNC IMEI Report Switch
Collect the Data
Post-Process Data
Provide Terminal Capacity Analysis
Provide Smart Phone Analysis
Prepare the Terminal Capability Evaluation
Report
Submit the Terminal Capability Evaluation
Report
Tools
OMSTARV5R6
Smartphone Signaling Storm Assessment Process -2

Tasks:
Perform Smart Phone Penetration Audit

Perform Smart Phone SCRI Behavior Audit
Perform Smart Phone PS RAB frequency
Audit
Perform RNC SPU Load Audit
Perform RNC PIU Load Audit
Perform NodeB CPU Load Audit
Perform Common Channel Utility Audit
Perform TOP N Smart Phone Traffic
Model Audit
Perform Solution Gain Prediction
Perform
Perform
Perform
Perform
SPU Gain Prediction

PIU Gain Prediction
NodeB CPU Load Prediction
Common Channel Utility Prediction
Tools
OMSTARV5R6
Smartphone Penetration
Apple, RIM and Nokia are the TOP 3
Smartphone.
Smartphone Definition
UEs complying with 3GPP Release 8 support the fast dormancy

function, as defined in 3GPP TS 25.331 CR3483.
R8 fast dormancy: This mechanism is standardized by 3GPP

Release 8. UE sends a SIGNALLING CONNECTION
RELEASE INDICATION (SCRI) message to the network with
the IE Signaling Connection Release Indication Cause set to
UE Requested PS Data session end.
--The RNC can identify this type of UE by the SCRI message
with IE UE Requested PS Data session end.
Pre-R8 fast dormancy: This mechanism, which is not
standardized, is the early proprietary implementations of fast
dormancy prior to Release 8. UE sends SCRI without the IE
Signaling Connection Release Indication Cause for fast
dormancy.
-- The RNC can identify this type of UE by its IMEI.
Smart Phone definition: UE group has the

capability of sending SCRI
Operator O Smartphone Penetration

Apple
21%
49%
5% 7%
9%
9%
RIM
Nokia
HTC
Samsung Korea
Others
Apple, RIM and Nokia are the TOP 3

Smartphone in the Network (RNC3901).
Smartphone Behavior Analysis -1

Device Type Distirbution
Device Type PS RAB ACCESS
SmartPhone
Behavior
2%
28%
SmartPhone
Behavior
1% 5%
General UE
General UE
Dongle
Dongle
70%
94%
* Smartphone behavior is defined as 2 Times PS

RAB Access in an Hour
Device Type PS Traffic Volume
*Dongle is included in Smartphone
Device Type CS Erlang
SmartPhone
Behavior
41%
51%
7%
General UE
SmartPhone
Behavior
51%
49%
Dongle
General UE
Dongle
28% Smartphone Behavior UEs generate 94% of total PS Access, 51% of total PS Traffic. 2% Datacard
generate 41% of the total PS traffic .

Smartphone Traffic Model Comparison
* iPhone includes iPhone4 and other iPhone models.
RIM
1.17
HTC
0.88
Motorola
0.92
IPhone4
Sony Ericsson
IPhone
Nokia
0.00
16.47
16.69
5.01
11.89
Sony Ericsson
11.17
1.18
14.82
15.00
20.00
0.00
64.80
24.36
73.49
16.91
68.18
24.08
73.14
21.57
Nokia
10.00
63.43
20.44
IPhone
2.43
0.94
68.39
15.27
IPhone4
3.34
5.00
HTC
Motorola
1.36
0.66
RIM
20.00
68.91
40.00
60.00
times
CS RAB ACCESS per user
PS RAB ACCESS per user
CS Call Duration per CS Call
PS Duration per PS Call
RIM, HTC and Iphone have the most PS RAB Access per user, and HTC and RIM have
relative low penetration rate in the Network (RNC3501).
80.00
second

Smartphone Traffic Model Comparison shows iPhone users have higher PS RAB times
per user compared with other UE.
UE Device
Total RRC
CS RAB
Total User
Access
ACCESS
Number
(Times)
per user
PS RAB
SHO
HHO
CS Call
PS
DL PS
UL PS
DCCC
ACCESS ATTEMPT ATTEMPT
Duration Duration Traffic per Traffic per
REQUEST
per user
S
S
per CS Call per PS Call user(KB) user(KB)
Nokia
158381
24966
0.94
2.43
201839
1141
46974
68.91
21.57
1499.37
129.47
IPhone
165787
11283
1.18
11.17
295007
3939
83629
73.14
24.08
5362.29
663.79
Sony
Ericsson
62353
7217
0.66
3.34
61357
498
10481
68.18
16.91
1044.06
84.47
IPhone4
99328
6480
1.36
11.89
103840
20056
73.49
24.36
5942.60
752.12
Motorola
56088
6232
0.92
5.01
74464
707
21067
64.80
20.44
1692.83
472.42
HTC
90421
4282
0.88
16.69
105429
1970
21070
63.43
15.27
3656.53
486.69
RIM
42868
2107
1.17
16.47
46243
802
13521
68.39
14.82
743.13
102.87
Dongle
45127
2511
15.90
58049
1198
116185
68.56
85478.20
9003.39
* Traffic Model calculation is based on Busy Hour Data
Smartphone Network Resource

Consumption
PS RAB increase will cause:
The impact on the core network
Signaling load increase on the core network
The impact on the RAN side
Signaling load increase On SPU
Signaling load increase on PIU board
CNBAP(signaling load) increase on NodeB
Paging channel utilization increase
Smartphone Network Resource Consumption
Smartphone Resource Consumption

100.00%
90.00%
80.00%
70.00%
60.00%
50.00%
40.00%
30.00%
20.00%
10.00%
0.00%
96.38%
86.27%
71.35%
28.65%
17.14%
13.39%
PIU
Smartphone
3901
13.02%
3.52%
SPU
RNCID
86.85%
81.86%
ULPower DLPower
Cong
Cong
Times
Times
5122
91
DPU
CNBAP
General UE
ULCE
Cong
Times
DLCE
Cong
Times
CODE
Cong
Times
1093
11
DLIUBBa ULIUBBa
nd Cong nd Cong
Times
Times
Assess the resource consumption of Smartphone, predict the gain after

Smartphone storm solutions apply, provide the suggestion of expansion.
Penetration
12
Smartphone Network Resource Consumption SPU-1

Key Signaling Messages affect SPU Load:
SMS
AMR Call (R99)
PS Call (R99)
PS Call (HSPA)
Soft Handover Addition
Soft Handover Deletion
-SPU
Softer Handover
Addition
Softer Handover Deletion
DCCC
Hard Handover
Smartphone Network Resource Consumption SPU-2

RNC SPU Signaling Consumption rules: (based on
PCHR)
Signaling Message
Traffic Model Calculation
R11
R12_A
R12_B
SMS
Call Count - CS_RAB_TIMES - PS_RAB_TIMES
0.90000%
1.02700%
1.07500%
AMR Call (R99)
CS_RAB_TIMES
1.97000%
2.18300%
2.55900%
PS Call (R99)
PS_RAB_TIMES* counter VS.RAB.AttEstab.PSR99/
3.20000%
2.18300%
2.55900%
PS_RAB_TIMES*{(RAB.AttEstabPS.Conv+RAB.AttEstabPS.Bgrd+RAB. 3.20000%
2.32700%
2.84600%
0.52000%
0.64400%
0.79100%
0.26000%
0.32200%
0.32400%
(RAB.AttEstabPS.Conv+RAB.AttEstabPS.Bgrd+RAB.AttEstabPS.Intv+R
AB.AttEstabPS.Strm)
PS Call (HSPA)
AttEstabPS.Intv+RAB.AttEstabPS.Strm-VS.RAB.AttEstab.PSR99))/
(RAB.AttEstabPS.Conv+RAB.AttEstabPS.Bgrd+RAB.AttEstabPS.Intv+R
AB.AttEstabPS.Strm)
ucStatShoAttTimes* {(VS.SHO.AttRLAdd-VS.SoHO.AttRLAdd)/
(VS.SHO.AttRLAdd-VS.SoHO.AttRLAdd +VS.SHO.AttRlDelVS.SoHO.AttRlDel)
ucStatShoAttTimes* (VS.SHO.AttRlDel-VS.SoHO.AttRlDel)/
(VS.SHO.AttRLAdd-VS.SoHO.AttRLAdd +VS.SHO.AttRlDelVS.SoHO.AttRlDel)
Softer Handover Addition
ucStatShoerAttTimes* (VS.SoHO.AttRLAdd /(VS.SoHO.AttRLAdd
0.35000%
0.45700%
0.60800%
+VS.SoHO.AttRlDel))
ucStatShoerAttTimes* (VS.SoHO.AttRlDel/(VS.SoHO.AttRLAdd
0.17000%
0.24000%
0.24800%
DCCC
+VS.SoHO.AttRlDel))
ucDcccUpRateReqTimes ucDcccDownRateReqTimes
0.80000%
0.85600%
1.01600%
Hard Handover
ucStatIntraFreqHhoReqTimes ucStatInterFreqHhoReqTimes
0.66000%
0.66000%
0.85700%
Smartphone Network Resource Consumption PIU-1
Key Signaling Messages affect PIU Load

SMS
AMR Call (R99)
PS Call (R99)
PS Call (HSPA)
DCCC
Hard Handover
Smartphone Network Resource Consumption PIU-2

RNC PIU Signaling Consumption rules: (based on
PCHR)
PIU Consumption dimension
SMS
Call Count - CS_RAB_TIMES - PS_RAB_TIMES
AMR Call (R99)
CS_RAB_TIMES
PS Call (R99)
PS_RAB_TIMES
PS Call (HSPA)
Same as PS R99
ucStatShoAttTimes* {(VS.SHO.AttRLAdd-VS.SoHO.AttRLAdd )/
((VS.SHO.AttRLAdd-VS.SoHO.AttRLAdd )+(VS.SHO.AttRlDelVS.SoHO.AttRlDel))}
ucStatShoAttTimes* {(VS.SHO.AttRlDel-VS.SoHO.AttRlDel)/
((VS.SHO.AttRLAdd-VS.SoHO.AttRLAdd )+(VS.SHO.AttRlDelVS.SoHO.AttRlDel))}
DCCC
ucDcccUpRateReqTimes+ucDcccDownRateReqTimes
Hard Handover
Default setting in tool: 500 times/ single CPU board
Smartphone Network Resource Consumption CNBAP-1

NODEB CNBAP Capability:
Counter:
Counter:
PCHR
VS.IUB.AttRLSetup
VS.IUB.AttRLAdd
VS.IUB.AttRLRecfg
CNBAP= ((VS.IUB.AttRLSetup +
VS.IUB.AttRLAdd + VS.IUB.AttRLRecfg
*{2})/{3600})
UE Handover times
PS RAB Attempts
CS RAB Attempts
UE DCCC Times
PCHR
UE consumed CNBAP= UE Handover
times + PS RAB Attempts *3 + CS RAB
Attempts *3+ UE DCCC Times *2 /3600
Assessment Result Summary

According to the penetration assessment result, provide the conclusion if the signaling
solution can be applied to the current network.
Smartphone behavior Analysis
According to the traffic model analysis result,

provide the signaling storm optimization
solutions(the right figure). For example, PCH
could be applicable to all the UE with PS RAB
number>2/hour and FD is only applicable to
R8 terminal EFD is only applicable to all the
Iphone.
Smartphone Network resource

Consumption
According to the Smartphone network resource

consumption analysis, provide the predicted
gain of the optimization solutions.
HSDPA
-PCH/FD/EFD
Case Study
Page 25
Signaling Storm Optimization Delivery WorkflowPCH/FD/EFD

Tasks:
Perform Live Network Evaluation
Perform Multi-Carrier Strategy
Analysis
Perform KPI Impact Evaluation
Perform Risk Analysis
Present the Risk Analysis Result to the

customer
Perform configuration verification
Ensure Lab readiness
Activate the Cell FACH/PCH
Activate the FD/EFD Feature
Perform first RNC implementation
Update IUPS activation factor
Add the second SCCPCH
Activate CELL_PCH feature
Activate EFD Feature
Roll out
Perform KPI Monitoring
Service Acceptance
PCH/FD/EFD Key technology What is Fast

Dormancy
UEs complying with 3GPP Release 8 support the fast dormancy function, as defined in 3GPP
TS 25.331 CR3483.
R8 fast dormancy: This mechanism is standardized by 3GPP Release 8. UE sends a
SIGNALLING CONNECTION RELEASE INDICATION (SCRI) message to the network with the IE
Signaling Connection Release Indication Cause set to UE Requested PS Data session
end.
--The RNC can identify this type of UE by the SCRI message with IE UE Requested PS Data
session end.
Pre-R8 fast dormancy: This mechanism, which is not standardized, is the early proprietary
implementations of fast dormancy prior to Release 8. UE sends SCRI without the IE Signaling
Connection Release Indication Cause for fast dormancy.
-- The RNC can identify this type of UE by its IMEI.
Page 27
PCH/FD/EFD Key technology UE States

Cell-DCH
In active state
Communicating
via
its
dedicated
channels
UTRAN knows which cell UE is in.
Cell-FACH
In active state
Few data to be transmitted both in
uplink and in downlink. There is no
need to allocate dedicated channel for
this UE.
Cell-PCH
No data to be transmitted or
received.
Monitor PCH, to receive its paging.
lower the power consumption of UE.
IDLE
Cell_PC
Cell_P
H
CH
Low
loa
d
high
load
Cell_DCH
Cell_FACH
Medium
load
IDL
E
Page 28
PCH/FD/EFD Key Technology White List/Black List

IMEI TAC White List and Black List
1. White List
2. Black List
EFD only applied to

those specific UE types
in the list
UE types are defined by
TAC which is in IMEI
EFD only applied to

those specific UE types
NOT in the list
UE types are defined
by TAC which is in IMEI
Cons:
Cons:
The solution gain

depends on the ratio of
UEs defined in the list
Higher risks of UE
compatibility
White list and black list only apply to Pre-R8 fast dormancy UE
29
PCH/FD/EFD Solution - CELL PCH

Scenario
1. Applicable to all UE reducing the PS RAB frequent access for UE without
SCRI.
2. Applicable to RNC version later than R11 (including R11)
Cell PCH solution
PCH/FD/EFD Solution - CELL PCH Gain

UE transition from dedicated Channel to Common Channel will save the
signaling messages. The graphs below show the number of signaling
messages before and after feature activation.
P2F2D2F2P
D2IDLE2D
P2F2P
Page 31
Cell_PCH & Cell FACH State Transition
Cell_PCH & CELL_FACH is defined

in 3GPP R99.
Huawei realized them in RAN 2.0

before Year 2006.
en D2F/F2P/F2D state transition happens, the signaling is RB re-configu
en P2F state transition happens, the signaling is cell-update;
Page 32
Parameters related to CELL_PCH

Parameter ID
D2F2PTvmThd
D2FTvmTimeToTrig
Explanation
Purpose:
This parameter is the threshold to decide whether 4B event should be reported.
How it works:
When the UE is on CELL_DCH and its traffic volume is lower than this parameter, D2FTvmTimeToTrig timer starts.
Purpose:
This parameter is designed to prevent unnecessary 4B event report when UE is on DCH, caused by traffic volume
variation.
How it works:
This timer starts immediately when the UE traffic volume is below the D2F2PTvmThd.
During the period it sets, there are two scenarios according to the traffic volume of the UE:
UE traffic volume is always below D2F2PTvmThd until it expires, 4B event is reported immediately when it
expires.
When UE traffic volume is higher D2F2PTvmThd at some time before it expires, this timer will reset and
UE is still on CELL_DCH.
Purpose:
This timer is designed to monitor whether the UE traffic volume is always lower than D2F2PTvmThd before UE
transfer from CELL_DCH to CELL_FACH
How it works:
This timer starts immediately when D2FTvmTimeToTrig expires.
BeD2FStateTransTimer
UE traffic volume is always below D2F2PTvmThd until it expires, UE is transferred from Cell_DCH to
Cell_FACH.
UE traffic volume is higher D2F2PTvmThd before it expires, this timer will reset and UE is still on
CELL_DCH.
Page 33
Parameters related to CELL_PCH
Parameter ID
Explanation
Purpose:
This parameter is designed to prevent unnecessary 4B event report when UE is on Cell_FACH, caused by traffic volume
variation.
How it works:
F2PTvmTimeToTrig
When the traffic volume is 0, this timer starts.
During the period before it expires, there are two scenarios according to the traffic volume of the UE:
UE traffic volume is always below 0, 4B event is reported immediately when it expires.
UE traffic volume is higher 0 at some time before it expires, this timer will reset and UE is still on Cell_FACH.
Purpose:
This parameter is designed to monitor whether the UE traffic volume is always 0 before UE transfer from Cell_FACH to
Cell_PCH
How it works:
BeF2PStateTransTimer
This timer starts immediately when F2PTvmTimeToTrig expires.
UE traffic volume is always below 0 until it expires, UE is transferred from Cell_FACH to Cell_PCH.
UE traffic volume is higher 0 before it expires, this timer will reset and UE is still on Cell_FACH
PsInactTmrForInt/
PsInactTmrForBac
Purpose:
This parameter is designed to monitor whether the UE traffic volume is always 0 before UE transfer to idle.
How it works:
When UE that has interactive class data service/ background class data service stops data transfer, this timer starts.
During the period before it expires, there are two scenarios according to the traffic volume of the UE:
UE traffic volume is always below 0, UE is transferred to idle status when it expires.
UE traffic volume is higher 0 at some time before it expires, this timer will reset and UE is still on its original status
(CELL_DCH or Cell_FACH).
Page 34
PCH/FD/EFD Solution-CELL-PCH State Transition

Parameters
Notes on Timer Explanation
4B event will not be reported immediately when UE traffic volume is

lower than the D2F2PTvmThd or zero. Only when UE traffic volume is
always lower than D2F2PTvmThd or zero for a period, which is set by
D2FTvmTimeToTrig or F2PTvmTimeToTrig respectively , 4B event is
reported.
For simplicity, in this document, we use D2F Timer and F2P Timer
(defined as below)to describe the principles Cell_PCH works. Pleased be
noticed that there are no timer named D2F Timer or F2P Timer in our
system.
D2F Timer = D2FTvmTimeToTrig+ BeD2FStateTransTimer
F2P Timer = F2PTvmTimeToTrig+ BeF2PStateTransTimer
If the D2F Timer or F2P Timer is too low, it may misjudge whether the UE
traffic volume meets the condition for state transition. If the D2F Timer
or F2P Timer is too high, more UE stay at Cell_DCH or Cell_FACH state.
The timers should be set according to actual BE service model.
Page 36
PS_RAB_TIMES Gain CELL-PCH

Maximum Gain of PS_RAB_TIMES (Ratio) =
[PS_RAB_TIMES(Smartphone, before CELL_PCH)

-SCRI_TIMES(Smartphone) - PS_RAB_TIMES(Smartphone, after
CELL_PCH)]
PS_RAB_TIMES(all)
PS_RAB_TIMES(Smartphone, before CELL-PCH) : PS_RAB_TIMES@BH of Smartphone before launching

Cell_PCH
PS_RAB_TIMES(Smartphone, after CELL_PCH):
IMSI_Count ( Smartphone ) * 3600/ PS Inactive Timer
SCRI_TIMES(Smartphone) : SCRI_TIMES@BH of Smartphone; (which will not change after launching Cell_PCH)
PS_RAB_TIMES(all) : PS_RAB_TIMES of all phones in the RNC before launching Cell_PCH
Smartphone here means UEs PS_RAB_TIMES@BH is more than 10 times. Actual definition could vary in UEs
PS_RAB_TIMES@ BH.
If we define PS_RAB_TIMES@BH lower than 10 times as Smartphone, the estimated
gain will increase,
Factors for PS_RAB_TIMES Gain CELL-PCH
Actual Gain of PS RAB_TIMES is influenced by:

Factors
PS_RAB_TIMES Reduced
SCRI Penetration
Actual PS RAB Times @BH
Timer(all)
Long timer will increase risk of Cell_FACH / Cell_DCH Congestion, which
influence KPIs such as access success ratio, etc.
Factors for SPU Gain CELL-PCH

Maximum SPU Gain is influenced by:
Maximum PS_RAB_TIMES GAIN (Positive Gain)
SPU Breakdown Ratio by PS Access
CELL UPDATE (Negative Gain)
RB RE-CONFIGURATION ( Negative Gain)
From testing of networks that have launched CELL_PCH, it is

estimated that:
Maximum SPU Gain = Maximum PS_RAB_TIMES GAIN(ratio) / 5
Notes: The estimation method is summarized from networks with InactiveTimer
before launching CELL_PCH= 20s and the originally do not have EFD or
Cell_FACH.
Page 39
Maximum Gain Estimation vs. Tested Actual Gain in

Operator A&B
Tested Gain after Launching
Cell_PCH in Operator A
Tested Gain after Launching

Cell_PCH in Operator B
SPU LoadPS
9.27%
RAB
56.01
%
Maximum Gain Estimation after

Launching Cell_PCH in Telenor
SPU Load PS
RAB
3%
SPU Load
PS RAB
4.09%
20.45%
19%
Node B
Node B RNCSGSN/GGSN
RNCSGSN/GGSN
Node B RNCSGSN/GGSN
Cell_FACH is not activated on original network
Cell_FACH is activated on original network

D2F Timer = 20s
Inactive Timer = 60s
Cell_FACH is activated on original network

D2F Timer = 5s
Inactive Timer = 20s
Ratio of PS RAB
from Smartphone
@BH
Smartphone
Penetration
Cell_FACH Lauched
SCRI Ratio
PS RAB Gain
SPU Load
Gain
Telenor
75%
19%
40%
20.45%
4.09%
Operator A
82.07%
12.73%
26%
56.01%
9.27%
Operator B
35%
9%
63%
19%
-3%
The PS_RAB_TIMES GAIN and SPU GAIN for Operator A&B are tested value on the networks. The PS RAB GAIN & SPU
GAIN for Telenor is estimated value using the method described in page 37~page39, and is based on the data from RNC512
from Aug 31,2011~ Sep. 7, 2011.
PCH/FD/EFD Solution - R8FD

Scenario
1. Applicable to UE: R5-R8 with SCRI cause UE Requested PS Data session
end.
2. Applicable to RNC version later than V9R12
FD(Fast Dormancy) Solution
PCH/FD/EFD Solution-EFD
Scenario
1 Applicable to R8 UE and UEs in White List
2 Applicable to RNC version later than V9R12
EFD(Enhanced Fast Dormancy) Solution:
PCH/FD/EFD Solution EFD State Transition
When fast dormancy enhancement is not applied, the RRC connection of the UE is released
when the RNC receives the SCRI.
When fast dormancy enhancement is applied, the RNC can change the UE status to the
CELL_PCH /CELL-FACH state instead of idle mode.
Procedure
Procedure Comparison
Comparison
State
State Transition
Transition of
of Fast
Fast
Dormancy
Dormancy Enhancement
Enhancement
Page 43
PCH/FD/EFD Solution- R5-R8 UE

R8 and Pre-R8 Fast Dormancy UE Comparison
R8 Fast Dormancy
UE sends a SIGNALLING CONNECTION RELEASE INDICATION

(SCRI) message to the network with the IE Signaling
Connection Release Indication Cause set to UE Requested PS
Data session end .
RNC will transit UE state from CELL-DCH to CELL-FACH to CELLPCH.
Pre-R8 Fast Dormancy
R5 or R5 above UE sends a SIGNALLING CONNECTION RELEASE

INDICATION (SCRI) message to the network without any cause.
RNC will transit UE state from CELL-DCH to CELL-FACH to CELLPCH according to IMEI TAC white list or black list.
Other UE
UE sends a SIGNALLING CONNECTION RELEASE INDICATION
(SCRI) message to the network without any cause.
RNC will directly release this UE to IDLE
44
Parameters related to FD/EFD

Parameter ID
Explanation
Meaning: This parameter specifies the value of the CELL-DCH inactivity timer for UEs
enabled with the Fast Domancy feature. When detecting that the Fast Domancy User in
PsInactTmrFo PS domain had no data to transfer in CELL-DCH for a long time which longer than this
rFstDrmDch timer, the state transition from CELL-DCH to CELL-FACH or CELL-PCH is triggered. To
enable this timer, set this timer to a value other than 0.
Recommended Value: 5s
Meaning: This parameter specifies the value of the CELL-FACH inactivity timer for
UEs enabled with the Fast Dormancy feature. When detecting that the Fast Dormancy
PsInactTmrFo User in PS domain had no data to transfer in CELL-FACH for a long time which longer
rFstDrmFach than this timer, the state transition from CELL-FACH to CELL-PCH is triggered. To enable
this timer, set this timer to a value other than 0
Meaning: This parameter specifies the value of the CELL-PCH inactivity timer for UEs
enabled with the Fast Dormancy feature. When detecting that the Fast Dormancy User in
PsInactTmrFo
PS domain had no data to transfer in CELL-PCH for a long time which longer than this
rPreFstDrm timer, the UE is released. To enable this timer, set this timer to a value other than 0.
FastDormanc Meaning: This parameter specifies the threshold of the traffic volume of 4A event for
yF2DHTvmTh triggering the transition of fast dormancy user from FACH/E_FACH to DCH/HSPA.
Recommended Value: D1024
d
Page 45
PS_RAB_TIMES Gain EFD

Maximum Gain of PS_RAB_TIMES (Ratio) =
[PS_RAB_TIMES(Apple, before EFD) EFD)]
PS_RAB_TIMES(Apple, after
PS_RAB_TIMES(all)
PS_RAB_TIMES( Apple, before EFD) : PS_RAB_TIMES@BH of Apply IPhone before launching EFD
PS_RAB_TIMES(Apple, after EFD):
PS_RAB_TIMES(all) : PS_RAB_TIMES of all phones in the RNC before launching EFD
IMSI_Count ( Smartphone ) * 3600/ PS Inactive Timer
Factors for PS_RAB_Times Gain EFD

Actual Gain of PS RAB_TIMES is influenced by:
Factors
PS_RAB_TIMES Reduced
Apple Penetration
R8 UE Penetration
Actual PS RAB Times of Apple &
R8 UE @BH
Factors for SPU Gain EFD

Maximum SPU Gain is influenced by:
Maximum PS_RAB_TIMES GAIN (Positive Gain)
SPU Breakdown Ratio by PS Access
CELL UPDATE (Negative Gain)
RB RE-CONFIGURATION ( Negative Gain)
From testing of networks that have launched EFD, it is estimated

that:
Maximum SPU Gain = Maximum PS_RAB_TIMES GAIN / 5
Notes: The estimation method is summarized from networks that originally do
not activate Cell_FACH or Cell_PCH.
Page 48
Tested EFD Gain in Operator C vs. Estimated EFD Gain
Tested Gain Estimation after Launching EFD

in Operator C
RNC SPU Load
8.56
%
Node
B
RNC
Times of PS
Access
43.9
%
SGSNGGSN
R8 UE Penetration
Apple Penetration (Apple Excluded)
Operator C
15%
0%
Telenor
24%
0%
Maximum Gain Estimation after

Launching EFD in Telenor
RNC SPU Load
Node
B
Ratio of PS RAB
TIMES
of Apple & R8 UE
@BH
44%
58%
Times of PS
Access
9.29%
46.44%
RNC
SGSN GGS
N
PS RAB Gain
43.9%
iPhone
46.44%
SPU Gain
8.56%
9.29%
The PS_RAB_TIMES GAIN and SPU GAIN for Operator C are tested value on the network.
The PS RAB GAIN & SPU GAIN for Telenor is estimated value using the method described in page 45~page47, and is based on the data from
RNC512 from Aug 31,2011~ Sep. 7, 2011 , where the network does not have CELL_PCH.
PCH/FD/EFD Solution-KPI Monitoring

Name
KPI/Counter
Remark
VS.RRC.AttConnEstab.Sum
RRC.SuccConnEstab.sum
RRC Access
PS RAB
CS RAB
CellUpdt
Common Channel
CPU
State Transit
Radio Link
(CNBAP)
PS RAB Setup Success Ratio
(RNC)
PS Call Drop Ratio with PCH
(RNC)
(VS.RAB.AttEstabPS.Conv.
RNC+VS.RAB.AttEstabPS.Bk
VS.RAB.AttEstabPS.RNC
g.RNC+VS.RAB.AttEstabPS.I
nt.RNC+VS.RAB.AttEstabPS.
Str.RNC)
VS.RAB.AbnormRel.PS
CS RAB Setup Success Ratio
(RNC)
CS Service Drop Ratio (RNC)
VS.RAB.AbnormRel.AMR.RN
C
VS.AttCellUpdt
VS.FACH.DCCH.CONG.TIME
Congestion duration
VS.FACH.DTCH.CONG.TIME
VS.XPU.CPULOAD.MEAN
SPU UTILITY
VS.INT.CPULOAD.MEAN
PIU Utility
VS.DCCC.Succ.F2D
VS.DCCC.Succ.D2F
VS.DCCC.Att.F2P
VS.DCCC.Succ.F2P
VS.DCCC.P2F.Att
VS.DCCC.P2F.Succ
VS.IUB.SuccRLAdd
VS.IUB.SuccRLDel
VS.IUB.SuccRLRecfg
VS.IUB.SuccRLSetup
Key Monitoring Point

1.If PS RAB Access is reduced as
expectation;
2.If SPU load is reduced as
expectation
3.If CE utility is reduced as
expectation
4.If Multi-RAB Call drop times is
normal as expectation.
VS.LC.ULCreditUsed.Mean
Credit
VS.LC.DLCreditUsed.Mean
VS.MultiRAB.CSAbnormRel.C
SPS
VS.MultiRAB.CSNormRel.CS
PS
Multirab
VS.MultiRAB.AttEstab.CSPS
VS.MultiRAB.CSAbnormRel.P
HUAWEI TECHNOLOGIES
CO., LTD.
SAtt
HSDPA
Solution introduction
Smartphone signaling storm assessment
Smartphone signaling storm Optimization
- URA_PCH solution
Case study
Page 51
URA_PCH +layered Paging Solution - URA_PCH

Scenario
Applicable to the scenario
1 URA_PCH is the supplement of Cell_PCH . If the network with high
mobility UE adopts the Cell_PCH , the number of cell reselection will increase
and FACH channel load and SPU load will raise up.
2 After adopting the URA_PCH , paging times will increase significantly
contrasting to Cell_PCH. Therefore, it can reduce influence of paging in
URA_PCH adopting the two solutions below .
URA PCH +layered paging
Re-planning URA
3 Applicable to R14 and R14 later version
URA PCH + layered Paging Solution Principle
When adopting the URA_PCH + Layered

paging solution , if RNC page the UE which
is in the URA_PCH state . First RNC will find
out the latest camped-on cell and
neighboring cells under the same RNC.
Then send message of paging type1 at
these cells. If there is no response after a
period of time(about 1s), it will send
paging message in entire URA .
Page 53
URA PCH +layered Paging Solution-Parameter

Design
1. Activate URA_PCH layered paging feature license
2. Implement RNC command SET URRCTRLSWITCH, enable URA_PCH layered
paging switch
3. Disable L2 paging retransmission switch
4. Enable PS NRT state transfer switch
5. Set state transfer procedure(DF2U)
6. Set state transfer timer(FD&EFD are optional , if FD&EFD has been
activated ,it is essential to configure)
SET UPSINACTTIMER: PsInactTmrForInt=1800, ProtectTmrForInt=10,
PsInactTmrForBac=1800, ProtectTmrForBac=10,
PsInactTmrForPreFstDrm=1800(optional),
PsInactTmrForFstDrmDch=5(optional), PsInactTmrForFstDrmFach=5(optional);
URA PCH +layered Paging Solution -URA Re-planning

URA PCH layered paging risk
1. The network adopts the URA_PCH + layered paging solution . When the first
layer paging success rate is relatively low , the increase of air interface paging
times in PCH state is uncontrollable
2. The URA_PCH layered paging solution will increase user access time delay
about 1s.
Is there other solution to reduce air interface paging times or cell reselection?
Answer URA re-planning!
Value of this function:
1. It can reduce the UU paging times by using this function to plan the URA . The
benefit of paging channel is same with the layered paging (compare to the
network which has not enabled the PCH)
2. If the network has enabled Cell_PCH , the increase of air interface paging times
in PCH state is controllable contrasting to the layered paging.(the max value is N
times :N=the cell number of URA-1)
3. Dont increase the access time delay
Page 55
URA Re-planning
Planning design rules:
Specification
The product supports that the max URA number is 65535, the whole
network can be configured up to 65535
RNC supports the max cell number is 5100, and the max NodeB number
is 3060.
Rules
The protocol defines single cell can be configured up to 8 URA .
Only one URA can not be configured in one RNC, it may result in
waste of paging channel resource
URA can not cross the RNC, or it may result in paging failure
It should ensure cells with continuous coverage allocate the same
URA.
Control the number of URA updates.
Page 56
URA Re-planning
URA planning principle Every cell can be configured up to 8 URA ID , one
configures Primary URA ID seven configures Secondary URA ID
Primary URA ID planning algorithm :

Primary URA ID must be configured . Usable range is 0-65535
Each NodeB has one unique Primary URA ID in RNC. All the cells in one NodeB has
the same Primary URA ID. It suggest that every RNC distributes 1000 Primary URA
ID .
Page 57
URA Re-planning
URA planning principal Every cell can be configured up to 8 URA ID , one
configures Primary URA ID seven configures Secondary URA ID
Secondary URA ID planning Algorithm
Secondary URA ID Usable range is 0-65535

Every cell can configure up to 7 secondary URA ID . The current cell can select
primary URA ID of neighboring cell as the secondary URA ID.(Descending order
according to the number of occurrences of the Secondary URA ID. If the Primary
URA ID of current cell appears, it should be removed. If the primary URA ID of
neighboring RNC appears , it should be removed.)
Page 58
HSDPA
Smartphone signaling storm assessment
Smartphone signaling storm optimization
- Fast state transition and Smart P2D
Case study
Page 59
Fast state transition and Smart P2D solution

Applicable to the scenario
1. If Smartphone sends the SCRI message later or do not send SCRI
(greater than 10s of the D2F timer) even if there is no data to transmit
This causes the Smartphone to stay in the CELL_DCH state for a long
time, and waste the network resource.
The fast state transition enables
SCCPCH
the
High
Priority
Lo to CELL_FACH,
Smartphone to quickly
transit from
the CELL_DCH
CELL_PCH, or URA_PCH state in the preceding situation. It can save the
network resource.
Notes: applicable to the terminals which do not include white list and
do not send SCRI.
2 There is a severe FACH congestion in a live network. The Smart
P2D can be used to directly transit the state of a UE with high traffic
volume from CELL_PCH or URA_PCH to CELL_DCH. The UE does not
transmit data in the CELL_FACH state. This saves bandwidth resources
on the CELL_FACH, eases FACH congestion, and reduces the delay for
processing high traffic.
3 Applicable to the version-R14 and R14 after
60
Fast State Transition Solution
Design strategy
The DRA_SMART_FAST_STATE_TRANSFER_SWITCH
switch under DraSwitch
controls whether fast state transition is enabled. If this switch is turned on:
When the state of a Smartphone performing BE services changes from
CELL_DCH to CELL_FACH, the RNC records the time stamp as T1.
When the Smartphone state changes from CELL_PCH, URA_PCH, or CELL_FACH
back to
CELL_DCH, the RNC records the time stamp as T2.
The RNC then calculates the interval between T1 and T2. If this time interval is
greater than the value of TthdForSFSTUserIdentify, the RNC determines that the
Smartphone is capable of fast state transition during the subsequent procedure S2.
Smart P2D Solution
Design strategy
The DRA_PCH_UE_SMART_P2D_SWITCH
switch under DraSwitch
controls whether smart P2D is enabled.
If the amount of data transmitted by a UE four consecutive times
exceeds the value of TvmThdForSmartP2D, the RNC predicts that
the amount of data the UE will transmit subsequently will remain
above the value of TvmThdForSmartP2D. The RNC directly transit
the UE state to DCH.
If the amount of data transmitted by a UE four consecutive times is
less than or equal to the value of TvmThdForSmartP2D, the RNC
predicts
that the UE
HUAWEI
TECHNOLOGIES
CO.,has
LTD. a
small amount
of data to transmit
Fast state transition parameter design

TthdForSFSTUserIdentify
Parameter meaning Timer for determining whether a UE is capable of fast
state transition. If the interval between the time when a UE with best effort
(BE) services leaves the CELL_DCH state and the time when the UE reenters
the CELL_DCH state is greater than or equal to this threshold, the BSC6900
determines that the UE is capable of fast state transition.
Impact on Radio Network Performance A large value of this parameter
leads to few UEs capable of fast state transitions, which reduces the gain from
the fast state transition function. A small value of this parameter leads to
many fast state transitions, which increases the call drop risk and the central
processing unit (CPU) usage of signaling processing boards.
Recommended value 15s
TvmThdForSmartP2D:
Parameter meaning Load threshold for smart state transition from
CELL_PCH or URA_PCH to CELL_DCH. If a UE's data during each transition
exceeds this threshold, the BSC6900 transits the UE from CELL_PCH or
URA_PCH to CELL_DCH.
Recommended value 51
unit 10byte
Fast State Transition-KPI Monitoring

ID
Counter
Description
67199617
VS.MeanRTWP
Mean Power of Totally

Received Bandwidth for Cell
67199618
VS.MeanTCP
Mean Transmitted Power of

Carrier for Cell
67202902
Mean Non-HSDPA Transmitted

VS.MeanTCP.NonH
Carrier Power for Cell
S
67202567
Mean Usage of UL Credit for

VS.LC.ULCreditUs
Cell
ed.Mean
67202570
Mean Usage of DL Credit for

VS.LC.DLCreditUs
Cell
ed.Mean
73410510
VS.CellDCHUEs
73410511
VS.CellFACHUEs
73439971
73421934
Focus on monitoring
Whether Non-HSDPA power
, CE consumption is
decrease ,
P2D transition success
number change
Number of UEs in CELL_DCH

State for Cell
Number of UEs in CELL_FACH

State for Cell
Congestion Duration of
VS.FACH.DTCH.CO DTCHs Carried over FACHs for
NG.TIME
Cell
Number of Successful state
VS.DCCC.P2D.Succ transfer from CELL_PCH to
CELL_DCH for cell
Signaling Storm Optimization Solution

Summary
Solution name
CELL PCH
URA PCH
R8FD
Dependence
none
none
none
The introduction of
version
V9R012SPH226 and after
V900R14C00 and after
V9R012SPH226and after
Applicable
terminal
Negative influence
All terminal
Reduce PS RAB attempts

times (reduce SPU
load ,CNBAP,CE
Increase RB reconfigure
utilization and air
and cell reselection
interface resource
utilization) reduce paging
channel utilization
All terminal
decrease PS RAB
attempts( decrease SPU
load , CNBAP,CE
utilization and air
interface resource
utilization), decrease
paging channel utilization
Increase RB
reconfigure
Send SCRI message

with the cause,
decrease PS RAB
load , CNBAP,CE
utilization and air
interface resource
decrease PS RAB
load , CNBAP,CE
utilization and air
interface resource
EFD
none
V9R012SPH226and after
Send the SCRI

without cause.
Current Support
apple
Smart phone fast

State Transition
need to enable
CELL PCH or
URA PCH
V900R14C00 and after
Smart phone ( dont

send SCRI or send
SCRI later)
Main gain
Save dedicated resource

(power ,code ,CE )
No impact
Remark
Two solutions
URA PCH + layered paging
URA replanning
Currently, only support apple
Two solutions:
Fast state solution
Smart P2D solution
HSDPA
-Risk Analysis
Case Study
Page 66
Risk Analysis - FACH congestion

For every TTI (10ms), 2 PDU can be transferred on one
SCCPCH
If PCH and FACH share a SCCPCH, for every TTI, normally one PDU
for PCH and one PDU for FACH
SCCPCH SCCPCH
High
Priority
TF
PCH TB
Low
SIG FACH
Traffic
TB
FACH TB
Case1
Case2
Case3
Case4
Case5
Case6
67
Capacity of SCCPCH FACH and PCH share SCCPCH

PHY
CH
LOG
CH
TFS
SCCPCH8
FACH USER
Plane
PCH
FACH SIG Plane
0*240,
1*240
0*168, 1*168, 2*168 0*360, 1*360
TFCS
1:{0*240,
2:{1*240,
3:{0*240,
4:{1*240,
5:{0*240,
6:{0*240,
0*168,
0*168,
1*168,
1*168,
2*168,
0*168,
0*360}
0*360}
0*360}
0*360}
0*360}
1*360}
For every TTI 10ms, there are two TB (Transport Block)

If there is paging message, one TB is used by PCH
If one TB is used for PCH, another TB only can be used by SRB FACH
If no TB used for PCH
If there is RRC message, one or two TB can be used by SRB FACH
Otherwise (no PCH and no SRB FACH), TRB FACH can be
transferred
68
Capacity of SCCPCH 2nd SCCPCH for FACH

PHY CH
SCCPCH8
LOG CH
PCH
TFS
0*240,
1*240
TFCS
1:{0*240}
2:{1*240}
SCCPCH9
FACH USER
FACH SIG Plane
Plane
0*168, 1*168,
0*360, 1*360
2*168
1:{0*168,
2:{1*168,
3:{2*168,
4:{0*168,
0*360}
0*360}
0*360}
1*360}
For every TTI 10ms, there are two TB (Transport Block) for
FACH
If there is RRC message, one or two TB can be used by SRB FACH
Otherwise (No SRB FACH), TRB FACH can be transferred
69
Solution1: Add 2nd SCCPCH for FACH- FACH congestion

Gain
One SCCPCH dedicated for PCH and another SCCPCH for FACH
For every TTI, 2 PDUs can be transferred on FACH, capacity of
FACH is increased by about 100% (1 PDU per 10ms -> 2 PDUs per
10 ms)
More PS data can be transferred on FACH
Lost
One SCCPCH may consume at most 10% DL power of a cell
Less DL power available for RRC connection and CS service
One additional SF128 code
70
Solution 2-1: Strategy adjustment- FACH congestion
Supported version later than V913SPC510

If FACH user plane is congested, UE will go from PCH to DCH:
SET URRCTRLSWITCH:
PROCESSSWITCH2=FACH_DTCH_CONGEST_P2D-1;
If FACH user plane is congested, the inactive UE will not trigger D2F, but
D2IDLE
SET UCORRMALGOSWITCH: ReservedSwitch0
=RESERVED_SWITCH_0_BIT16-1;
71
Solution 2-2: Strategy adjustment- FACH congestion
Supported version later than V912SPC516

If the FACH user is over 30, for all the P2F request, will go form PCH to DCH.
SET URRCTRLSWITCH: RsvdPara1=RSVDBIT1_BIT20-0;
72
Solution3: FACH Capability Improvement- FACH

congestion
Supported Version V913SPC510 or later.

Activate the switch to support 60 user on FACH Channel
SET UNBMPARA ReservedSwitch0=RESERVED_SWITCH_0_BIT1-1;
73
Risk Analysis -KPI degradation

PS Call Drop Rate
After the CELL_PCH, R8 FD, or EFD is implemented,
1) The PS R99 call drop rate increases due to the call drops occurring on the common
channel.
2) The number of PS accesses is reduced, and the total number of PS call drops keep
no change. In this case, the PS call drop rate deteriorates.
a) Old PS call drop formula:
PS Service Drop Ratio (RNC) = [Number of abnormal RAB releases/(Number of abnormal RAB
releases (CELL_ DCH) + Number of normal RAB releases (D2Idle)] x 100%
b) In versions earlier than V900R012 SPC500, no counter is designed to measure the CELL_
DCH/FACH to CELL_PCH or URA_PCH transition. Therefore, you cannot modify the KPI formula of
the PS call drop rate to avoid the impact of the PCH transition.
c) In V900R012 SPC500 and later versions, the CELL_ DCH/FACH to CELL_PCH or URA_PCH
transition counter is available and you can use the attached KPI formula of the PS call drop rate
to avoid the impact of the PCH transition.
New PS Call
Drop Formula
Risk Analysis -KPI degradation

After
CS Drop
Rate
the solution
is implemented, the CS call drop rate increases. This is caused
by the increase of the combined service call drop rate.
Cause
After the EFD or CELL_PCH solution is implemented, a large number of UEs retain
PS RAB connections in PCH state. If the UE initiates a CS service connection when
retaining the PS RAB connection, the CS service connection belongs to the
category of combined services.
1) Uplink load increase, the service coverage scope deteriorates.
2) If the TRB of the PS service resets, the CS service call drop occurs.
Impact
The CS call drop rate increases from 0.45% to 0.55% in one operator.
Actions
The PS 0k/8k solution is used to avoid the CS call drop rate deterioration.
For the Voice + PS combined service, the PS service is forced to establish on the
DCH, and the initial uplink and downlink rate are set to 0 kbit/s or 8 kbit/s
respectively.
Risk Analysis - KPI degradation

CS Call Drop
To implement the countermeasures, run the following commands based on

the RNC version:
Versions later than V900R012 SH506
SET
UCORRMALGOSWITCH:
ReservedSwitch0=RESERVED_SWITCH_0_BIT11_1
The UL of the CS and PS combined service uses the DCH switch. When the
DCH is enabled, the uplink PS service can only run on the DCH if the CS and
PS combined services exist.
SET UFRC: ULDCHBEUPPERLIMITFORAMR=D8;
The maximum rate of the uplink PS service on the DCH is 8 kbit/s when the
CS and PS combined services exist.
SET
UCORRMALGOSWITCH:
ReservedSwitch0=RESERVED_SWITCH_0_BIT15-1;
The DL of the CS and PS combined service uses the DCH switch. When the
DCH is enabled, the downlink PS service can only run on the DCH if the CS
and PS combined services exist.
SET UFRC: DLDCHBEUPPERLIMITFORAMR=D8;
The maximum rate of the downlink PS service on the DCH is 8 kbit/s when
the CS and PS combined services exist.

CS Call Drop

SET UCORRMALGOSWITCH: ReservedSwitch0=RESERVED_SWITCH_0_BIT28-1;
The parameter controls whether to initiate the P2D process for CELL_PCH or URA_PCH
users at CS service initiation before establishing the CS service. If this function is
enabled, the P2D process is initiated before the CS service is established. If this
function is disabled, the P2F process is initiated before the CS service is established.
SET UCORRMALGOSWITCH: ReservedSwitch0=RESERVED_SWITCH_0_BIT14-0;
When the function is enabled, the P2D process of the combined service uses the 0k
solution for the R99 DCH. By default, the 8k solution is used and the function is
disabled.
The value 0 indicates that the function is disabled and the 8k solution is used.
The value 1 indicates that the function is disabled and the 0k solution is used.

FACH State Call Drop
Cause
1) The FACH/RACH coverage performance is worse than the designed AMR 12.2K. The
coverage deterioration may trigger TRB and SRB reset and call drops in CELL_ FACH
state.
2) FACH channel congestion and cell reselection failure may also trigger TRB and SRB
reset and call drops in CELL_ FACH state.
Impact
Call drops in CELL_ FACH state increases the PS call drop rate.
Actions
Shorten the duration when the UE is in the CELL_ FACH state and enable UEs to stay at
CELL_PCH or DCH state.
1) Reduce the F2P Timer to 6 seconds
2) Reduce the 4A event threshold for FACH UE
3) Disable the cell-level EFD for some congested cells to reduce PS call drops caused
by FACH congestion.

Access Failure increase due to IUPS Transmission
Cause:
as the user number in URA/PCH state increase, the IU PS transmission resource may
become insufficient, and cause the access failure.
Countermeasures:
Adjust the IUPS activity factor of adjacent node before implement PCH/FD/EFD.
V9R12C01 V9R13C500 as example
ADD TRMFACTOR: FTI=xxxxxx, REMARK="IUPS", PSCONVDL=10, PSCONVUL=10,
PSSTRMDL=10, PSSTRMUL=10, PSINTERDL=10, PSINTERUL=10, PSBKGDL=10,
PSBKGUL=10, HDSRBDL=10, HDSIPDL=10, HDVOICEDL=10, HDCONVDL=10,
HDSTRMDL=10, HDINTERDL=10, HDBKGDL=10, HUSRBUL=10, HUSIPUL=10,
HUVOICEUL=10, HUCONVUL=10, HUSTRMUL=10, HUINTERUL=10, HUBKGUL=10;

RRC Failure no reply increase after activating
Second SCCPCH
Cause
1) UE system information update cannot finish within 6 hours after
activating second SCCPCH, so RRC success rate will decrease.
2) IPHONE have compatibility problem between the border of cell with one
SCCPCH and cell with two SCCPCH
Actions
1) Activating Second SCCPCH at mid-night
2) Modify system information update time from 6hour (default) to 1hour
SET UCERRMTIMER: PeriodSysInfoUpdtTimerLen=1;
3) Implement Second SCCPCH at the whole network
HSDPA
Smartphone Signaling Storm Optimization
Study Case
Page 81
Implementation Result Summary
*Paging Times here does not reflect paging lo
Test Case
RRC times
PS RAB
times
Paging
times
SPU Utility
CE Num.
CELL-PCH
-30%
-30%
-26%
-4%
19%
URA<LAC
-30%
-30%
-27%
-6%
27%
URA=LAC
-33%
-33%
-27%
-7%
28%
-56%
-56%
-47%
-13%
34%
T2=2S
-33%
-33%
-31%
-5%
29%
T2=10S
-33%
-32%
-29%
-7%
28%
T2=15S
-28%
-27%
-25%
-4%
24%
URAPCH
FD
RRC State
Transfer
PCH URA FD RRC State transition can reduce network load. In

Unicom Network, FD feature has the most significant effect.
RRC State User Distribution

RNC06
4000
PCH
URA
FD
RRC
RNC08
4000
3500
3500
3000
3000
2500
2500
2000
2000
1500
1500
1000
1000
500
500
PCH
URA
FD
RRC
CELL_DCH UE
CELL_FACH UE
CELL_DCH UE
CELL_FACH UE
CELL_PCH UE
URA_PCH UE
CELL_PCH UE
URA_PCH UE
After PCH/URA/FD/RRC State transition is activated, DCH user number is

decreasing, and PCH user number increased.
SPU Load
40.0
39.0
38.0
before
PCH
URA
37.0
FD
RRC state
transition timer
test
36.0
35.0
Weekend
weekend
Weekend
34.0
33.0
32.0
31.0
30.0
After PCH/URA/FD/RRC State transition is activated, SPU LOAD is

decreased by 4% 6% 7% 13% 5% 7% 4% .
CE Utility Ratio
14000
before
PCH
URA
13000
12000
FD
RRC state
transition timer
test
Weekend
11000
10000
9000
8000
Weekend
Weekend
7000
6000
After PCH/URA/FD/RRC State transition is activated, CE consumption is

decreased significantly by 19% 27% 28% 34% 29% 28%
24% .
RRC Setup Request

RRC service Setup Request
before
180000
PCH
URA
FD
RRC state
transition timer
test
160000
140000
120000
Weekend
100000
weekend
Weekend
80000
60000
40000
20000
0
After PCH/URA/FD/RRC State transition is activated, RRC setup request is

decreased by 30% 30% 33% 56% 33% 33% 28% .
RAB Establish Request

200000
180000
160000
before
PCH
URA
140000
FD
RRC state
transition timer
test
120000
100000
Weekend
weekend
Weekend
80000
60000
40000
20000
0
After PCH/URA/FD/RRC State transition is activated, RAB establish request

is decreased by 30% 30% 33% 56% 33% 32% 27%
CS Traffic Volume
300
before
PCH
URA
250
200
Weekend
weekend
FD
RRC state
transition timer
test
Weekend
150
100
50
After PCH/URA/FD/RRC State transition is activated, CS Traffic has not

affected.
PS Traffic Volume
30000
PCH
25000
20000
URA
Weekend
15000
Weekend
FD
RRC state
transition timer
test
Weekend
10000
5000
0
After PCH/URA/FD/RRC State transition is activated, PS volume is

decreased is a little since some small package is transferred on FACH and
not calculated in the counter.
Accessibility
100.00
before
PCH
URA
FD
99.50
RRC state
transition timer
test
99.00
98.50
98.00
97.50
RRC service
PS RAB
After PCH/URA/FD/RRC State transition is activated, the accessibility KPI is

improved a little.
Retainability CS CDR
CS CDR
0.800
before
0.700
PCH
URA
FD
RRC state
transition timer
test
0.600
0.500
0.400
0.300
0.200
0.100
0.000
After PCH/URA/FD/RRC State transition is activated, CS CDR has not

affected.
Retainablity PS CDR
*PS CDR formula is modified.
before
PCH
URA
0.450
0.400
0.350
0.300
Weekend
weekend
FD
RRC state
transition timer
test
Weekend
0.250
0.200
0.150
0.100
0.050
0.000
After PCH/URA/FD/RRC State transition is activated, PS CDR has

increased from 0.3 to 0.4%.
Thank you
www.huawei.com

Signaling Storm Solution

Uploaded by

Document Information

Original Title

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

Signaling Storm Solution

Uploaded by

Copyright:

Available Formats

Security Level:

HUAWEI TECHNOLOGIES CO., LTD.

What is Signaling Storm

What is the signaling storm

Which scene will trigger the signaling storm:

How to deal with the signaling storm :

HUAWEI TECHNOLOGIES CO., LTD.

How to define Smartphone?

Based on Operation System of the terminal:

HUAWEI TECHNOLOGIES CO., LTD.

Smartphone Power Saving Explode Signaling

Fast dormancy function has been introduced to some

Frequent connection, more signaling

IDLE status (idle mode), UE power consumption < 5mA

HUAWEI TECHNOLOGIES CO.,

Heart Beata Different Behavior of Smart Phone 2

For Push Type Messages

Apple Push Server

Service Client Service Server

Every 10-15 minutes,

User setting (in service client on

The Heart Beats of smart phones are actually caused by

Traffic Mode Benchmark of different Operators

Operator V in E.U. B in N.A. E in Asia

Signaling requirement increases more rapidly than data traffic with

Huawei Systematic Solution To Tackle Signaling Storm

Resource & Capacity

Resource & Capacity

RNC Resource Adjustment

Smartphone Traffic Model

Expansion Suggestion in Small scale

Hardware & Software Capacity

Smart Signaling Optimization

Network Resource & Capacity Monitoring and Performance Assurance

HUAWEI TECHNOLOGIES CO.,

Smartphone Signaling Storm Solution

Signaling Storm Assessment

HUAWEI TECHNOLOGIES CO.,

Later than R12

Later than R12

HUAWEI TECHNOLOGIES CO.,

Smartphone Signaling Storm Assessment Process -1

HUAWEI TECHNOLOGIES CO., LTD.

Smartphone Signaling Storm Assessment Process -2

Perform Smart Phone Penetration Audit

SPU Gain Prediction

HUAWEI TECHNOLOGIES CO., LTD.

UEs complying with 3GPP Release 8 support the fast dormancy

R8 fast dormancy: This mechanism is standardized by 3GPP

Smart Phone definition: UE group has the

Operator O Smartphone Penetration

Apple, RIM and Nokia are the TOP 3

HUAWEI TECHNOLOGIES CO., LTD.

Smartphone Behavior Analysis -1

Device Type PS RAB ACCESS

* Smartphone behavior is defined as 2 Times PS

Device Type PS Traffic Volume

*Dongle is included in Smartphone

Device Type CS Erlang

HUAWEI TECHNOLOGIES CO., LTD.

Smartphone Behavior Analysis -2

PS RAB ACCESS per user

CS Call Duration per CS Call