08 UA8.1 DR5 KTS 97425 Fast Dormancy PDF

PM97425 - Fast Dormancy for Smartphone battery saving
KTS UA08.1
TIS-FOA-NEA (AVargas & EYang)

2012-11-16 V1.0
COPYRIGHT 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
Agenda
Part A Fast Dormancy Description
1. Feature overview.
2. Purpose of the feature and benefits.
3. Feature interactions.
4. General feature activation strategy
PART B - Performance evaluation on FFA/FOA (US/GM)

1. Feature Activation strategy used.
2. Sum Up of Fast Dormancy observations
3. State transitions and RRC contexts
4. Other side effects of Feature activation
5. Non regression analysis
Part C Conclusions and recommendation for activation
2
Part A Fast
Dormancy
Description
3
Feature
Overview
4
Feature Overview the present

In current implementation (pre-Rel.8), a UE can send a RRC SIGNALLING CONNECTION
RELEASE INDICATION message to the UTRAN, which results in an immediate call tear down
As the UTRAN does not know whether this is due to an error or to fast dormancy, the UE is sent
back to idle state
The current implementation allows reducing the battery drain as expected, but the following
drawbacks are evident:
- The mobile can not be sent to CELL_FACH or URA_PCH (users in idle mode experience longer call setup time and
generate higher signalling load when traffic resumes than users in CELL_FACH or URA_PCH)
- UTRAN does not know the root cause for the UE initiated release request (this release is not counted as a call drop)
5
Feature Overview Proposed Solution

With new 3GPP Release 8 specification, the UE can use a new cause value when sending the
RRC SIGNALLING CONNECTION RELEASE INDICATION
If the Signalling Release Indication Cause IE contains the value UE Requested PS Data session
end the UTRAN may now initiate an RRC state transition to URA_PCH or Cell_FACH
So, upon reception of the RRC SIGNALLING CONNECTION RELEASE INDICATION (SCRI)
message, the UTRAN will examine the cause in this information element and if it contains the
value UE Requested PS Data session end it may:
- Release the signalling connection
- Initiate an RRC state transition to URA_PCH or Cell_PCH
This behaviour is applicable to legacy UEs as well, meaning that a direct transition to PCH shall
be triggered to these mobiles, even if they do not insert the new Rel.8 cause
6
A Sum up of features: Principles and Use Cases of Fast Dormancy

The following schematic procedure applies:
Fast Dormancy & AO are enabled & UE sending
3GPP R8 compatible SCRI IE
Operator parameter
option
If start conditions are not met

legacy behaviour of SCRi
IE msg presence
UeVersionForScri
includes Ue 3gpp
Release
No
Yes
Yes
Yes
Case B: Initiate an RRC state

transition from Cell_DCH/Cell_FACH
to CELL_PCH
OR
Case C: Initiate an RRC state
transition from Cell_DCH/Cell_FACH
to URA_PCH
SCRI Cause IE is = UE
No
Requested PS Data
session end?
XX_PCH
Active
Yes
Case A1: Release the

signalling connection (UE
goes into idle mode)
Normal Release
Yes
XX_PCH
Active
Case D1: Initiate an RRC state transition

from Cell_DCH/Cell_FACH to CELL_PCH or
URA_PCH
7
Extended fast dormancy

is activated?
No
No

signalling connection
Abnormal Release
A Sum up of features: Principles and Use Cases of Fast Dormancy
The following schematic procedure applies:
Fast Dormancy & AO are enabled & UE sending 3GPP NOT R8

compatible SCRI IE MSG
If start conditions are not met

legacy behaviour of SCRi
Yes
Yes
Yes
XX_PCH
Active
UeVersionForScri
includes Ue 3gpp Release
Extended fast dormancy

is activated?
No
No
No

signalling connection (basic preRel.8 SCRI)
Case D2: Initiate an RRC state transition

from Cell_DCH/Cell_FACH to CELL_PCH or
URA_PCH
Abnormal Release
8
Fast Dormancy Allowed Transitions

The RRC states transitions supported by the U-plane with Fast Dormancy procedure are the
following (assuming AO enabled):
- Cell_DCH to Idle
- Cell_FACH to Idle
Cell_DCH or
Cell_FACH
- Cell_DCH to Cell_PCH
URA_PCH
- Cell_FACH to Cell_PCH
- Cell_DCH to URA_PCH
- Cell_FACH to URA_PCH
With Fast Dormancy + Extended Fast Dormancy
Cell_PCH
+ Cell/URA_PCH, the transitions to Idle are not possible

RRC state transitions triggered by
RRCconnection Request
RRC state transitions triggered by Fast
Dormancy procedure
RRC state transitions triggered by Always
On procedure
9
Idle
Fast Dormancy Applicability

The procedure is applicable when the UE is in Cell_DCH or Cell_FACH state, for PS
Interactive/Background traffic only
The following combinations are enabled for Fast Dormancy:
- 1, 2 or 3 PS I/B RAB in Cell_DCH state over DCH/DCH
- 1, 2 or 3 PS I/B RAB in Cell_DCH state over DCH/HS-DSCH
- 1, 2 or 3 PS I/B RAB in Cell_DCH state over HS-DSCH/E-DCH
- 1 PS I/B RAB in Cell_FACH state (multiple RABs over Cell_FACH are not yet supported)
The following combinations are not allowed for Fast Dormancy:

- CS Data + PS Interactive/Background
- PS Streaming traffic class
- Conversational traffic class
Timer T323 must be present in SIB#1

As per 3GPP, the UE shall not send a SCRI message while T323 is running or while in Cell_PCH
or URA_PCH state
10
Purpose of the
feature and
benefits
11
Purpose of the feature and benefits

Presently the UEs (mainly Smarthphones) send SCRI and this originates a high signalling load due to small application data.
With Current behaviour we can save all the user_inactivity signalling by sending them to URA PCH, but still a big portion of PS_releases
with SCRI are being released and established again
Proposed FD provides the ability for UTRAN to distinguish the cause for the RRC SIGNALLING CONNECTION RELEASE INDICATION (at
least to identify when there is no further PS data to be transmitted by the UE), it reduces the signalling load by using more suitable
transition states as Cell-PCH and URA-PCH. It improves also the UE battery live, due to less DCH time and less RRC Connection requests
Attempts.
Ability for
URA_PCH Active
before Fast Dormancy
Reduce the number of transition states changes with the traffic volume variation or resuming
If all SCRI are sent to xx_PCH then PS RAB establishment is 10 x lower!!!

Note: the reduction of PS call establishment by a factor of 10 is highly dependent on number of SCRI vs PS RAB establishment
12
Purpose of the feature and benefits
Benefits {& Cost} of Fast Dormancy (+URAPCH)

Activation of Fast Dormancy follows the benefits observed with URA PCH activation. It can
bring benefits to both the user and the network operator.
Key user benefits:
PS latency reduction
UE battery savings
Key operator benefits:

TMU processor occupancy reduction (largely related to paging and signalling reduction)
SGSN paging reduction (which should translate into SGSN processor occupancy benefits).
Per cell paging load reduction (in cases where paging load is a germane factor).
The costs of the FD is the higher usage of URA PCH with the constrains that it can bring on
Higher CS call setup time for a higher amount of users
Higher call duration in FACH and in PCH where the ue mobility scenarios can produce some
degradation.
Summary of key attributes/benefits (and constraints) enumerated on sum up FD section
13
Feature
Interaction
14
Feature Interaction 1/2

ALWAYS-ON
- Introduces the concept of state transiton, FastDormancy depends on the activation of this feature
(isAlwaysOnAllowed=True) .
- When a SCRI procedure with cause UE Requested PS Data session end is triggered:
- Stopping timers related to RRC state transitions: Cell_DCH/Cell_FACH to Cell_PCH/URA_PCH/Idle,
- Stopping traffic volume monitoring/measurement related to these RRC state transitions
Required Feature
UA5 PM26673 URA_PCH and PM26675 - Cell_PCH

- Introduces URA_PCH and Cell_PCH, FastDormancy depends on the activation of this feature.
Required Feature
PM29400 Enhanced RRM for High Quality Streaming:

- In that case the RRC state is Cell_PCH, SCRI message shall be ignored,
15
Feature Interaction 2/2

UA7 PM108388 - Enhanced URA_PCH
- There is a probability for a legacy UE to move in idle mode instead of the target state Cell/URA PCH. The consequence
in that case could be a non enhanced Cell/URA_PCH paging between the RNC and the UE since the RNC RRC state
could be Cell_PCH or URA_PCH and the UE is in idle mode (Cell/URA PCH paging not received by the UE). This
feature resolves the lack of synchronization between UE and RNC during CS/PS paging.
Important interaction with this feature
UA8.0 PM108389 - Cell_PCH/URA_PCH direct transition to DCH:

Interaction with sub-feature 2, for PS Interactive RAB with SI=signaling, the additional condition of Fast Dormancy
eligibility depends on isAlwaysOnAllowedForSigIndOnRab: if isAlwaysOnAllowedForSigIndOnRab is set to FALSE, Fast
Dormancy is not eligible (Extended Fast Dormancy is not eligible also); if isAlwaysOnAllowedForSigIndOnRab is set to
TRUE, Fast Dormancy is eligible (Extended Fast Dormancy is eligible also).
Important interaction with this feature
16
General Feature
Activation Strategy
17
Feature Activation strategy: Fast Dormancy

We should also consider that the main feature interactions presented above should be active before FastDormancy (FD)
The strategy below show how to activate Fast Dormancy on a progressive mode with several small steps allowing to monitor which steps is
bringing more impact
- FD1 Step1: Activate FastDormancy with limited impacted Ues and not affecting legacy SCRI (Without Cause
PSDataSessionEnd):
-
isFastDormancyAllowed = True
isExtendedFastDormancyAllowed = False
UeversionForSCRI = R7_R8 Filter all older than 3gppR7 Ues
This strategy option allow to observe the global impact of the feature activation mainly other side effects beside the extra transition it causes; Also it allows to
observe the performance of FD for recent ues
- FD2 Step2: Activate FastDormancy with more impacted Ues and not affecting legacy SCRI (Without Cause
PSDataSessionEnd):
-
Same setting as Step1 except for parameter UeversionForSCRI = R6_R7_R8
This will allow to include almost all ues supporting 3gppR8 IE specification
- FD3 Step3: Activate FastDormancy with all 3GPPR6 or later Ues including legacy SCRI (Without Cause PSDataSessionEnd):
-
Same setting as Step2 except for parameter isExtendedFastDormancyAllowed = False True
This will include the remaining Ues with 3gppR6 and later version, for any SCRI proposed and allow to reach a high level of triggering of FD
- FD4 Step4: Activate FastDormancy with all UEs including all legacy SCRI (Without Cause PSDataSessionEnd)
-
Same setting as Step3 except for parameter UeversionForSCRI = Pre_R8
This parameter tuning will allow to observe the remaining trigger of R5 UEs which are considered to be mainly driven by SCRI not supporting 3gppR8 compatible
IE
18
Configuration, Parameters and RAN Model
RNC
RadioAccessService
isFastDormancyAllowed
ueVersionForScri
isExtendedFastDormancyAllowed
UeTimerCstConnectedMode
t323
19
PART B Performance
assessment on
FFA/FOA
20
Feature Activation
strategy used
21
Feature Activation strategy: AT&T
At&t
- 25th of June: URA on base on UA811EP3

- 12th of July: SU 813tap2
- 16th of July: EDCH parameter optimization including change AOMode ReleaseOnly (EDCH)
- FD1 18th of July: Activation of Features with lower triggering isFastDormancyAllowed=True

isExtendedFastDormancyAllowed = False, UeVersionForSCRI = R7_R8.
- FD2 20th of July: Activation of fast dormancy(FD) at this stage without EFD UeVersionForSCRI = R6_R7_R8.
- FD3 27th of July: extended fast dormancy(EFD) is activated: isExtendedFastDormancyAllowed = True
- FD3off31st of July: extended fast dormancy(EFD) is deactivated: isExtendedFastDormancyAllowed = False
- 2nd of Aug: decrease RepThreshold to increase Direct Transition: RadioAccessService.AlwaysOnConf.AoFachParam.repThreshold = 512->256
- 3rd of Aug: Change TimeToTrigger to 100 ms
- 6th of Aug: change RBsetConf to AOMode ReleaseOnly (HSDPA) and also change RepThreshold from 256 to 128
- FD4 1/0 7th of August: modify UeversionForSCRI from R6_R7_R8 to Pre_R8 and modify isExtendedFastDormancyAllowed to True, then
back out 8 hours later due to TMU reset
8th of Aug: RadioAccessService.AlwaysOnConf.AoFachParam.repThreshold = 128->256
- 13th of Aug: All feature on

- 6th of Sep: SU 813EP1tap1
- 11th of Sep: Turn off UTRAN paging repetition: isPagingRepetitionAllowed=false
22
Feature Activation strategy: A1TA

Phase1 activation : August (Ua08.1.3 Ep1)
A1TA
- FD1 13th of August :Activation of Features with lower triggering isFastDormancyAllowed=True

isExtendedFastDormancyAllowed = False, UeVersionForSCRI = R7_R8.
- FD2 14th of August : Activation of fast dormancy(FD) at this stage without EFD UeVersionForSCRI = R6_R7_R8.
- FD3 15th of August extended fast dormancy(EFD) is activated at this stage just for 3 hours after all FD is deactivated:
isExtendedFastDormancyAllowed = True
Phase2 activation : September/October (Ua08.1.3 Ep2/Ep3)

- FD2 18th of Sept :Activation of Features with lower triggering isFastDormancyAllowed=True
isExtendedFastDormancyAllowed = False, UeVersionForSCRI = R6_R7_R8.
- 19th of Sept Improve of State transition from DCH to PCH IubEdchDelayVariation = 5 to 3
- FD3 20th of Sept : Activation of extended fast dormancy EFD is activated at this stage isExtendedFastDormancyAllowed =True
- FD2_T323 24th of Sept: Deactivation of EFD and decreasing T323 isExtendedFastDormancyAllowed = False & t323=10 secs
- 25th of Sept enhanced Paging Release for Rel7+ devices [CRE128146] isDirectTransitionFromPchToIdleAllowed = true
- FDOff 26th of Sept: Deactivation of EFD and decreasing

- 27th of Sept enhanced Paging Release for Rel7+ devices [CRE128146] isDirectTransitionFromPchToIdleAllowed = False
- 28th of Sept Enabling WAIT TIME in Cell Update Confirm upon PCH to DCH CAC failure [CRE133668] isCellUpdateWaitTimeForPchUeAllowed = True waitime = 5 s
- FD2 1st of Oct: by the last time Re-activation of fast dormancy(FD) at this stage without EFD UeVersionForSCRI = R6_R7_R8.
isFastDormancyAllowed=True isExtendedFastDormancyAllowed = False.
23
Sum Up of Fast
Dormancy
24
Sum Up of Fast Dormancy Benefits {& Cost} of Fast Dormancy (1/3)

Attribute
Description
At&t A1TA
Result
PS Latency
Expressed as a PS time to first byte
Decreased from approximately 1.5s to 0.9s ~70% of users

conisdering URA +FD (ATT) or 40% for FD2 only (A1TA)
UE battery usage
URA usage should reduce battery usage
Not measured during trial
TMU load
Processor Occupancy.
Reduction of 17% to 21% combined URA+ FD2 vs 7.1.3 URA off

Reduction of 9% and 10.3% compared with 7.1.3 and 8.1 with URA on
in Att or 8% in A1TA
UTRAN paging
9370 level paging volume
When multi_URA configured, paging volume decrease, 30% (can vary

depending on settings) paging cancel and delay records decrease.
Success rate doesnt degrade. (trial on KC3)
SGSN paging
The volume of paging messages sent by the

SGSN.
Reduction of 70% to 80% on total SGSN paging load
CS setup latency
from URA
URA CS setup compared to transition from PS
Similar value to case of CS added to PS (irrespective of URA activation

state
URA CS setup compared to IDLE transition
Increased by approx 1.0 secs for the setup from URA with DT
compared to a setup over FACH. However main result is the increase
of ~30% with FD2 of setups over DCH
% of CS calls which are now multi-RAB calls
Increased from 8% to 54% (expected) with URA +FD2, FD alone brings

a small increase (8% on worse case of FFA/FOA)
mRAB penetration
25

Attribute
Description
At&t A1TA
Result
Iu-PS resource usage
Number of Iu-PS connections and SCCP contexts
Increased from 3500 to 21000 (still not close to any exhaust

points 80K).Max value achieved was 25K when FD4 was
activated a few hors
SGSN signaling load
URA activation should reduce SGSN signalling and

hence provide processor occupancy gains
Not measured during trial
10
CS paging Success
Amount of missed CS pages (in the case of URA

typically due to mismatch state of UE and RNC)
No degradation expected but need confirmation from CN

statistics for CS (an expected goal of enhanced URA paging)
11
DL Power, Codes
consumption; UCU;
RTWP
Any shift (positive or negative) in the 9370 view of DL

power consumption or codes, based on shift in
signaling/paging usage.
No major observed change. ATT revela a lower usage of

UCU after FD2 activation but not confirmed with A1TA
12
RRC; RAB assignment

PS
Volume of RRC signaling procedures; RAB

assignment procedures (causes for the observed
signaling gain)
Reduction of up to 70% on RRC procedure and RAB

assignment PS (URA+FD2), while FD alone it ranges up to
60%
13
FACH Efficiency
Volume of SDU transported over same amount of

Erlangs used
Increase of amount of data per erlang, which means that

even if we increase the erlangs
26

Attribute
Description
At&t A1TA
Result
KPI11
CDR Voice
CS Retainability
Is not impacted by URA or FD, it remains constant thru URA and FD activation of both FOA/FFA.
KPI13
PS Retainability
For ATT It can be noticed an improvement overall due to global strategy including with URA.
CDR PS
3
KPI14
FD2 can produce small degradation observed on both FOA/FFA ranging from 0.03% to 0.08% (worse
observation in A1TA)
Global CSSR CS
Is affected by RRC accessibility, remaining components have no impact with URA or FD. The KPI35 cs is
affected by .09% of degradation which produces a kpi impact of 0.04% degradation in Kpi14. Applying
modified formulas allow to have a new baseline for KPi35CS in order to avoid impact on KPI14
Global CSSR PS
Degradation observed due to two components; KPI35PS and KPI33, the first one is rebase lined with the
modified formula to take into account the state transitions and will not produce any degradations. The
Kpi33 component will produce an overall degradation of 0.04% detailed below
CS RAB success
rate
It is not affected by FD activation
PS RAB success
rate
Degradation produced by URA_PCH and FD are mainly due to a different distribution and mechanisms of
accessibility (using state transitions and not RAB establishment). The degradation is at most 0.1%
CSSR_CS
4
KPI16
CSSR_PS
KPI32
RABEstab
CS_SR
KPI33
RABEstab
PS_SR
27
State transitions
and RRC contexts
28
Performance assessment : major FD related events

Jun28
At&t
Aug23
The Global observations of State transition, show the main volume decrease of RRC and PS Releases due to SCRI,
while the overall state transitions tend to increase specially CellDCHtoPCH, PCHtoFACH, CellFachtoPCH. The FACHtoDCH
increase due to more UEs needing traffic in DCH
There is global increase of state transitions as result of some UEs triggering an upsize reconf to send an SCRI just
after (depending on T323).
The big increase on 1st of August is due to a normal traffic increase.
29
At&t
Performance assessment : Global Dynamics of state transitions

kc09
Millions
dch
fach
idle
pch
in
9.327
8.03
5.327
3.502
Before
out
9.322
7.8002
5.661
3.403
28-Jun
diff
0.005
0.2298
-0.334
0.099
0.00
drops
0.02
0.017
KC09
After
23-Aug
Millions in
out
diff
drops
dch
4.974
4.968
0.006
0.01
fach
5.784
5.623
0.161
0.015
idle
1.657
2.03 -0.373
pch
6.6
6.394
0.206
0.012
0.00
Success rate
Success events
Normalized events
0.007
28Jun KC09 URA ON
23 Aug KC09 URA ON & FD2 On

URA Update
Confirm
URA Update
Confirm
Normalization due to PS
increase traffic on Aug 27%
URA_PCH
URA_PCH
99.98%
132K
RB Reconfig
(DBC)
99.46%
4.83M
Cell-DCH
4.34M**
RRC
Connection
Establish
99.57%
3.37M
99.42%
196K
RRC
Connection
Release
92.96%
3.47M RRC
Connection
Establish
5.661M
Cell Update
Confirm
99.8%
3.2MCell Update
RB Reconfig
(DBC)
1.62M**
37K FACH
voice setup
RRC
Connection
Establish
RRC
Connection
Release
99.8%
3.262M
96.32%
406
Cell-DCH
Cell_FACH
Cell Update/
Confirm
98.97%
598K
Confirm
RRC
Connection
Release
* Estimated SCRI & inact

** estimated SCRI
30

99.84%
5.784M
26K FACH
voice setup
2.346M RRC
Connection
Establish
Idle
Cell Update
Confirm
Cell_FACH
63.42%
2.030M
0.96M**
Idle
99.92%
3.338M
RRC
Connection
Release
0** 0.012K
Drops
Performance assessment : Global RRC contexts

The Global RRC contexts
which rely on counters
sum #1666, #935 and
#936, reveal a major
impact on URA Contexts
Uon
1.8E+10
At&t
FD3
KC9
EDCH
FD1
1.6E+10
AO R HS;DT@128
FD4 I/0
FD3off
PagingRep
FD2
1.4E+10
1.2E+10
1E+10
8E+09
6E+09
Cell_DCH counter broken
4E+09
2E+09
TotalURA_PCH
AR 389449 has been

raised for broken counter
U1666, fixed in UA813EP2
31
TotalCell_FACH
13Sep
10Sep
7Sep
4Sep
1Sep
29Aug
26Aug
23Aug
20Aug
17Aug
14Aug
11Aug
8Aug
5Aug
2Aug
30Jul
27Jul
24Jul
21Jul
18Jul
15Jul
12Jul
9Jul
6Jul
3Jul
30Jun
27Jun
24Jun
21Jun
18Jun
0
15Jun
Cell_FACH reduce when

AO release only for EDCH
and further reduce when
AO release only for HSDPA
Performance assessment : State transition : SCRI

Uon
5000000
KC9
EDCH
4500000
AO_R_HS
0.8
FD3off
FD2
FD1
FD3
At&t
0.7
4000000
0.6
FD4 I/0
3500000
3000000
0.5
0.4
2500000
2000000
0.3
1500000
0.2
1000000
0.1
500000
VS_IuReleaseReqPs_UeGeneratedSignallingConnectionRelease(U599_5)(Event)
VS_UEReqDataSessionEnd_toPch(U2964)(Event)
13Sep
11Sep
9Sep
7Sep
5Sep
3Sep
1Sep
30Aug
28Aug
26Aug
24Aug
22Aug
20Aug
18Aug
16Aug
14Aug
12Aug
10Aug
8Aug
6Aug
4Aug
2Aug
31Jul
29Jul
27Jul
25Jul
23Jul
21Jul
19Jul
17Jul
15Jul
13Jul
9Jul
11Jul
7Jul
5Jul
3Jul
1Jul
29Jun
27Jun
25Jun
23Jun
21Jun
19Jun
17Jun
15Jun
%ofSCRI_PSDataSessionEnd
The several steps of Fast Dormancy have quite different impacts on, mainly Step 2 is addressing almost 60% of SCRi while step3
takes additional 10 % and Step 4 considers the remain 30% to reach the 100% of SCRI handled by RNC to reconfigure users in
URA_PCH
% of SCRI PSDataSessionEnd is the rate of PSDataSessionEnd/(PsDataSessionEnd+SCRI_IureleaserequestPS)
32
Performance assessment : major FD related events
A1TA
The Global observations of State transition, show the main volume decrease of RRC and PS Releases due to SCRI,
while the overall state transitions tend to increase specially CellDCHtoPCH, PCHtoFACH, CellFachtoPCH. The FACHtoDCH
increase due to more UEs needing traffic in DCH
There is global increase of state transitions as result of some UEs triggering an upsize reconf to send an SCRI just
after (depending on T323). Also this increase is a litle bit more noticeable for A1TA due to smaller URAToIdleTimer
(25min vs 720min on Att)
33
Performance assessment : Global Dynamics of state transitions

27&28 Sep GQ07 URA ON
State
DCH
FACH
URAPCH
Idle
URA no FD
in
out
5.49E+06 5.40E+06
5.57E+06 5.51E+06
1.67E+06 1.58E+06
2.80E+06 3.03E+06
diff
-9.26E+04
-5.70E+04
-8.58E+04
2.35E+05
State
DCH
FACH
URAPCH
Idle
URA Update
Confirm
URA_PCH
99.98%
47.7K
98.98%
1.62M
99.34%
0.114M
RB Reconfig
(DBC)
99.70%
4.10M
Cell-DCH
99.20%
99.45%
RRC
Connection 2.35M
1.25M**
RRC
Connection
Establish
4&5Oct GQ07 URA ON & FD On
Release
3.03M
RB Reconfig
(DBC)
99.95%
0.313M
99.26%
2.74M
99.74%
3.86M
Cell-DCH
99.92%
2.67M
98.68%
RRC
Connection
Establish
Connection
Release
2.71M
2.04M
** estimated SCRI + inact + PSdrops

34
63.9K FACH
voice setup
RRC
Connection
Release
0.8M**
Idle
Cell Update
Confirm
Cell_FACH
0.76M** 99.47%
RRC
30.6K FACH
voice setup
RRC
Connection
Release
Cell Update/
Confirm
99.44%
0.227M
Confirm
1.54M**
Idle
URA_PCH
Cell Update
Confirm
Cell_FACH
diff
-4.89E+04
-2.38E+05
-1.91E+05
4.78E+05
URA Update
Confirm
Success rate
Success events
99.92%
1.47M
Cell Update
URA With FD2

in
out
4.98E+06 4.93E+06
6.49E+06 6.25E+06
3.05E+06 2.86E+06
1.56E+06 2.04E+06
A1TA
Performance assessment : Global RRC contexts

The Global RRC contexts
which rely on counters
sum #1666, #935 and
#936, reveal a major
impact on URA Contexts
while the CellDCH and
CellFACH remain constant.
35
A1TA
Performance assessment : State transition : SCRI
A1TA
With FD R6R7R8 the SCRI with PSDataSessionEnd is almost 40%. The Extended FD increase it further to ~65% of all SCRI.
The usage of T323 reduced from 30secs to 10 secs make the PSDatasessionend SCRI increase as expected.
The usage of FD2 and FD3 produces a reduction on the global SCRi, while this is understood for the case of FD2 because of
T323 and correction of CR 729587 which ignores SCRI in case of State transition on going, the reduction for EFD (FD3) is still
under discussion (No AR open up to now).
36
Performance assessment : RRC contexts & State transition sumup At&t A1TA
1.
Triggering of SCRI
For Att, the several steps of Fast Dormancy have quite different impacts on, mainly Step 2 is addressing almost 60% of SCRi
while step3 takes additional 10 % and Step 4 considers the remain 30% to reach the 100% of SCRI handled by RNC to
reconfigure users in URA_PCH
For A1TA, the amount of PS releases with SCRI is reduced ~40% with FD. It is further reduced to~64% with extended. The
reductions on total amount of SCRI is due to the observation of T323 and the scenario of SCRI ignored when happening at same
time of a Reconfiguration. Defining the T323 at a lower value is also producing more SCRI as expected.
2.
RRC Contexts
Att, show a reductions of ~70% overall (URA+FD) on both RNCs of RRC PS Attempts on the step2 of Fast Dormancy. On the
few days of FD step 3 we can observe ~80% reduction. For the CS it is also observed a reduction but less expressive it
ranges from 40% to 60% depending on the step of FD. With A1TA the gain is lower ~40% for PS and 15-20 % for CS
ATT strategy of AO release Only is put in place for HSDPA and EDCH channel types, the contribution of FACH becomes
only URA PCH these strategies also allow to keep a lower value of FACH usage while URA and FD is adding up on
FACH, release only is subtracting leaving the fach context almost the same.
A1TA, as no similar strategy was used, it increases the FACH context ~40%, the increase is a contribution of URA
incoming
AO release only mode have an effect of removing SDU In FACH/RACH while URA & FD have the contrary effect of
increase FACH usage and the traffic on these channels
As Observed before with URA PCH activation the FACH usage and FACh efficiency (SDU/ErlgFACH) increase with FD
The URA contexts increase nearly 100% for FD2 (R6_R7_R8).

It can be notice the clear increments on the amount of SCCP connections active between RNC and SGSN brought by FD
step2 and Step4 it increases up to 25K at max which is still far from the maximum limit of ~81K simultaneous contexts.
For Att, it can be noticed an increase mainly due to AO releaseOnly mode which will increase Cell DCH usage with some
impact on resources. Apart from this configuration side effect, FD itself is not changing so much the amount of cell DCH
usage even is slightly reduced (due to some traffic carried by Cell FACH)
37
Performance assessment : State transition & RRC Contexts sumup At&t A1TA
The Previous Sections continuations:
3.
State transitions
With FD the DT PCH to DCH increase 60% for A1TA and ~40% for Att (higher Repthreshold), the success rate is also
a bit better around 0.1%. The T323 change from 30 secs to 10 secs increase slightly the amount of DT due to higher
amount of ue entering in URA as well.
In ATT the increase on this transition is ~65%, mainly because of strategy of release only which takes already some
ues to PCH. For A1TA the increase is more visible as there is a more impact of SCRi. The DCH to URAPCH is degraded
as expected mainly in case of EFD.
A1TA FOA also reported User impacting, mainly related with Extended FD which was causing problems on some ue's
preventing them from receive call and send SMS.
The DCH to FACH is improved by 0.05% this is mainly attributed to changes on Code due to the race conditions in case
of Reconfigurations of AO and SCRi. The volume decrease less than 10%. However later on for ATT this transition is
removed
IN A1TA The success rate FACH to DCH decrease by 0.5%, this is produced by a higher amount of EDCH upsize
(+15%) which is mainly produced by EDCH which has a lower success rate. Looking at another indicator global for AO
upsize we can see actually a small gain of 0.02%. The volume increase as well around 20%. In Att the volume increase
closer to the 30% while the success rate have the same kind of effect only noticed to St005
A1TA FACH to PCH downsize increases almost up to 100% in case of EFD, while for ATT it goes up to 150%. The
success rate follows same changes on both, it is improved in case of single FD due to the fact that it is the ue
triggering the transition. however the EFD success rate is worse due to legacy ue's not responding well to SCRI.
The PCH to FACH upsize have an increase of 65% and 100% depending if FD or EFD is used respectively. the success
rate is more or less kept at a very high value.
The Cs setup over FACH is kept constant on both networks however the setup over URA increase on both cases 30%
38
At&t
Performance assessment : State transitions: RRC

There is a reductions of ~70% overall (URA+FD) of RRC PS attempts on the step2 of Fast Dormancy.
On the few days of FD step 3 we can observe ~80% reduction
For the CS it is also observed a reduction but less expressive. It ranges from 40% to 60% depending
on the step of FD but also there is a change on CS call profile during the reference periods
7000000
Uon
KC9
EDCH
AO_R_HS
900000
FD4 I/0
FD2
6000000
FD1
FD3 FD3off
800000
700000
5000000
600000
4000000
500000
3000000
400000
300000
2000000
200000
1000000
100000
0
15Jun
17Jun
19Jun
21Jun
23Jun
25Jun
27Jun
29Jun
1Jul
3Jul
5Jul
7Jul
9Jul
11Jul
13Jul
15Jul
17Jul
19Jul
21Jul
23Jul
25Jul
27Jul
29Jul
31Jul
2Aug
4Aug
6Aug
8Aug
10Aug
12Aug
14Aug
16Aug
18Aug
20Aug
22Aug
24Aug
26Aug
28Aug
30Aug
1Sep
3Sep
5Sep
7Sep
9Sep
11Sep
13Sep
FirstRRCConnectionRequest_RRC015_CR_Ps(URRC015_CR_Ps)(Event)
FirstRRCConnectionRequest_RRC015_CR_Cs(URRC015_CR_Cs)(Event)
NumberofSMS_NAS001_CR(UNAS001_CR)(Event)
39
Performance assessment : State transitions: RRC
A1TA
There is a reductions of ~40% overall (FD2) of RRC PS Attempts on the step2 of Fast Dormancy. On the few days of FD step 3 we can observe ~80%
reduction
For the CS it is also observed a reduction but less expressive it ranges from 15% to 20% depending on the step of FD. We can extrapolate that 60/70% of Ues
sue CS but not PS regularly so UraPchToIdleTimer is 25 min, allows that the typical larger intervals betweenCS calls make the calls escape from URA .
The success rate is also affected and it will be analyzed on non regression section.
FD RRC PS reduction is proportional to RRC SCRI ratio presented above
40
Performance assessment : Contexts FACH & FACH Usage

The Contexts in fach have contribution
of URAPCH and Cell DCH
Once the strategy of AO release Only
is put in place for HSDPA and EDCH
channel types, the contribution of
FACH becomes only URA PCH
The Global strategy used results in an
amount of FACH context almost the
same as the existing before URA
AO release only remove SDU in
FACH/RACH while URA & FD increase
FACH usage and the traffic on these
channels
The way that DTCH and DCCH is
impacted is also different. URA & FD
are bringing more signaling
reconfigurations in FACH which is not
easily recovered with the AO
releaseOnly mode tuning.
41
At&t
Performance assessment : Contexts FACH & FACH Usage

The increase of traffic in CellFACH (FACH
and RACH) is correlated with the
activation of FD and increases
furthermore with Extended FD to values
close to 40%.
However the Avg usage of FACH channel
also increases resulting on a ratio of
SDU/Erlg which still shows a small
increase associated with Fast Dormancy
(~10%). This is the expected behavior of
FD as it was already the case for URA
activation. The reason is related with the
usage of FACH as a first way for traffic
while before it was mainly used for
waiting before inactivity is reached
There is a higher amount of SDU per
erlang when T323 is decreases and it is
also observed the same for the
isDirectTransitionFromPchToIdleAllowed
set to true. This a normal consequence
of the observed slightly less usage of
FACH for these configs.
42
A1TA
Performance assessment : Contexts: URAPCH
At&t
The URA contexts increase nearly 100% for the step2 of FD (from R7_R8 to R6_R7_R8).
The main contribution is the usage of FD on Cell DCH ( increase of blue bars but above all the increase of FD on
FACH state is by far the main contributor for URAPCH state)
It can be notice the clear increments on the amount of SCCP connections active between RNC and SGSN
brought by FD step2 and Step4 (when enabled during a few hours).
The Contexts based on simultaneous number of SCCP connections reveal still a far away number from the
maximum limit of ~81K simultaneous contexts
43
Performance assessment : Contexts: URAPCH
A1TA
The URA contexts increase more than 170% for the last step of FD (extended FD)
The majority of contexts contribution comes from the CellFACH state, the Cell DCH contributes with around
15% of total transitions triggered uniquely by SCRI, while for fach, both SCRI and inactivity contribute for
URAPCH contexts
The T323 @ 10 secs produces more SCRI and so more transitions, however the average amount of contexts is
just slightly increased.
44
Performance assessment : Contexts: DCH
At&t
The traffic usage is not changing as dramatically as URA state transitions, however it can be noticed an increase
mainly due to AO releaseOnly mode which will increase Cell DCH usage with some impact on resources
Apart from this configuration side effect, the URA and FD itself are not changing so much the amount of cell DC
usage even is slightly reduced (due to some traffic carried by Cell FACH).
45
Performance assessment : State transition : DCH to PCH

The current setting is only dealing with
the 3gppR8 IE PSDataSessionEnd and
limited to R6, R7 and R8. This strategy
makes this transition as the most used.
The usage of AO release Only Mode

increase the triggering of this transition
but still we could further increase it by
setting lower timers T2Timer HSDPA
and EDCH
The failures show mainly 2 types of causes:
The other cause which stands for all
the failures occurring during the
Regarding
VS_UEStateTransFail_CellDCH_PCH
(#2958)
The RbReconfFail is triggered by a
failure response by the ue side to the
reconfiguration from DCH to PCH.
There are only two node B responsible
for this higher RbReconfFail in KC03
KSU5050 and KSU6141.
46
At&t
Performance assessment : State transition : DCH to PCH

On the transition from DCH to PCH we can
observe a very clear impact on FD with more
transitions being triggered and lower success
rate.
The success rate has a per day degradation up
to 0.15% worse performance as now we are also
producing transitions due to FD.
The iubEdchDelayVariation change produced
an improvement of 0.1% making the
degradation reduced from 0.15 to 0.05%
(99.95% while 99.85% before)
Observing also per hour a progressive worse
performance with the Fast Dormancy step
evolution, the extended Fast Dormancy
performs worse than the FD due to more
transitions and more impacted we can
conclude that the more older ues we have and
more Ues not supporting 3GppR8 new IE
element the amount of failure will be
proportionally higher. There was several ue
issues reported during this test phase ( see next
slides)
47
A1TA
Performance assessment : State transition : DCH to URAPCH -
UE misbehavior
The live tests of FD also revealed several ue issues specially associated with Extended FD
The main issues observed was inability to make/receive Calls and SMS while PS session is active.
Alu was able to get one of these devices on lab (Samsung Galaxy S i9000) and could observe that the usage
after the UE moved to uraPCH due to SCRI or Radio Bearer Release CS, it is not possible anymore to make CS
call or receive SMS.
There was also other type of ues reported with problems like reboots and loss of coverage indications. Because
there were other actions on network like the isDirectTransitionFromPchToIdleAllowed CRE128146, which also
caused problems on some UEs with call failing and loss of signal. There is no other confirmed correlation of EFD
and UE impacted
Several GM customers suggest to use a White list controlled at Oam Utran Level where we can filter based on
IMEI the UEs which are revealing missbehaviours with Fast Dormancy. This solutions is referred based on
implementation of other suppliers. There is already discussions internally in ALU on how to implement a similar
solution.
48
A1TA
Performance assessment : State transition : DCH <-> FACH
Regarding FD there is a small improvement on the

DCH2FACh success rate .
After the final step of strategy which makes this

transition only available to R99 Ues, it can be noticed
that it is reduced to a few hundreds of transitions per
day with a lower success rate. On KC03 it is improved
when FD is reduced more calls going thru RRC >
DCH which means as well more possibility of calls
ending up in R99 configuration, the change on volume
is small (~350 to ~450) but still producing this kind of
shifts on the success rate
As expected URA brings more transitions of FACH2DCh
due to more UEs regaining CellDCH resources from m
URAPCH and not from Idle. Fast Dormancy will also
increase this trend.
However AO releaseOnly mode will make this trend
reduced because the amount of users in fach is
reduced
The success rate is affected mainly due to new
strategy of EDCH resources and Fallbacks at upsize
which are still counted as failures. It remains At 65%
on current settings and it is about the same value on
both RNCs
49
At&t
Performance assessment : State transition : DCH <-> FACH
With FD there is a small improvement on the DCH2FACh

success rate (~0.05%; also observed on previous
activation). This improvement may be associated with
code changes to avoid race conditions related with SCRI
trigger in case the FD is enabled. There are a few less
attempts (less than 10%)
The St005 success rate decrease with FD, the impact Is
clearly seen on the busy days
Analyzing per hour, We can observe an equivalent
behavior with FD on the morning and evening period
while it is worse on the afternoon period where the
traffic is higher.
This failure can be related with the fact that edch usage
increases and as well the success rate is not as good as
the HSDPA only upsize success rate.
This means that the fact that we have more edch upsize
will explain the degradation observed on FACH to DCH
success rate
The edch success rate itself is not much changed with
FD and it is in fact quite unstable and difficult to
correlate with FD events
The remaining parameters options show no impact on
Success rate. However T323 have a lower value of
transitions which is a normal correlation. Nevertheless
the several modifications performed in small amount of
time do not provide a definite conclusion on this case.
50
A1TA
Performance assessment : State transition : FACH <-> PCH
There is an increase on the amount of

transitions to URAPCH (~+1.5 times) this is
a consequence of :
Directly FD activation, because having SCRI
being triggered in CellFACH triggers a
transition to URAPCH
Indirectly the FD will increase URA, which

makes more Ues to remain in transit
between FACH and URA when the amount
of traffic is small enough preventing them to
go to CellDCH
There is a an improvement on the success

rate of FACH to PCH Transition that is
growing with the first two steps of FD
(mainly step2), the last step (Step3) did not
keep this trend (using only few days of
evaluation for step3 in KC09).
There is an increase of ~100% of transitions
from URAPCH to FACH when FD is enabled
The success rate seems to improve slightly
but it can be related with different
distribution of UE releases triggering this
transition.
51
At&t
Performance assessment : State transition : FACH <-> PCH
There is an increase on the amount of transitions

to URAPCH (~+60%; with Extended it increases
more than 100%), this is a consequence of Having
more URA which makes more Ues to remain in
transit between FACH and URA while the amount
of traffic is small enough preventing them to go to
CellDCH
There is a an improvement on the success rate of
FACH to PCH Transition that is growing with the
first two steps of FD, the Extended FD did not
keep this trend, on the contrary it is degrading
compared with previous equivalent samples.
The overall improve on success rate is 0.3% but is
also associated with a big increase on volume
which makes hard to investigate
This can be related with the fact that these
transitions triggered by the UE (SCRI) are
more successful than the normal inactivity
ones which in many cases correspond to lost
ues.
URAPCH to FACH, there is an increase of ~65% of
transitions; it can go up to 100% for EFD
The success rate keeps the same reference value.
Improvement after EP2 associated with CR include
778223
52
A1TA
Other side effects

of Feature
activation
53
Performance assessment : Other Observations sumup
CellUpdate - The Cell Update components have mainly 3 changes all related with more Ura usage and FD impact:
At&t A1TA
UlDataTx which is a direct consequence of more URA PCH users; UL Paging response due to more Ues in URA which will answer to paging
and Cell reselection is reducing mainly after Ao ReleaseONly parameter modification, this cause is mainly correlated with FACh usage
Paging Success rate
For Att the Total paging success rate is lower as URA PCH usage increase, The RNC point of view of Total success rate of paging decrease to
~75% when we increase the amount URA PCH with Extended FD, this is mainly attributed to PS Paging in URA PCH. However for A1TA this
change is not observed and this metric remains almost constant in some FD activations we can observe a degradation of almost 1% but this
metric has a big variability. There is a higher degradation observed when enhanced Paging Release for Rel7+ devices was enabled
On both NW there is an increase on Paging success rate of CS over URA after FD is enabled which is explained by a better DT behavior. The
EFD have an effect on loosing more ues which then generates more Enhanced paging of CS. since this type of paging is less efficient, it has
a slight decrease on CS normal paging success rate
On ATT the success rate of URA PS Paging indicator point of view is low as it can in some cases insist on paging a UE which is still failing to
respond to paging. The value is normally trending to 65% success rate. However for A1TA this value remains unchanged with a good
performance around 87%
Considering the amount of PS CN paging and URA PS Paging we can observe that only 25%(the highest with EFD) paging intended for RRC
which means that PCH PS Paging is the main driver for the global Paging006 degradation observed
Form CN, Paging success rate degradation of 1.5 to 2% but they maybe statistical due to the significant reduction in attempts where the
failures are now more illuminated
Cs+PS00 upsize - In A1TA the small degradation observed on the success rate of Cs+PS00 upsize is correlated with FD as the volume of Uspizes
of EDCH is also larger, However the success rate of this upsize transition is already presenting a very good performance? better than 99.95%.
MRAB - There is a normal increase of drops in mrab conditions but as well the amount of mrab usage is higher. Looking at Mrab drop per erlang of
mrab we can observe a normal evolution. In A1TA the Mrab CS over PS increased from 36% to a maximum of 44% while for Att the shift is not so
obvious but increase to 54%.
TMU PO - The calculation shows that the Capacity Gain of FD/DT feature (up to Phase 2) was ~+9% as compared with UA07.1.3 (URA_PCH ON),
~+17.8% as compared with UA07.1.3 (URA_PCH OFF) and ~+21.1% as compared with UA08.1 (URA_PCH OFF) and ~+10.3% as compared
with UA08.1 (URA_PCH ON without FD/DT). A1TA have a TMU PO reductions of 8% with FD and up to 15% with EFD the RAB memory is also
increased by 4 to 6%.
54
Performance assessment :PS and CS Paging
At&t
The paging success rate is lower as URA PCH usage increase

The success rate of paging decrease to ~75% when we increase the amount URA PCH with Extended FD.
This behavior is expected as it includes the PS Paging in URA PCH
55
Performance assessment : PS and CS Paging
A1TA
The RNC overall paging success rate presents some variation however a definite correlation with FD is difficult to establish as URA PCH usage increase
Depending on the reference we can observe a decrease on success rate around 1% however it recovers after 7 October to the same reference
values.
This can be partially explained due to PS normal Paging, as it have a small decrease as well even if it remains with a good success rate (more details
below). The CS normal paging does not show any special impact
Data from CN from A1TA Not available
There is a higher degradation observed when isDirectTransitionFromPchToIdleAllowed was enabled (25 and 26 Sept). There was also ues reporting several
problems like rebooting and becoming out of service.
56
Performance assessment : URA CS paging
At&t
There is an increase on Paging

success rate of CS over URA after
FD is enabled
The down turn of success rate is
also noticed during the
RepThreshold=128B and after
decreases a bit to the normal
trend correlated with AO release
only for HSDPA
From CN, there is some
degradation for SMS
DT@256
DT@256
PagingRep
DT@256
DT@256
AO_R_HS
DT@128
AO_R_HS
DT@128
FD4 1/0
FD4 1/0
57
PagingRep
Performance assessment : URA CS paging

There is a slight increase on Paging success rate
of CS over URA after FD is enabled.
There is a degradation observed when the
enhanced Paging Release for Rel7+ devices
CRE128146 was enabled thru the
isDirectTransitionFromPchToIdleAllowed, This CRE
aims at reducing signaling load for releasing a
URA Context which would only need a paging
with an extra information element provided that
would allow R7 and recent Ues to go to idle
without Cellupdate. However it was observed that
some previous release ues were affected and did
not react well to paging. Also on indicators it was
observed a high impact on success rate of the CS
normal Paging and in the paging006 _URA
overall. This CRE was deactivated 2 days after
and the failure scenarios are under investigation.
The Extended FD reduces the Success rate of CS
normal paging back to normal values because
there are more ues entering on enhanced paging
which has a typical worse success rate. This is
also a consequence of more miss synchro state
between ues and RNC.
58
A1TA
Performance assessment : Paging PS URA
At&t
The success rate of URA PS Paging

indicator point of view is bad as it
can in some cases insist on paging
a UE which is still failing to respond
to paging. The value is normally
trending to 65% success rate
Considering the amount of PS CN
paging and URA PS Paging we can
observe that only 25% is paging
intended for RRC which means that
PCH PS Paging is the main driver
for the global Paging006
degradation observed
Uon
Uon
FD2
Form CN, Paging success rate

degradation of 1.5 to 2% but they
are assumed to be statistical due to
the significant reduction in attempts
where the failures are now more
illuminated
FD3
1/0
59
FD2
FD3 1/0
Performance assessment : Paging PS URA
A1TA
The URA PS Paging seems affected slightly once we use more URA but still the success rate is quite ok keeping a value
~87% of success rate
This can explain the small degradation and recovery observed with Paging006_URA
Also the ratio of CN originated paging vs the RNC originated paging is changing from 65% to 40% with FD (it goes down
to 25% with EFD) which can also explain some of the degradation of PS normal paging with more volume of URA
Paging Ps normal is also affected by the enhanced Paging Release for Rel7+ devices CRE128146
60
Performance assessment : TMU Load

The calculation shows
that the Capacity Gain
of FD/DT feature (up
to Phase 2) was
~+9% as compared
with UA07.1.3
(URA_PCH ON),
~+17.8% as
compared with
UA07.1.3 (URA_PCH
OFF) and ~+21.1%
as compared with
UA08.1 (URA_PCH
OFF) and ~+10.3%
as compared with
UA08.1 (URA_PCH ON
without FD/DT).
* Provided by ChingRoung Chou
61
At&t
Performance assessment : RAB & TMU Load
At&t
The calculation based RAB and TMU load shows that the feature could improve the RNC capacity, which also
shifted the limiting factor of KC RNC-09 from TMU limited back to RAB limited in UA08.1. we can also observe a
higher limit of the normalized variable the throughput
* Provided by Ching-Roung Chou
62
Performance assessment : TMU & RAB PO

The Values were calculated at BH
and consider that:
14 & 17 Sept No FD
18 Sept FD2
21 Sept FD3
The TMU PO reduction impact
observed hour to hour is around
8% for FD and 15% to EFD
There is no impact observed on
PO of RAB in spite of some
changes on profile on day to day.
The values presented are rough
estimations and are not
normalized
63
A1TA
Non regression
analysis
64
Performance assessment : Non regression Sum up

CDRCS/KPI11 - There is no impact observed for CDR CS or in KPI11 for ATT
At&t A1TA
CDR PS /KPI13
For ATT the impact of FD was a degradation of 0.03% while for A1TA the CDR PS has an impact during the activation of FD and EFD on
September can go up to 0.08%. However the activation of FD2 only in October do reveal a much lower impact (0.01%).
1.
The main cause of these impacts are inn both cases the increase of FACh drops which were mainly caused by higher fach usage and Cell
Reselection failure which increase significantly with FD/URA AR 4153335
2.
There are more failures on the HHO 3g2g_PS correlate with the EFD activation, this scenario is rare and was not caught on traces
3.
the PS00 Drops it is correlated with the usage of CS+PS00 which drop the ps connection in case of HHO 3g2g
The CSSR Cs/KPI14 performance remains almost unchanged with FD, however there are a few small impacts
1.
RRC are reduced around and this can cause a small impact on the success rate the highest impacts observed on RRC013 were of 0.03% or
0.09% for ATT market where the decrease of RRC is more significative
2.
For A1TA the impact on IuSccp ConnSuc rate is deteriorated with FD due to more URA usage, but it is not the cause of it, the Paging Repetition
fallback reveal the source of this degradation together with URA usage this scenario is still under investigation : AR 1-4108755 under
investigation
3.
The RAB success rate RAB011_CS is not affected by FD and remains unchanged
The CSSR PS/KPI16 performance is affected by FD

1.
The RRC can have impacts up to 0.08% (0.15% in Sept) of degradation however it was shown that this is a impact due to lower RRC attempts
and consequently a higher percentage of bad radio conditions ues forced this distribution to be slightly affected and produce this impact
2.
The Security mode command impact is transparent to FD as it is mainly caused by two Node B G895 and G552
3.
The RAb assignment stage is also affected in August and in September (0.1% at worse cases with EFD enabled), however no impact is seen in
October, because the concept of accessibility should be enlarged also to the PCH to FACH/DCH reconfigurations an additional accessibility
formula should be considered to evaluate URA/FD networks (RAB017_URA is available on our UA8 indicators and detailed in backup).
In terms of remaining impacts of non regression there was a slight improvement on UCU usage by using FD2, however the same observation was not
confirmed in A1TA. Other Resources metrics do not reveal any impact with FD2(CEM, Power, ULLOad, throughput , traffic, bler).
65
Performance assessment : non regression: KPI13-PS call drop

Looking at the kpi 13 we can
se a degradation up to 0.03%
The lower chart shows the
main components of PS
abnormal release .
However only the FACH and
HSDPA are contributing for
KPI13.
The HSDPA remains stable or
even improve while FACH
increases with FD2.
The PCH drop is mainly
impacting KPI33 and will be
addressed later as being
consequence of more URA
usage
66
At&t
Performance assessment : non regression: KPI13-PS call drop
On the lower chart by

removing the failures on Cell
reselection and representing
the drop per erlang we can
observe a stable behaviour or
even an over all
improvement in order to
keep a low or no impact on
PS drop we must make sure
that the FACH usage is not
increasing with FD activation
25000
Uon
EDCH
FD1
FD2
AO R HS;DT@128
FD4 I/0
KC9
FD3
FD3off
PagingRep
20000
15000
10000
5000
0
15Jun
18Jun
21Jun
24Jun
27Jun
30Jun
3Jul
6Jul
9Jul
12Jul
15Jul
18Jul
21Jul
24Jul
27Jul
30Jul
2Aug
5Aug
8Aug
11Aug
14Aug
17Aug
20Aug
23Aug
26Aug
29Aug
1Sep
4Sep
7Sep
10Sep
13Sep
The major explanation for the

fach drop is simply a higher
usage of FACH channel
produced by FD2, one of the
failure components observed
is the Cellreselection failure.
This failure counter includes
some FACH mobility scenarios
addressed by AR 4153335.
At&t
VS_IuAbnormalReleaseRequestPs_DlAsCnfTrbCellFa
67
Performance assessment : non regression: PS call drop

Ps drop increases as expected,
this is due to the higher amount
of transitions into URA PCH and
less denominator but lets look at
each component in detail
The Iu PS drop that includes all
transitions on denominator and
also removing timeouts from
numerator is valid only after Ep2.
ON the FD activation in Sept,
there is an increase of the drop
rate with FD + EFD enabled of up
to 0.08%.
However by removing the same 9
sites referred before in CS section
we only have an impact of 0.04%
After the single FD October
activation, we observe an impact
around 0.01%
68
A1TA

Considering only the target
configuration with FD only
(No EFD), we can see that:
The amount of drops
that will be contributing
on numerator of KPI of
Psdrop rate are around
more 2500 drops
From these figures and
the previous analysis done
for AO upsize EDCH we can
conclude that the extra drops
in FACH are explained by the
Cell reselection failure.
The chart showing the fach
drops removing
Cellreselection failures per
erlangs do not show any
impact with FD activation
69
A1TA

UA0813EP2
16000
FD2
FD3
FD2_T323 Fdoff
GQ07
FD2
A1TA
UA0813EP3
40000
14000
35000
12000
30000
10000
25000
8000
20000
6000
15000
4000
10000
2000
5000
VS_IuReleaseReqPs_DlRLCErrSRB(U599_8)(Event)
VS_IuReleaseReqPs_RadioCnxUeLost(U599_6)(Event)
VS_IuReleaseReqPs_ReleaseDueToUtranGeneratedReason(U599_14)(Event)
VS_IuReleaseReqPs_UlRLCErrSRB(U599_9)(Event)
16Oct
14Oct
15Oct
13Oct
12Oct
11Oct
9Oct
10Oct
8Oct
7Oct
6Oct
5Oct
4Oct
3Oct
2Oct
1Oct
30Sep
29Sep
28Sep
27Sep
26Sep
25Sep
24Sep
23Sep
22Sep
21Sep
20Sep
19Sep
18Sep
17Sep
16Sep
15Sep
14Sep
13Sep
12Sep
11Sep
0
10Sep
VS_IuReleaseReqPs_UnspecifiedFailure(U599_3)(Event)
Main causes of PS drops that are shifting with FD are ReleaseDueToUGR which increase this can be due to extra
reconfigurations failures after failing reconfiguration timer T361 this is mainly affected by EFD (+2K FD; +5K EFD)
Another high runner cause is the unspecified failures with high increase of 5 to 7K for the worse days with EFD
correlated with higher drops on irat HO to 2g of Cs+ps00
Then there are ULRLCSRBErr which have a an impact on Global RNC but after removing the Critical node Bs we have a
negligible increase (~+500 failures Also on the last activation of FD only, it was not observed an increase by comparing
with the reference days of 27 and 28 Sept
70

UA0813EP2
800
FD2
FD3
GQ07
FD2_T323 Fdoff
FD2
A1TA
UA0813EP3
3500
700
3000
600
2500
500
2000
400
1500
300
1000
200
500
100
0
VS_IuReleaseReqPs_RepeatedIntegrityCheckFailure(U599_4)(Event)
VS_IuReleaseReqPs_T360Expiry(U599_12)(Event)
VS_IuReleaseReqPs_UtranPageFail(U599_20)(Event)
VS_IuReleaseReqPs_UlRLCErrTRB(U599_11)(Event)
VS_IuReleaseReqPs_CellReselFail(U599_19)(Event)
VS_IuReleaseReqPs_DlRLCErrTRB(U599_10)(Event)
VS_IuReleaseReqPs_FailureInTheRadioInterfaceProcedure(U599_16)(Event)
16Oct
14Oct
VS_IuReleaseReqPs_AbnormalConditionTimerRelocExpiry(U599_7)(Event)
15Oct
13Oct
12Oct
11Oct
10Oct
9Oct
8Oct
7Oct
6Oct
5Oct
4Oct
3Oct
2Oct
1Oct
30Sep
29Sep
28Sep
27Sep
26Sep
25Sep
24Sep
23Sep
22Sep
21Sep
20Sep
19Sep
18Sep
17Sep
16Sep
15Sep
14Sep
13Sep
12Sep
11Sep
10Sep
For the remaining causes of PS drop we have more Cell reselection failures; There is a AR 4153335 to address some scenarios of
Cell reselections failures With priority for FD specifically but it should be evaluated for a general URA behavior compare with
589_7 on next slide, it increases around 800 to 1K
There is also more UL and DL err in TRB (specially DL and mainly affected by EFD) ~+ 500 so the nominal configuration was not
affected (FD only)
More Utran page fail associated with Fast Dormancy extended also seen on the Enhanced URA Paging feature ratio of RNTI success vs
TMSI Success (~+ 200) (see in backup)
There is still the case of VS_IuReleaseReqPs_AbnormalConditionTimerRelocExpiry(U599_7)(Event) which increases on a small amount of
samples
71
There are more failures on the HHO 3g2g_PS correlate with the EFD activation
The extra failures correspond to approx 600 events
This scenario does not have traces captured and so investigation can not proceed
72
A1TA
A1TA
Regarding the PS00 Drops it is correlated with the usage of CS+PS00 vs HHO 3g2g. So in case of HHO to 2G of CS call the PS00 is
released
Below we can see the increase of drops on PS 00 correlated with the drop PS due to CS irat HHO. The missing gap between counters
#2680 and #589_0 corresponds to the gap between CS+PS_HS where the screening of #589_HSDPA should be pegged.
73
At&t
Performance assessment : non regression: KPI14 (Cssr CS)

PagingRep
FD3
FD3off
99.70%
99.50%
99.30%
99.10%
98.90%
98.70%
RRCConnectionSuccessRateExcRep_RRC021_CR_Cs(URRC021_CR_Cs)(%)
Uon
CSSRBRetainability
13Sep
10Sep
7Sep
4Sep
1Sep
29Aug
26Aug
23Aug
20Aug
17Aug
14Aug
11Aug
kpi32a
KPI14w/nbr
FD4 I/0
KC09AO R HS;DT@128
EDCH
PagingRep
FD3
FD1
FD3off
FD2
0.995
8Aug
5Aug
2Aug
30Jul
27Jul
24Jul
21Jul
18Jul
15Jul
9Jul
12Jul
6Jul
3Jul
30Jun
27Jun
24Jun
21Jun
18Jun
15Jun
98.50%
0.99
0.985
0.98
0.975
0.97
KPI14UA8RRCModified
74
KPI14w/nbr
13Sep
10Sep
7Sep
4Sep
1Sep
29Aug
26Aug
23Aug
20Aug
17Aug
14Aug
11Aug
8Aug
5Aug
2Aug
30Jul
27Jul
24Jul
21Jul
18Jul
15Jul
12Jul
9Jul
6Jul
3Jul
30Jun
27Jun
24Jun
0.965
21Jun
With modified formulas this

degradation is not observed as the
amount of state transition is
considered on Accessibility of RRC
successes (see more details in
backup slides)
FD4 I/0
KC09 AO R HS;DT@128
EDCH
FD1
FD2
99.90%
18Jun
It is however noted that the RRC

accessibility KPI35CS is slightly
affected with URA or with FDstep2,
this brings a degradation of
KPI35CS indicator of about 0.09%
which has an impact on 0.04% on
global KPi14, this is deduced as
being an effect of different
distribution of failures between RRC
stage and state transitions
Uon
15Jun
The CSSR of CS is kept constant

without major impacts in KC09
At&t
Performance assessment : non regression: KPI32

Uon
0.999
FD4 I/0
KC09 AO R HS;DT@128
EDCH
FD3off
FD2
0.9985
PagingRep
FD3
FD1
0.998
0.9975
0.997
0.9965
0.996
13Sep
10Sep
7Sep
4Sep
1Sep
29Aug
26Aug
23Aug
20Aug
17Aug
14Aug
11Aug
8Aug
5Aug
2Aug
30Jul
27Jul
24Jul
21Jul
18Jul
15Jul
12Jul
9Jul
6Jul
3Jul
30Jun
27Jun
24Jun
21Jun
18Jun
15Jun
0.9955
KPI32aUA81
Uon
600
EDCH
FD1FD2
FD3
FD3off
KC09 FD4 I/0
AO R HS;DT@128
PagingRep
20000
500
15000
400
300
10000
200
5000
100
RAB_FailEstab_CS_RBSetupExp(U2629_8)(Event)
RAB_FailEstab_CS_RLFailNodeBErr(U2629_4)(Event)
RAB_FailEstab_CS_RLFailOther(U2629_3)(Event)
RAB_FailEstab_CS_ULLoad(U2629_0)(Event)
RAB_FailEstab_CS_LackTranspRsrc_NeighbRnc(U2761)(Event)
RAB_FailEstab_PS_DLPwr(U2631_1)(Event)
75
RAB_FailEstab_CS_RBSetupFail(U2629_7)(Event)
RAB_FailEstab_CS_RLFailNodeBResource(U2629_5)(Event)
RAB_FailEstab_CS_RLReconfigExp(U2629_6)(Event)
RAB_FailEstab_CS_LackTranspRsrc(U2762)(Event)
RAB_FailEstab_PS_CodeStarv(U2631_2)(Event)
13Sep
10Sep
7Sep
4Sep
1Sep
29Aug
26Aug
23Aug
20Aug
17Aug
14Aug
11Aug
8Aug
5Aug
2Aug
30Jul
27Jul
24Jul
21Jul
18Jul
15Jul
12Jul
9Jul
6Jul
3Jul
30Jun
27Jun
24Jun
21Jun
0
18Jun
0
15Jun
Include
Performance assessment : non regression: CS CSSR

The CSSR of CS is kept constant without
major impacts
The RRC013_CS is affected with some
degradation but it is then kept on same
trend even after the FD is turned off on
the 27 an d 28 of Sept. by making average
on working days before and after of FD we
can observe at most a degradation of
0.03% of success rate (0.03% is also the
stdev of RRC013 on working days)
However it may affect the cs statistics due
to lower setup of RRC Cs procedures
(Approx 20%) to be detailed later
together with PS RRC
The Iusccp failure also seems related with
the FD. There is an AR 1-4108755 open
due to A Rejected Iuconnection sent by
CN. This degradations was correlated with
PR activation & upsize from URAPCH, so it
degrades further with FD since ura usage
increases but it is not the main cause for it
After roll back of PR (not needed anymore
to achieve baseline on Paging012) we can
see that the recovery is complete.
76
A1TA
Performance assessment : non regression: CS CSSR - RAB
The RAB success rate is not affected by FD.

On the days where there are more failures due to Dl Power but we have also more attempts
The last activation (FD2) do not reveal any impact on RAB011 and even a slight increase can be
observed compared to previous periods
77
A1TA
4 - Performance assessment : non regression: KPI16
PagingRep
FD3
FD3off
FD2
99.7%
99.5%
99.3%
99.1%
98.9%
98.7%
13Sep
7Sep
10Sep
4Sep
1Sep
29Aug
26Aug
23Aug
20Aug
17Aug
14Aug
11Aug
8Aug
5Aug
2Aug
30Jul
27Jul
24Jul
21Jul
18Jul
15Jul
12Jul
9Jul
6Jul
3Jul
30Jun
27Jun
24Jun
21Jun
18Jun
98.5%
RRCConnectionSuccessRateExcRep_RRC021_CR_Ps(URRC021_CR_Ps)(%)
Uon
EDCH
FD1
FD2
FD4 I/0
KC09AO R HS;DT@128
PagingRep
FD3
FD3off
0.999
0.998
0.997
0.996
KPI35psUA8RRCModified
78
KPI16UA8RRCModified
13Sep
10Sep
7Sep
4Sep
1Sep
29Aug
26Aug
23Aug
20Aug
17Aug
14Aug
11Aug
8Aug
5Aug
2Aug
30Jul
27Jul
24Jul
21Jul
18Jul
15Jul
12Jul
9Jul
6Jul
3Jul
30Jun
27Jun
24Jun
0.995
21Jun
Kpi33 wil be analysed on next

slides
99.9%
18Jun
The KPI35PS can be modified as

stated above for kpi35CS in order
to reflect the state transition in
RRC resulting on a degradation
of 0.04% overall which is now
only due to kpi33
FD4 I/0
KC09 AO R HS;DT@128
EDCH
FD1
15Jun
The main contributors for this

degradation are the KPI33 and
the KPI35 PS
Uon
15Jun
The degradation of KPi16 is

observed at URA activation, then
it further degrades at FDstep2
activation and at the last step of
optim resulting in a total
degradation of 0.34%
At&t
4 - Performance assessment : non regression: Kpi33

The Kpi33 degradation ranges from 0.09 to
0.1% considering the reference periods in
Ua713 on both RNCs
Uon
FD4 I/0
KC09AO R HS;DT@128
EDCH
PagingRep
FD3
FD1
0.999
At&t
FD3off
FD2
0.997
0.989
0.987
UEStateTrans_UraPCH_CellDCH_Successrate
Uon
50000
13Sep
10Sep
7Sep
4Sep
1Sep
29Aug
26Aug
23Aug
20Aug
17Aug
14Aug
11Aug
8Aug
5Aug
2Aug
30Jul
UEStateTransSucc_PCH_FACHsuccessrate
Kpi33rabassignment_R
FD4 I/0
KC09AO R HS;DT@128
EDCH
PagingRep
FD3
FD1
45000
27Jul
24Jul
21Jul
18Jul
15Jul
12Jul
9Jul
6Jul
3Jul
30Jun
27Jun
24Jun
21Jun
18Jun
15Jun
0.985
FD3off
FD2
40000
35000
30000
25000
20000
15000
10000
5000
failures(attsuc)PCH2FACH
79
Failures(Attsucc)URAPCH2DCH
13Sep
10Sep
7Sep
4Sep
1Sep
29Aug
26Aug
23Aug
20Aug
17Aug
14Aug
11Aug
8Aug
5Aug
2Aug
30Jul
27Jul
24Jul
21Jul
18Jul
15Jul
12Jul
9Jul
6Jul
3Jul
30Jun
27Jun
24Jun
0
21Jun
Looking at failures point of view we can

notice that KC09 have a distributions of 50%
due to URA2FACH; 35% due to URA2DCH
and remaining 15% due to RAB
establishment on PS
0.991
18Jun
There is also a worse performance of RAB

establishment resulting from the very low
amount of attempts after the last step of AO
releaseOnly left on the RAB establishment
phase
0.993
15Jun
The main contributors for KPI33 are the state

transitions from URA to Fach and from URA
to PCH. These transitions have some ARs
CRs to be corrected that will improve the
current success rate. For more details see the
detail sections on these transitions above
0.995
RABassignmentFailure C
Performance assessment : non regression: PS CSSR
A1TA
The PS Success rate is severely affected by FD and above all by EFD. By comparing with second Activation on 1st
October we can conclude that previous activations was also impacted by some degraded NodeBs
There is a degradation around 0.5% overall, however the next slides will breakdown this indicator to its
components while showing the impact of each one as well as some special Node B which contribute with more
degradation
80
Performance assessment : non regression: PS CSSR - RRC
A1TA
The RRC degradation is quite clear for the PS (ranges from .1% to .15%) in september and 0.08% in F6, while it
reduces the number of attempts and failures it becomes difficult to prove the true reason for this degradation.
The hypothesis formulated here is that it is related with the different distributions of attempts which will experience
worse radio conditions (eventually calls dismissed from URAPCH state) which will now increase the number of poor radio
conditions set of calls for RRC. This can also affects the subsequent stages of call setup to prove this hypothesis will be
the objective of next slides
The same is not observed for Cs calls as they are much less affected by URA due to smaller RRC volume reduction
produced by PCH state
81

RRC003 and RRC021 look both degraded
however while RRC003 range to
degradation up to 0.2% the RRC021
have a lower impact of around 0.06%
The main difference between RRC021
and RRC013 are the repetitions in case
of cell reselection across different TMUs
The RRC003 (as RRC013 depicted
before) will give the point of view of
success rate for all repetitions, including
repetitions due to cell reselection,
however for RRC021 it is only
considering the last attempt so removing
any other situation of repetition due to
cell reselection this can be another
piece for the hypothesis
formulated before, while calls that
are in worse radio conditions are
typically in serving areas with
overlap and pilot pollution
producing as well more reselection
which is a cause for more failures
for state transitions leading also for
failures on RRC stage on those
indicators prone to reselections
failures
82
A1TA

These charts shows the
top contributors for the
RRC establishment
which are more reduced
with the FD
introduction.
An these are as well the
ones more affected by
worse performance
once FD is activated.
These charts together
with next ones are also
important to produce
our prove that the less
attempts are the ones
affected by worse
performance
83
A1TA
A1TA
The quick repetition of the RRC Connection Setup is activated based on the P-CPICH Ec/No (bydefault) or
RSCP measurement received from the RRC Connection Request message reported by the UE. If these quality
measurements are below a given threshold (-10dB for A1)
The higher usage of Algorithm of RRCQuickRepetition provide another piece on the prove to sustain that the
radio conditions are degraded for the new amount of calls attempting to get a rrc connection PS
84
Performance assessment : non regression: PS CSSR RRC
A1TA
The bottom charts were taken from RRC connection request msgs containing the RF EC/No & the Propagation
delay Distribution of traces taken as reference (NO FD) and traces taken with FD & EFD activated
The results are pretty clear showing a wider PDF function when the FD & EFD are activated (or a slower rising
CDF function, which means that there are now more frequent samples with lower radio conditions
The charts below and the previous ones presented on above slides are enough to validate our Hypotehsis The
RRC lower success rate is a consequence of worse radio conditions UEs attempting on the PS RRC
85
Performance assessment : non regression: PS CSSR - RAB
A1TA
The PS RAB establishment success rate is degraded specially with Extended FD

The degradation is up to 0.1% on the Cluster removing 9node Bs with reported problems and considering
the worst days
However on the FD2 Re_activation we did not observe any degradation.
86

Considering the strategy
followed up to now, which
considers only as part of drop
rate the CellDCh and FACH
usage, assuming that otherwise
user is on idle (ura or idle) and
dont need NW resources. We
need to design also another
formula of accessibility which
includes the access to FACH or
Cell DCH channels types and so
URAPCH Upsizes success rate
should part of this new equation
(KPI33).
The diff components help to
evaluate truly the user point of
view to access resources either
(fach or DCh), and it is easy to
understand that in case we need
to rely on higher amount of
triggering of URA to DCH we will
be affected by a lower success
rate.
87
A1TA
Performance assessment : non regression: UCU usage
At&t
The EDCh optim has a big impact on UCU usage decreasing the 2ms and increasing the other configurations (R99; EDCH
10ms and HSDPA) this is expected.
The FDStep2 have decrease effect (R99; EDCH 10ms and HSDPA) due to more users going thru the FACH and less DCh
observed
The HSDPA ReleaseOnly will put back the effect of FDStep2 taking more UCU resources
25
Uon
KC09
EDCH
FD1
AO_R_HS;DT@128
FD4 I/0
PagingRep
FD3
FD2
FD3off
20
15
10
15Jun
17Jun
19Jun
21Jun
23Jun
25Jun
27Jun
29Jun
1Jul
3Jul
5Jul
7Jul
9Jul
11Jul
13Jul
15Jul
17Jul
19Jul
21Jul
23Jul
25Jul
27Jul
29Jul
31Jul
2Aug
4Aug
6Aug
8Aug
10Aug
12Aug
14Aug
16Aug
18Aug
20Aug
22Aug
24Aug
26Aug
28Aug
30Aug
1Sep
3Sep
5Sep
7Sep
9Sep
11Sep
13Sep
VS_RF_ChanElementUsageUCU_EDCH_10ms_Mean_ONB(U35094)(%)
VS_RF_ChanElementUsageUCU_EDCH_2ms_Mean_ONB(U35096)(%)
VS_RF_ChanElementUsageUCU_EDCH_Mean_ONB(U35064)(%)
VS_RF_ChanElementUsageUCU_HSDPA_Mean_ONB(U35066)(%)
VS_RF_ChanElementUsageUCU_R99_Mean_ONB(U35062)(%)
88
Performance assessment : non regression - CEM

No impact observed on CEM resources correlated with FD activation
89
A1TA
At&t
Performance assessment : non regression - ULoad

No impact observed on UL Load correlated with FD activation
105.2
Uon
EDCH
FD1FD2
KC09
FD3
FD4 I/0
PagingRep
0.007
FD3off
AO_R_HS;DT@128
105.3
0.006
105.4
0.005
105.5
0.004
105.6
0.003
105.7
0.002
105.8
0.001
105.9
106
15Jun
17Jun
19Jun
21Jun
23Jun
25Jun
27Jun
29Jun
1Jul
3Jul
5Jul
7Jul
9Jul
11Jul
13Jul
15Jul
17Jul
19Jul
21Jul
23Jul
25Jul
27Jul
29Jul
31Jul
2Aug
4Aug
6Aug
8Aug
10Aug
12Aug
14Aug
16Aug
18Aug
20Aug
22Aug
24Aug
26Aug
28Aug
30Aug
1Sep
3Sep
5Sep
7Sep
9Sep
11Sep
13Sep
UplinkRSSI_ULOAD002_CR_Avg(UULOAD002_CR_Avg)(dBm)
PercentageMaximumWidebandReceivedPower_ULOAD018_CR_ONB(UULOAD018_CR_ONB)(%)
90
Performance assessment : non regression - ULoad
A1TA
No impact observed on UL Load correlated with FD activation, the indicator have big variations
but not correlated with FD
91
At&t
Performance assessment : non regression - DL Power Usage

No impact observed
correlated with FD activation
Uon
FD4 I/0
KC09 AO R HS;DT@128
EDCH
24.0%
PagingRep
FD3
FD1
FD3off
FD2
22.0%
20.0%
18.0%
16.0%
14.0%
12.0%
13Sep
10Sep
7Sep
4Sep
1Sep
29Aug
26Aug
23Aug
20Aug
17Aug
14Aug
11Aug
8Aug
5Aug
2Aug
30Jul
27Jul
24Jul
21Jul
18Jul
15Jul
9Jul
12Jul
6Jul
3Jul
30Jun
27Jun
24Jun
21Jun
18Jun
15Jun
10.0%
AverageHSDPAPowerused_HSDPA010_CR_ONB(UHSDPA010_CR_ON
FD4 I/0
KC09AO R HS;DT@128
PagingRep
FD3
Percentage_NonHS_PowerUsed_Power001_B_Avg_ONB(UPower001_B_Avg_O
92
13Sep
10Sep
7Sep
4Sep
1Sep
29Aug
26Aug
23Aug
20Aug
17Aug
14Aug
11Aug
8Aug
5Aug
2Aug
30Jul
27Jul
FD3off
24Jul
21Jul
18Jul
15Jul
12Jul
9Jul
6Jul
3Jul
30Jun
EDCH
FD1
FD2
27Jun
21Jun
18Jun
24Jun
Uon
30
29
28
27
26
25
24
23
22
21
20
15Jun
The HSDAP Power used have

a short increase at the FD2
Activation but then resumes
back to same values of trend
Performance assessment : non regression - DL Power Usage

No impact observed on DL Power Usage correlated with FD activation
93
A1TA
Performance assessment : non regression: BLER CS
At&t
There is a significant impact on Voice Bler however it is not related with FD
Uon
0.33%
KC09
EDCH
PagingRep
FD3
FD1
0.31%
AO_R_HS;DT@128
FD4 I/0
FD3off
FD2
0.29%
0.27%
0.25%
0.23%
0.21%
0.19%
0.17%
CsVoiceUplinkBLER_BLER012_CR(UBLER012_CR)(%)
94
13Sep
11Sep
9Sep
7Sep
5Sep
3Sep
1Sep
30Aug
28Aug
26Aug
24Aug
22Aug
20Aug
18Aug
16Aug
14Aug
12Aug
8Aug
10Aug
6Aug
4Aug
2Aug
31Jul
29Jul
27Jul
25Jul
23Jul
21Jul
19Jul
17Jul
15Jul
13Jul
11Jul
9Jul
7Jul
5Jul
3Jul
1Jul
29Jun
27Jun
25Jun
23Jun
21Jun
19Jun
17Jun
15Jun
0.15%
Performance assessment : non regression: Other

No impact observed on the Cs voice bler however there is an AR open for the URA activation (AR1-4153337)
95
A1TA
Part C
Conclusions and
recommendation
for activation
96
Conclusions and recommendation for activation
The setting of Fast Dormancy feature providing more benefits and less constraints is the activation of R6R7R8 Fast
Dormancy (without extended fast Dormancy).
ExtendedFD proved to increase further the gains of FastDormancy but in A1TA there were impacted end users
affected KPIs The usage of a filtering procedure based on IMEI is currently under internal evaluation to answer
some customer requests.
The usage of AOMode=releaseOnly for EDCH & HSDPA confs, provide some benefits in terms of KPIs and FACH
usage but also prove to take more resources on NodeB.
Regarding the other related parameter tests executed in parallel with the feature:
1.
The T323 can be reduced to less than 30 secs. this will save some FACH usage and theoretically some DCH however this was very
hard to observe on A1TA FOA. On the other hand it can also increase the number of state transitions.
The gains in CPU are small but consistent it presnets a gain of 8% for A1TA and 9 % for ATT, while in ATT FD +URA
could produce combined gains up to 21%
Other gains are also observed on the Reduction of RRC and RAB establishment PS, reduction on PS Paging load from
SGSN and latency reduction for PS users
Although there are a long and complex non regression analysis , the feature is considered as validated even if there
are side effects produced by it, namely:
1.
Higher Ps drops in fach mainly produced by higher FACH usage and Cell reselection failure AR 4153335
2.
Iusccp connsuc rate CS affected due to a particular combination of features FD/URA and Paging repetition. This investigation is still
on going AR 1-4108755. However the issue is not related with FD even if it can be further increased by FD
3.
There are a much different distribution of RRC in PS and at a lower extend as well in CS which affect the Success rate metrics,
however without impact on user. Also for ATT some special metrics were proposed.
4.
Paging Evaluation should be closely monitored if possible with access to CN statistics under stable periods of operation in order to
have a reliable assessment.
97
Reference Document
FD FSM:
https://wcdma-ll.app.alcatellucent.com/livelink/livelink.exe?func=ll&objId=64033308&objAction=browse&viewType=1
FD FA (ATT):
FD FA (A1TA)
SmartPhone features workgroup webpage
https://wcdma-ll.app.alcatellucent.com/livelink/livelink.exe?func=ll&objId=66326569&objAction=browse&sort=name
98
Backup Slides
99
Configuration, Parameters and RAN Model (1/5)

isFastDormancyAllowed indicates the activation/deactivation of the Fast Dormancy procedure
Parameter change is taken into consideration at the reception of the next RRC SIGNALLING
CONNECTION RELEASE INDICATION message
Parameter
isFastDormancyAllowed
Object
RadioAccessService
RAN Path
RNC / RadioAccessService
Granularity
RNC
Range and Unit
Boolean {True, False}
User and Class
Customer, 3-a2
Value
True, for feature activation
100

ueVersionForScri indicates which UE versions are available with Fast Dormancy feature,
provided by the specific service provider
Parameter
ueVersionForScri
Object
RadioAccessService
RAN Path
Granularity
RNC
Range and Unit
Enumeration {R6_R7_R8, R7_R8, pre_R8, R_8}
User and Class
Customer, 3-a2
Value
R8 for feature activation, larger triggering with pre_R8
R6_R7_R8 3GPP R6, R7, R8 and later UE versions are applicable for Fast Dormancy
pre_R8 3GPP R8 and earlier UE versions are applicable for Fast Dormancy
R7_R8 3GPP R7, R8 and later UE versions are applicable for Fast Dormancy
R8 3GPP R8 and later UE versions are applicable for Fast Dormancy
This parameter will not limit the extended Fast Dormancy, it is just needed to enforce the release of UE
under Fastdormancy domain of activity
101

t323 defines the T323 UE timer value. This timer is started after the SCRI triggered by UE.
While this timer running the UE will not resend any SCRI and will wait for the Network response
proposing the next UE RRC state.
When T323 expires the ue can decide if another SCRI should be sent depending if the ue have any
update in terms of no PS data from Upper layers.
Parameter
t323
Object
RadioAccessService / UeTimerCstConnectedMode
RAN Path
Granularity
RNC
Range and Unit
Enumeration {0, 5, 10, 20, 30, 60, 90, 120}
User and Class
Customer, 3-a1
Value
T323_30
102

isExtendedFastDormancyAllowed indicates if the Fast Dormancy functionality is also
applicable for pre-R8 UEs, not supporting SCRI cause
Parameter
isExtendedFastDormancyAllowed
Object
RadioAccessService
RAN Path
Granularity
RNC
Range and Unit
Boolean {True, False}
User and Class
Customer, 3-a2
Value
TBD (mandatory when flag isFastDormancyAllowed is set to True)
Other important precedence parameters

isAlwaysOnAllowed : Parameter that allows to activate the Always on state transitions including
CELL/URA_PCH
pchRrcStates: Parameter for enabling Cell/URA_PCH (UA5), also defines the target RRC state
when a RRC transition triggered by Fast Dormancy occurs
103
Performance assessment : Contexts: DCH
A1TA
The traffic in CellDCH is reducing slightly, this small reduction is typical of URA increase when some more UEs will remain between URA and FACH,
avoiding this way the usage of CellDCH.
The Amount of reduction observed on September activations is around 10%. The low Buffer thresholds will not allow much traffic being carried out
in FACH.
The main objective of T323 reduction was to check if we had any reduction on Cell DCH URA by triggering more frequently SCRI, however this is
not the case. Even if the DCHtoURAPCH increase, it is not impacting DCH usage, as we have lower T1, the call goes either to FACH or to URA
quickly.
104
Performance assessment : State transition : Direct transition DT At&t

The first picture shows the global
DT which increase in KC09 we
can observe that the success rate
decreases mainly after Ua813 due
to known AR 1-4036297
Counter
broken
@813tap2
The Failures on DT do not show

any special case of Failure they
are globally timeouts.
The global success rate however
remains the same, we can even
observe a small increase with
more triggering, but over all value
is around 98.89%
Current settings provide this
transition with a weight of 10% of
PCH2FACH and 25% of
FACH2DCH (using at FD activation
the RT@512)
105
Performance assessment : State transition : Direct transition DT A1TA

The first picture shows the global DT
which increase due to more UEs in
URAPCH (+~60%)
The global success rate is now improved
due to correction in EP2 of DT upsize
over pegging of Attempts CR773788
Also the split of EDCH vs HSDPA for
direct transition is having more EDCH
component as we are triggering FD only
for 3gppR6 and above.
The success rate of EDCH is worse but
it is not changing with FD.
Also on the same trend the T323 show
a slightly higher amount of upsize
triggered by DT that could be explained
by a equally higher frequency of SCRI
some ues R5 trigger the cause TVI for
3gppR6 ues
106
Performance assessment : State transition : DCH to URAPCH -
UE misbehavior
INTERNAL
Information coming from customer

INFO 1 (2012)
Pre-release 8 is only recommended to activate for some models. VendorX has implemented a TAC database:
It was found critical issues with Blackberry, HTC and Samsung Galaxy, so it is not recommended to use this
feature for these Pre-release 8 UE.
Currently deployed in OperatorX activated for the next mobiles: iPhone 4, iPhone 3, iPad, iPad 2, Samsung i5800,
Samsung Galaxy Mini, Samsung Wave S8500, Samsung S5830, Samsung i8000, Samsung P1000, Samsung Nexus S (i9020),
Motorola DEFY, Nokia C7, Nokia N8, Nokia N97, Nokia N97 mini, Sony Ericsson X10 mini, Sony Ericsson X10 mini pro, Sony
Ericsson Vivaz
INFO 2 (2011)
An issue was discovered with the Qualcomm chipset:
Network request the UE to switch from Connected (DCH) to URA_PCH, the device
experiences a Cell Change within the same URA area and a new PS call is
requested, the device tries to switch from URA_PCH to connected mode
The chipset baseband processing resets automatically. Customer perceives the
device loses coverage for a certain period, or UE needs to be rebooted.
> Workaround:
The UE is switched to Cell_FACH instead of URA_PCH.
INFO 3 (2011)
It was found critical issues with Blackberry and HTC, so it is not recommended to
use this feature for these Pre-release 8 UE.
Blackberry UE send SCRI (Signalling Connection Release Indication) and go to PCH, If UE out of service
and re-enter service area at CELL_PCH state, UE state will be abnormal and cannot establish PS and CS
service anymore.
HTC After SCRI the UE sends IDT (Initial Direct Transfer) to recover PS service, RNC sends UE service
request accept, but UE cannot recover PS service anymore.
107
A1TA
Performance assessment : State transition : CS Setup over FACH

250000
Uon
KC9
EDCH
FD3
FD1
FD2
FD4 I/0
PagingRep
At&t
120.%
AO_R_HS;DT@128
FD3off
100.%
200000
80.%
150000
60.%
100000
40.%
50000
20.%
0
15Jun
17Jun
19Jun
21Jun
23Jun
25Jun
27Jun
29Jun
1Jul
3Jul
5Jul
7Jul
9Jul
11Jul
13Jul
15Jul
17Jul
19Jul
21Jul
23Jul
25Jul
27Jul
29Jul
31Jul
2Aug
4Aug
6Aug
8Aug
10Aug
12Aug
14Aug
16Aug
18Aug
20Aug
22Aug
24Aug
26Aug
28Aug
30Aug
1Sep
3Sep
5Sep
7Sep
9Sep
11Sep
13Sep
.%
VS_UEStateTransSucc_FACH_CellDCH_CsCallSetup(U2808)(Event)
VS_UEStateTransSucc_PCH_CellDCH_CSsetup(estimation:#982#2948#2826)
StateTransitionSuccessRateFachToDch_ST005_CR(UST005_CR)(%)
StateTransitionSuccessRateFachToDch_ST005_CR(CScallsetup)
The global DT which increase in KC09 we can observe that the success rate decreases mainly after
Ua813 due to known AR 1-4036297
The global success rate however remains the same, we can even observe a small increase with more
triggering, but over all value is around 98.89%
108
Performance assessment : State transition : CS Setup over FACH
A1TA
The split of CS call setup from URA is also increase proportionally to the usage of URA
The success rate of ST005 referred to CS setup over FACH is also affected by the extra cac failure
referred before affecting the EDCH Upsize configuration.
109
Performance assessment : Cell updates & URA_Update
At&t
The Cell Update components have mainly 4 changes all related with more Ura usage and FD impact:
UlDataTx which is a direct consequence of more URA PCH users
UL Paging response due to more Ues in URA which will answer to paging
Cell reselection is reducing mainly after Ao ReleaseONly parameter modification, this cause is mainly
correlated with FACH usage
Re-entered service Area is decreasing, but not entirely correlated with URA, it is more related with
FACH usage
KC9
EDCH
FD2
Uon
FD1
6000000
FD3
AO_R_HS;DT@128
FD4 I/0
PagingRep
FD3off
1
0.99
5000000
0.98
0.97
4000000
0.96
3000000
0.95
0.94
2000000
0.93
0.92
1000000
0.91
0
15Jun
17Jun
19Jun
21Jun
23Jun
25Jun
27Jun
29Jun
1Jul
3Jul
5Jul
7Jul
9Jul
11Jul
13Jul
15Jul
17Jul
19Jul
21Jul
23Jul
25Jul
27Jul
29Jul
31Jul
2Aug
4Aug
6Aug
8Aug
10Aug
12Aug
14Aug
16Aug
18Aug
20Aug
22Aug
24Aug
26Aug
28Aug
30Aug
1Sep
3Sep
5Sep
7Sep
9Sep
11Sep
13Sep
0.9
VS_NbrCellUpdates_CellReselection(U901_0)(Event)
VS_NbrCellUpdates_PagingResponse(U901_3)(Event)
110
VS_NbrCellUpdates_UplinkDataTransmission(U901_2)(Event)
CellUpdateSuccessRate_RL019_CR
Performance assessment : Cell updates & URA_Update

The Cell Update components have mainly 4 changes:
UlDataTx which is a direct consequence of more URA PCH users
UL Paging response due to more Ues in URA which will answer to paging
Re-entered service Area is changing but not entirely correlated with URA (not displayed below)
The remaining Cell updates causes shifts are a consequence of Higher amount of CellFach usage.
111
A1TA
Performance assessment UTRAN Paging impact of URAid

When multi_URA configured, paging
volume decrease by 30%, paging cancel
and delay records decrease. Success rate
doesnt degrade. (trial on KC3)
112
At&t
Performance assessment : TMU & RAB memory

The Values were calculated at BH
and consider that:
14 & 17 Sept No FD
18 Sept FD2
21 Sept FD3
The TMU Memory show a very well
defined profile as a function of FD
and EFD but it is producing very
small changes (on the hour with
highest memory usage, we can
observe a 1 to 2 % of memory
increase with FD or EFD,
respectively
The Impact on Memory usage of
Rab is a little bit higher and can go
up to 4 to 6% depending on FD or
EFD
The values presented are rough
estimations and are not normalized
113
A1TA
Performance assessment : MRAB

The MRAB from CS point of view
increases to ~54%
60.%
The PS MRAB point of view is also

increasing from 12% to 15%
40.%
FD3
FD4 I/0
PagingRep
AO_R_HS;DT@128
35.%
30.%
25.%
20.%
30.%
15.%
20.%
10.%
10.%
5.%
.%
RatioOfMultiRABCSPStoTotalCSTraffic_RL059_CR(URL059_CR)(%)
Uon
KC9
EDCH
FD1FD2
13Sep
10Sep
7Sep
4Sep
1Sep
29Aug
26Aug
23Aug
20Aug
17Aug
14Aug
11Aug
8Aug
5Aug
2Aug
30Jul
27Jul
24Jul
21Jul
18Jul
15Jul
12Jul
9Jul
6Jul
3Jul
30Jun
27Jun
24Jun
21Jun
18Jun
.%
RatioOfMultiRABCSPStoTotalPSTraffic_RL058_CR(URL058_CR)(%)
FD4 I/0
PagingRep
FD3 FD3off
AO_R_HS;DT@128
300000
1200
13Sep
10Sep
7Sep
4Sep
29
26
23
20
0
1Sep
VS_RABEstabPSWithCSPresent(U2707)(Event)
17
14
11
8Aug
VS_RABEstabCSWithPSPresent(U2706)(Event)
5Aug

2Aug
114
30Jun
27Jun
24Jun
21Jun
30Jul
200
27Jul
50000
24Jul
400
21Jul
100000
18Jul
600
15Jul
150000
12Jul
800
9Jul
200000
6Jul
1000
3Jul
250000
18Jun
The Non regression will address in

detail this point
FD3off
KC9
EDCH
FD2
FD1
50.%
15Jun
The Mrab CS drops increase a small

amount when FastDormancy is
enabled alone;
Uon
15Jun
expected behavior
At&t
VS_RABRelCSWithPSPresent(U2708)(Event)
Performance assessment : MRAB
A1TA
The Mrab CS drops increase after

FD is activated and increase a little
bit further after EFD (typically we
go from a situation of 200 drops to
240 drops with FD or even ~260
with EFD
This is a consequence of much
more CS Rabs established over PS
sessions
This behavior is expected and did
not produce any degradation
attributed to FastDormancy
115
Performance assessment : PS00 upsize

250000
Uon
KC9
FD3off
EDCH
FD3
FD4 I/0
At&t
PagingRep
100.0%
AO_R_HS;DT@128
FD1
200000
99.80%
FD2
150000
99.60%
100000
99.40%
50000
99.20%
99.0%
15Jun
17Jun
19Jun
21Jun
23Jun
25Jun
27Jun
29Jun
1Jul
3Jul
5Jul
7Jul
9Jul
11Jul
13Jul
15Jul
17Jul
19Jul
21Jul
23Jul
25Jul
27Jul
29Jul
31Jul
2Aug
4Aug
6Aug
8Aug
10Aug
12Aug
14Aug
16Aug
18Aug
20Aug
22Aug
24Aug
26Aug
28Aug
30Aug
1Sep
3Sep
5Sep
7Sep
9Sep
11Sep
13Sep
RBReconfigDataActivity_RB033_C_0kbpsToDchHsdsch(URB033_C_0kbpsToDchHsdsch)(Event)
RBReconfigDataActivity_RB033_C_0kbpsToEdchHsdsch(URB033_C_0kbpsEdchHsdsch)(Event)
RBReconfigDataActivity0kbps_URB038_C_0kbpsToDchHsdsch(URB038_C_0kbpsToDchHsdsch)(%)
RBReconfigDataActivity0kbps_URB038_C_0kbpsToEdchHsdsch(URB038_C_0kbpsToEdchHsdsch)(%)
On the PS00 we have more reconfigurations to HSDPA/R99 since the ues CS+EDCH is not active
At the activation of all features, also CS+EDCH is enabled and the reconfs from CS+PS00 towards CS+EDCH
increase
116
Performance assessment : PS00 upsize
A1TA
On the PS00 we have more reconfigurations to EDCH since the ues HSDPA are still not addressed on current UEVersionForSCRI of FD
The small degradation observed on the success rate of Cs+PS00 uspize is correlated with FD as the volume of Uspizes of EDCH is also
larger. Also there is an impact on the success rate depending on the activation of the Feature EDCH retain ability (PM125855).
However the success rate of this upsize transition is already presenting a very good performance better than 99.95%
It is also important to mention that not all of these failures will produce a call drop
117
Performance assessment : TMU Load

The calculation shows
that the Capacity Gain
of URA_PCH/FD/DT
feature (with
R6_R7_R8 setting of
ueVersion) was
~+19.3% as
compared with
UA07.1.3 (URA_PCH
OFF) and ~26.4% as
compared with
UA08.1 (URA_PCH
OFF).
(from Ching-Roung
Chou)
118
Performance assessment : non regression: CS call drop

350000
DT .pc
fd1 2
fd3 & off

Pr
Break
GQ07
F2.1F2.2F2.3
F2.4F3 F4F3offF5
F6
EP2
A1TA
0.25%
300000
0.20%
250000
0.15%
200000
150000
0.10%
100000
0.05%
50000
0
6Aug
7Aug
8Aug
9Aug
10Aug
11Aug
12Aug
13Aug
14Aug
15Aug
16Aug
17Aug
18Aug
19Aug
20Aug
21Aug
22Aug
10Sep
11Sep
12Sep
13Sep
14Sep
15Sep
16Sep
17Sep
18Sep
19Sep
20Sep
21Sep
22Sep
23Sep
24Sep
25Sep
26Sep
27Sep
28Sep
29Sep
30Sep
1Oct
2Oct
3Oct
4Oct
5Oct
6Oct
0.00%
RABAssignmentSuccessPerGrantedRABType_RAB022_R_Cs(URAB022_R_Cs)(Event)
_CallDropRate_IU007_R_Cs_Computed(UIU007_R_Cs_Computed)(%)
The global CDR was slightly higher on GQ07 RNC, the increase was around 0.006% for all RNC except 9 sites which were removed due to
a specific degradation identified.
The Node Bs excluded; G552; Gi01; G895 G75A; G700; G66B; G44A; G390; G915 had mainly problems of:
UL High RSSI: Gi01; G895
PS drops UL RLC SRB ERROR : G552
Leaks for EDCH & HSDPA codes / users: G75A G700 G66B G44A G390 G915
On the last activation on only FD there was no regression of CS CDR which remains stable
119
Performance assessment : non regression: CS call drop
The KPI 11 remains stable after several steps of FD activation
120
At&t
A1TA
In line with the previous chart we can observe here the main changes on drop contribution by detailing the components of
IuAbnormlaReleaseRequest of PS domain.
Main changes are
DLASCnfOther (PS00): however this component does not affect our users as no UP exist.
DLASCnfTRbFach: have a significant increase of drops, but quite less on last activation (only FD)
DLASCnfxPCH: this component is also not included as it is drops on PCH state
So our main increase on drop is related with more fach drops, however we already saw before that the FACH usage also increase
121
A1TA
Looking on the drops per hour we can see that the main shift happening with EFD is the drops Per Hour on FACH.
The PS00 components have an increase with FD as well and this will be correlated with the usage of more HHO in case of
CS+PS00 (explained below)
The HSDPA drop per Erlang (only valid after EP2 where the counters 1666 were fixed) remains stable without EFD
The FACH drop is also correlated with any change on FD or EFD
122
Performance assessment : non regression: KPI35_CS
At&t
The impact produced on RRC was considered as not user impacting but just a consequence of a different
failure distribution, ATT porpose to use different set of formulas to take that into account
RAB Success = RAB Succ / RAB Atts
SRB Retain = RAB Atts / (RAB Atts + (SRB Failure Rate * RRC Assigns))
RRC Success = (RAB Atts + (SRB Failure Rate * RRC Assigns)) / (RAB Atts + (SRB Failure Rate * RRC
Assigns) + RRC Fails)
Total Accessibility = RAB Succ / (RAB Atts + (SRB Failure Rate * RRC Assigns) + RRC Fails)
1
Uon
KC09
EDCH
FD1
FD2
AO_R_HS;DT@128
FD4 I/0
PagingRep
FD3
FD3off
0.998
0.996
0.994
0.992
15Jun
17Jun
19Jun
21Jun
23Jun
25Jun
27Jun
29Jun
1Jul
3Jul
5Jul
7Jul
9Jul
11Jul
13Jul
15Jul
17Jul
19Jul
21Jul
23Jul
25Jul
27Jul
29Jul
31Jul
2Aug
4Aug
6Aug
8Aug
10Aug
12Aug
14Aug
16Aug
18Aug
20Aug
22Aug
24Aug
26Aug
28Aug
30Aug
1Sep
3Sep
5Sep
7Sep
9Sep
11Sep
13Sep
0.99
123

KPI35 CS
KPI35csUA8RRCModified
The SMC seems affected by EFD and in some days of FD. However when looking on a longer time
scale there is no major impact attributed to FD settings. The total avg periods show a global
impact of less than 0.01%
There is one day of severe degradation on this indicator due to global problems on network at
1Am
124
A1TA

The RRC success rate is increasing
after FD and remains high
In August the RRC003 and RRC021
improve a lot while RRC013 is not
moving bug PS conversational ;
WA was to deactivate the redirection
3g2g.
The main difference between
RRC021 and RRC013 are the
repetitions in case of cell reselection
across different TMUs
The RRC003 will give the point of
view of success rate for all
repetitions and will be interesting to
be evaluated in case of PS while for
CS it is not showing an important
degradation (~0.01% or even
equivalent noticed on last days)
The RRC021 keeps almost the same
level where we could acknowledge
0.01% degradation
125
A1TA

The CS call setup is distribution show the amount of cs call starting from the different
States. Idle is still the main state of cs voice call setup while URAPCH will increase from
12% to 22% with FD+ EFD enabled. The CS setups on FACH will gain a few setups to
the calls established over cell DCH once FD+EFD is active
126
A1TA
A1TA
The first chart on this slide refer to the signaling stage of the call establishment from the state PMM
idle.
It show a small degradation observed during the ExtendFD but not fully correlated as there were a few
sites with specific problems
Not reproduced after last activation
127
A1TA
The SMC SR for PS seems to be affected even if the impact is very small (0.02%)
The main impact observed is on the success rate during the Extended FD. The remaining period where simply FD is on going,
there is no obvious degradations specially when observing SRB retainability on the cluster without the high runner NBs.
The main culprit NODe Bs are G895 and G552
The degradation is not related with FD as it remains even on periods with FD off observed to be recovered after EP3
128


08 UA8.1 DR5 KTS 97425 Fast Dormancy PDF

Uploaded by

Document Information

Original Description:

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

08 UA8.1 DR5 KTS 97425 Fast Dormancy PDF

Uploaded by

Copyright:

Available Formats

PM97425 - Fast Dormancy for Smartphone battery saving

TIS-FOA-NEA (AVargas & EYang)

COPYRIGHT 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

PART B - Performance evaluation on FFA/FOA (US/GM)

Part C Conclusions and recommendation for activation

Feature Overview the present

Feature Overview Proposed Solution

A Sum up of features: Principles and Use Cases of Fast Dormancy

If start conditions are not met

RRC SIGNALLING CONNECTION RELEASE INDICATION

Case B: Initiate an RRC state

Case A1: Release the

Case D1: Initiate an RRC state transition

Extended fast dormancy

Case A2: Release the

A Sum up of features: Principles and Use Cases of Fast Dormancy

The following schematic procedure applies:

Fast Dormancy & AO are enabled & UE sending 3GPP NOT R8

If start conditions are not met

RRC SIGNALLING CONNECTION RELEASE INDICATION

Extended fast dormancy

Case A3: Release the

Case D2: Initiate an RRC state transition

Fast Dormancy Allowed Transitions

With Fast Dormancy + Extended Fast Dormancy

+ Cell/URA_PCH, the transitions to Idle are not possible

Fast Dormancy Applicability

The following combinations are not allowed for Fast Dormancy:

Timer T323 must be present in SIB#1

Purpose of the feature and benefits

If all SCRI are sent to xx_PCH then PS RAB establishment is 10 x lower!!!

Purpose of the feature and benefits

Benefits {& Cost} of Fast Dormancy (+URAPCH)

Key operator benefits:

Feature Interaction 1/2

UA5 PM26673 URA_PCH and PM26675 - Cell_PCH

PM29400 Enhanced RRM for High Quality Streaming:

Feature Interaction 2/2

UA8.0 PM108389 - Cell_PCH/URA_PCH direct transition to DCH:

Feature Activation strategy: Fast Dormancy

UeversionForSCRI = R7_R8 Filter all older than 3gppR7 Ues

Same setting as Step1 except for parameter UeversionForSCRI = R6_R7_R8

Same setting as Step2 except for parameter isExtendedFastDormancyAllowed = False True

Same setting as Step3 except for parameter UeversionForSCRI = Pre_R8

Configuration, Parameters and RAN Model

Feature Activation strategy: AT&T

- 25th of June: URA on base on UA811EP3

- FD1 18th of July: Activation of Features with lower triggering isFastDormancyAllowed=True

8th of Aug: RadioAccessService.AlwaysOnConf.AoFachParam.repThreshold = 128->256

- 13th of Aug: All feature on

Feature Activation strategy: A1TA

- FD1 13th of August :Activation of Features with lower triggering isFastDormancyAllowed=True

Phase2 activation : September/October (Ua08.1.3 Ep2/Ep3)

- 19th of Sept Improve of State transition from DCH to PCH IubEdchDelayVariation = 5 to 3

- FDOff 26th of Sept: Deactivation of EFD and decreasing

Sum Up of Fast Dormancy Benefits {& Cost} of Fast Dormancy (1/3)

Expressed as a PS time to first byte

Decreased from approximately 1.5s to 0.9s ~70% of users

URA usage should reduce battery usage

Not measured during trial

Reduction of 17% to 21% combined URA+ FD2 vs 7.1.3 URA off

9370 level paging volume