Fast Dormancy and Enhanced Cell FACH V1 - OLN

Fast Dormancy activation
and associated impacts
F. Tra, V. Diascorn, S. Bechet

OLN/RNM/REP/RCT
march 2014
FT Orange Company Confidential
Page 1
First Fast Dormancy (FD) trial has been performed in OSP network in 2012
with recommendation to activate FD for capable UEs
Since then, other trials have been performed in different affiliates (OJO,
OSP, OFR) with different RAN vendors
These trials provide some performance trends but also they raise some issues.
This document aims to sum up the results obtained so far and provide
general recommendation regarding FD activation in RAN solutions and its
associated impact
Page 2
Agenda
Overview: Fast Dormancy and PCH states
PCH, a RRC connected state to use with Fast Dormancy

Fast Dormancy features description
Main topics to tackle with PCH states introduction

Main topics to tackle with Network Control Fast Dormancy introduction
General recommendations for Network Control Fast Dormancy activation
Focus on Enhanced Cell FACH feature
Annexes
Page 3
PCH, a RRC connected state that can be used as the

new Idle State for PS connections
2 PCH states are defined: URA_PCH and C ell_PCH
In PCH state, the RAB in PS-Core is kept while the radio bearer towards RAN is released
keeping IU signaling Connections and PDP Contexts without using any Radio Resource
UEs are move to an active state faster leading to better end user experience and less latency
It is a RRC state between Cell_FACH and Idle States
Cell_FACH
Transition to PCH is ordered by the UTRAN on timer

expiry on Cell_FACH
Transition from PCH to Idle is ordered by the UTRAN
on timer expiry on URA_PCH
Transition from PCH to cell_FACH is driven by either
DL or UL request for activity (buffer filling up to
threshold)
if in DL, then UTRAN sends a paging request

if in UL, then UEs initiate a Cell Update procedure
In state URA_PCH, UEs are known at

UTRAN Registration Area (URA) level
UEs paging messages are then
broadcasted in whole URA
UEs initiate URA updating periodically and
on URA change
No dedicated
bearer
Inactivity in
UL & DL for y
seconds
Buffer filling up
to threshold
PCH
No bearer for
transmission
Inactivity in
UL & DL for z
seconds
IDLE
No RRC
connection
In state cell_PCH, UEs are known at Cell

level
UEs paging messages are then broadcasted
in only one cell
UEs initiate cell updating periodically and on
cell change
Page 4
What is Fast dormancy?

When the smartphones came, some vendors implemented
UE Proprietary Fast Dormancy
The aim of this capability is to save UE battery so the mobile is

switched to idle (transitions 10a and 10b )after few seconds of
finishing the data transfer.
It is controlled by the UE (not by the network)
This will cause increasing the signaling load , as the UE will
start connection to the network from idle state
This will also cause high latency .
Fast Dormancy was standardized in 3GPP Release 8.
It resulted in the network and the UE sharing control of fast

dormancy transitions
Referred as Network Control Fast Dormancy (NCFD)
UEs performing Release 8 Fast Dormancy , will be down

switched to URA state instead of releasing the connection
(transitions 12 and 13 ).
Page 5
Fast Dormancy introduction leads to an enhancement of

dimensioning KPIs whatever the RAN vendor
OJO with E/// RAN
OSP with Huawei RAN
45 % reduction of
RRC connection setup

& PS RAB Attempts
16% reduction of
IU_PS signaling
attempt (RANAP)
8% reduction of RNC
load
16% decrease of CE
consumption
OFR with ALU RAN
(URA_PCH)
(Cell_PCH,15% of NCFD UEs)
80 % reduction of
RRC connection setup

& PS RAB Attempts
72 % reduction of
IU_PS signaling
attempt (RANAP)
15 % reduction of
RNC load
70 % decrease on PS
Paging type 1
attempts
(URA_PCH) - estimations*
70 % reduction of
RRC connection
setup & PS RAB
Attempts
20 % reduction of
RNC load
Fast Dormancy benefits can vary from a network to another one due to
device population,
parameters settings (state transition timers),
network configuration (network already using Cell_PCH or URA_PCH)
In all trials run so far, Fast Dormancy enables to reduce signaling (RRC and PS RAB
attempts), RNC load and CE consumption
*
In OFR, only URA_PCH tested. FD performance are extrapolated.
Page 6
Agenda
Procedure collision with paging Type 1 signaling procedure

Potential FACH congestion
CSSR and CS setup latency degradation
Multi RAB handling becomes a generality
Adaptation of Mobility and service steering mechanisms
Adaptation of KPI monitoring

General recommendations with Network Control Fast Dormancy activation
Annexes
Page 7
Topics to tackle with PCH state introduction

Procedure collision in PCH state and paging type 1
PCH state can be used without Fast Dormancy but NCFD cannot be used
without PCH
NCFD will then increase the usage of this state
Experiments have shown that some procedure collisions may happen between
location update and RAB establishment leading to some failures
In Cell_PCH, location update procedure occurs whenever a change of cell is
experienced by the user, namely Cell update
In URA_PCH, location update procedure occurs at URA change, namely URA update
Since URA consists of one or several cells, URA update is then less frequent than
Cell update
Since concurrent cell updates and RAB setup can lead to some procedure failures, the
recommendation is to favor URA_PCH state to reduce the number of cell update
Since in URA_PCH, SMS are sent thanks to Paging type 1 message, there will
be an increase of this message;
To reduce this impact, a redesign (size reduction) of URA can be necessary

Page 8

Transition PCH to FACH leading to FACH congestion (1/2)
With the usage of URA_PCH, UEs first step up to Cell_FACH prior to any
interaction with the network.
This transition is actually done using FACH and RACH messages to proceed
either to traffic resuming, new service establishment or sending signaling
messages
In case of DL PS activity, UTRAN sends a paging type 1 message and UEs
respond by a Cell Update cause Paging Response
In case of UL activity, UEs send a Cell Update message with cause UL Data
transmission
In case of inactivity after a given timer, UEs transition to Idle state is actually done
through cell_FACH to proceed to RRCConnectionRelease
All those transitions to Cell_FACH state lead to an increase of the FACH

channel usage and lead to a high number of UEs on Cell_FACH state
FACH is a common channel with only 32 kbps capacity
FACH channel can then be a bottleneck for the network performance
Page 9

Transition PCH to FACH leading to FACH congestion (2/2)
Means to tackle this potential FACH congestion lie in one of the followings
Means
Free camping
Description
Cons
It consists in allowing camping

on all 3G frequencies with no
particular offset to discriminate
the carriers;
- Reselection in URA_PCH is the

same as in Idle
- Steering of FACH congestion
among all carriers
- only parameters tuning
- can breach some affiliates

current camping policy and
consequently load balancing
strategy
SCCPCH is a common channel

used to carry FACH and PCH
messages
- double FACH capacity
- Increase the power devoted

to common channels,
- hence reduce dedicated
traffic power, notably HSDPA
capacity
Signaling and data in

Cell_FACH state carried with
HSPA speed
- increase data rate in Cell_FACH

state
- Decrease the latency in RRC state
switching
- Induce an increase of
HSDCH traffic load
- Reduce radio capacity
- not all UEs compatible
Bypass Cell_FACH to directly

move to Cell_DCH
- avoid FACH channels and its low

capacity
- Decrease the latency in RRC
state switching
- coming in most of RAN

vendors next release
- not yet validated (T6)
Parameter Tuning
Activation of a secondary
SCCPCH
Pros
Parameter Tuning
Activation of HS-FACH
(enhanced FACH) in DL
New feature to deploy
Direct upswitch from
URA_PCH to DCH
New feature to deploy
At short/middle term FACH congestion is another argument to go for Free camping strategy
At middle term, direct upswitch is the most promising solution to be tested to solve FACH congestion
HS-FACH in DL is not recommended to be activated alone; It has to be activated alongside with its UL
version in addition to other features like SRBoHSPA and F-DPCH
Page 10

Transition PCH to FACH leading to CSSR and CS setup
latency
degradation
With the usage of URA_PCH, UEs first step up to Cell_FACH prior to any
interaction with the network.
FACH is a common channel with no fast power control
It is a less robust channel compared to DCH channels leading to decrease the
call set up success rate
This systematic two-step transition from URA_PCH to Cell_DCH increases the
latency for CS services compared to Idle mode
It also decreases the CSSR for both CS and PS services since the overall
procedure will be driven by the transition efficiency between URA_PCH and
Cell_FACH
To counteract these drawbacks, all RAN vendors already plan some

direct upswicth transition from URA_PCH towards Cell_DCH
ALU : Enhanced Direct Transition (SRB 13.6) in LR13.1
Ericsson: Faster Establishment, Direct Upswitch from URA (FAJ 121 1496 in
W12B)
Huawei : Smart Cell_PCH to Cell_DCH (RAN 14)
Combined with the issue of FACH congestion, direct upswitch transition could be a
promising middle term solution to solve this CSSR and CS latency degradation
Page 11

Multi RAB handling (1/2)
NCFD, due to URA_PCH usage, leads to keep the UEs connected in the PS core
network
Therefore any CS call establishment is made with the establishment in parallel of the PS
bearer, leading to CS + PS(0/0) RAB
The rate of multi RAB CS+PS is highly increased
This Multi RAB CS + PS performance is worse than CS only, due to

Lower robustness during handover phases
Lower robustness in bad radio conditions when a PS data session is ongoing
Channel switching reconfigurations leading to potential RAB reconfiguration failures and
Voice session drops
More signaling in multi RAB (larger number of RRC reconfiguration procedures triggered by
PS calls PS RAB setup/release, serving cell change with HSxPA, rate reconfiguration with
R99 PS)
Multi RAB performance problematic is not introduced by URA_PCH state introduction

but its impact on global performance is emphasized when URA_PCH state is ON
Page 12

Multi RAB handling (2/2)
Several proposal made by RAN vendors (in annex) to cope with this issue.
Based on trial feedback, two main solutions are promoted now:
Channel switching tuning
either reduce as much as possible channel switching events through timers
or reduce the number of Multi RAB combinations
Ensure the speech retainability in bad radio conditions

either by reconfiguring the PS from 2ms TTI to 10 ms TTI for HSUPA users
or by releasing the PS RAB without evoking the CS call release
These solutions indeed improve the performance of Multi RAB but the fundamental issue
is only masked. A feature development is required to improve the handling of MultiRAB
and its drop rate. Some solutions vendors specific solutions are proposed
Page 13

Mobility and service steering mechanisms
Some vendors load balancing and traffic steering mechanisms could not be
applied in URA_PCH since
Most of the load balancing procedures rely on RRC procedures (from Idle state)
From URA_PCH, no RRC phase is performed (RRC context is already kept)
Consequently, it happens that

ALU IMCRA cannot be applied from URA_PCH to steer traffic among layers
IMCTA applies instead since URA_PCH is a connected state
The capability to put Dual Carriers (DC) capable users on DC-carriers will therefore be
lost. It is required then to apply the enhanced IMCTA (UA08) to keep this possibility.
Ericsson IFLS cannot be applied from URA_PCH

but HS-IFLS and Non-HS-IFLS can be applied
Huawei DRD (either RAB DRD or RRC DRD) cannot be applied from URA_PCH
but LDR could be applied
Load balancing and traffic steering policy shall be reviewed with the introduction of
URA_PCH and fast Dormancy features
Page 14

KPI monitoring evolution
All vendors require some modification in KPI computation to take into
account the introduction of URA_PCH
In fact most of the counters consider a call departure mainly from Idle mode.
with URA_PCH introduction, most of the calls will start from PCH state which acts then
as the new Idle Mode
CSSR computation cannot be separated for calls starting in Idle vs calls started in
PCH state (PCH efficiency cannot therefore be deduced)
Ericsson plans a solution in W13A (Feature Multi RAB observability (W13A)

ALU also plans some development but no clear roadmap
It is highly recommended to update KPI formulas to cope with this newly introduced
URA_PCH state
Page 15
Agenda
Management of legacy UEs
Deal with some IOT issues on R8 devices
Impact on signaling capacity at PS Core network level

Annexes
Page 16
Topics to tackle with NCFD introduction

Non NCFD capable UEs
NCFD is a release 8 feature
Prerelease 8 devices cannot therefore be handled with this feature
either they will use the proprietary fast dormancy if capable to directly switch from
Connected mode to Idle leading to an increase of signaling
Or switch to FACH/PCH states based on radio inactivity timers
The benefit of NCFD could potentially be less noticeable if the proportion of these
prerelease 8 devices is high
To fully benefit from the NCFD, it shall be enable for all UEs.
Solution: build a database of candidate terminals based on IMEISV (TAC code
and SVN) and enable the transition towards URA_PCH from cell_DCH upon the
reception of SCRI without any cause
Features promoted by the suppliers as a solution
Huawei: activate parameter PROCESSSWITCH: FD_TAC_MATCH_SWITCH to enable
NCFD for all UEs whose version is rel.5 or later (RAN 15)
Ericsson: Fast Dormancy for pre-rel-8 UEs (FAJ 121 2425 ) coming with the feature
Differentiated UE Handling (FAJ 121 2267) (W13B)
ALU: extended fast dormancy + ueScriVersion (UA08.1)
Since the usage of NCFD on some legacy UEs might raised some IOT issues due to UEs
not respecting the RB reconfiguration as a response to the SCRI sent by UE, validation
tests shall be performed first. Final recommendation will be made based on validation
test performance and devices IOT tests results
Page 17

IOT with some Rel8 devices, supposed to be NCFD capable
It has been found both in a trial in M* with Huawei and OFR with Ericsson some IOT
issues with some devices after the direct DCH to PCH transition:
case 1: Some terminals send CELL_UPDATE message to transfer data immediately after a
state transition from DCH to PCH which increases signaling and leads to heavy load on the
air interface
case 2: When the UE is paged or it has some data in its buffer, it sends a Cell Update
message with this cause (Page response or UL data transmission) the baseband reboots
Solution promoted is to adopt a two step transition towards PCH by stepping first in
FACH state
1st step: UEs will be sent upon SCRI reception with cause PS Data Session end to FACH
state
2nd step: upon either the FACH inactivity timer or a reception of a second SCRI (after the
T323 timer expiration), UEs with be moved in URA_PCH
This solution can be applied for
Either identified terminals, if a database of concerned devices can be built (based on

IMEISV - TAC code and SVN)
Or applied for all devices by setting the FACH inactivity timer to a lower value and disabling
the direct DCH to PCH transition
The efficiency of such feature is related to both the capability to build such IMEISV
database and also in case of no IOT issues with devices.
Nevertheless an activation of this 2 steps transition for all devices could avoid the need of
IMEISV database
Page 18

Signaling capacity in PS Core network
NCFD, due to URA_PCH usage, leads to keep the RAB in PS Core Network
inducing
A higher number of simultaneous RAB in the PS core even without any actual ongoing traffic
The number of maximum SCCP connections on the SGSN shall be increased to
overcome the high number of parallel connected users: upgrade values will depend on the
affiliates capacity forecast and the number of capable NCFD devices
In direct tunnel networking (3GDT) mode, each RAB creation triggers a PDP
update procedure over the Gn interface inducing
Significant impacts on cards managing signaling in PSCN when 3G DT activated
The SGSN and GGSN then process the related signaling instead of SGSN alone in no
direct tunneling mode
NCFD by increasing duration of RABs is decreasing number of RABs creations

and decreasing signaling impacts on PSCN
In case of 3G Direct Tunnel used, the usage of NCFD should decrease the signaling on
the GGSN and SGSN
Page 19
Agenda
Annexes
Page 20
General recommendations for Fast

Dormancy activation
Recommendation 1: Not deploy PCH state alone
Most of the drawbacks described in this document are mainly related to the usage of
URA_PCH, and not Fast Dormancy itself (except the direct DCH to PCH transition
issue).
It is not recommended to deploy PCH state alone since the operator will face all the
issues and not take full benefit of fast dormancy with PCH state.
Recommendation 2: activate NCFD

NCFD brings high gain at each network level,
UE level: reduction of battery drain, PS session latency enhancement
RAN: signaling load reduction, RNC CPU reduction,
PSCN: paging reduction
it is recommended to activate NCFD for 3GPP rele8. fast Dormancy capable UEs
Recommendation 3: activate URA_PCH instead of Cell_PCH with NCFD

it is recommended to activate URA_PCH instead of Cell_PCH to reduce potential PD
failures due to cell update procedures failure
Page 21
Fast Dormancy activation strategy (1/2)

step 1: Activate NCFD only for capable devices
1. Activate the two step transition (DCH to FACH to PCH) to avoid some devices IOT
issues (for all UEs)
Reduce the FACH inactivity timer or T323 timer to speed up the transition to PCH from
FACH and avoids unnecessary FACH congestion
2. Follow up the FACH congestion KPI

For affiliates in Free camping strategy, the impact shall be less sensitive
For other affiliates (with dedicated camping strategy), if the FACH congestion is too high,
either go for Free camping (if admissible)
or activate the secondary SCCPCH to increase FACH capacity (with HSPA capacity reduction)
3. Follow up the Multi-RAB KPIs

If the related KPIs are degraded, apply
a reduction of Multi RAB (CS+PS R99) combination through channel switching tuning
and a protection of CS voice by easing the 2 ms TTI to 10ms TTI reconfiguration of PS
sessions
3. If the strategy above is not sufficient, apply an early release of PS session in bad radio
condition
Page 22
Fast Dormancy activation strategy (2/2)

step 2: Activate the direct upswitch transition (PCH to DCH)
and
potentially
NCFD
forit inallthetype
of devices
1.
Upon
validation ofactivate
this feature,
activate
network
in order to
Reduce FACH congestion,

It will help to reduce the CS latency and enhance the CSSR for CS voice
This could help affiliates with dedicated camping strategy, without need of secondary
SCCPCH
2. To increase the gain of NCFD, it could be interesting to enable it for all types
of UES. But at the condition to be able to build a database of IMEI-SV to
handle the non rel.8 capable devices
Page 23
Agenda
Annexes
Parameter setting recommendation for Fast Dormancy activation per supplier
List of NCFD compatible devices
Proposals from RAN suppliers on Multi RAB handling
Signaling during states transitions
Page 24
Enhanced CELL FACH enables to improve signaling

& save capacity over the network.
pros
throughput gain: uplink data rates increased from ~16

kbps to beyond 1 Mbps
reduction of RNC signalling load: common E-DCH

resources allocation is controlled by the NodeB (up to
32 common E-DCH resources per cell)
improvement of UL resource utilization: common EDCH resources are quickly released by the UE (saving
CE & dummy connections)
E-DCH
E-DCH
PRACH
PRACH
SCCPCH
SCCPCH
E-DPDCH
E-DPDCH
16kbps/20ms
32kbps/10ms
5.76Mbps/2ms
HS-DSCH
HS-DSCH
HSPDSCH
HSPDSCH
42Mbps/2ms
RACH de-congestion
more HSPA resources used (signalling over HSPA)

new terminals needed
link adaptation still not perfect: needs uplink
transmission (HS-DPCCH up)
no concurrent use of 2ms and 10ms TTI
Additional complexity for RAN optimisation: new
threshold to fine tuned
Cell_FACH
Cell_DCH
Transport
channels
FACH
FACH
RAC
RAC
H
H
seamless
Access coverage can be improved (better CSSR ?)
cons
Cell_DCH
Cell_FACH
E-DCH
E-DCH
HS-DSCH
HS-DSCH
Physical
channels
some delay
Transport
channels
Faster message exchanges: about 100/200 ms

improvement
Physical
channels
E-DPDCH
E-DPDCH
HS-PDSCH
HS-PDSCH
Up to 42Mbps / 2ms
Up to 5.76Mbps / 2ms
Page 25
Enhanced CELL FACH should improve capacity both at radio side (HSPA
usage) and at hardware side (lower UL CE despite signaling on HSPA)
Enhanced CELL FACH should improve capacity
CE usage
Some enhanced CELL FACH terminals effect that could benefit to legacy terminal
EFACH terminals will be less often in CELL DCH which free CE and HSPA connection to legacy devices
EFACH terminals should have better UL CE management (no more CE consumption due to SRB)
UL PS call
example
RACH transmission
CE usage
URA_PCH
CE Gain in cell DCH

More CE consumption
in signalling phase
minrate for
SRBoHSUPA
CELL_FACH
CELL_DCH
CELL_FACH
URA_PCH time
Additional CE for signaling : RACH over HSUPA
data
transmission
on
enhanced
RACH
(E-DCH)
URA_PCH
Throughput in cell
DCH is not limited
Throughput is limited in
cell FACH (2 Mbps max)
URA_PCH
CELL_FACH
time
inactivity
timer
Enhanced CELL FACH will not REPLACE data transfer in CELL DCH but will
complete it since its throughput is limited, it should be used for background traffic
Page 26
Vendors results seems to indicate that enhanced CELL FACH terminals

could have better Call Set Up Sucess rate than legacy terminals thanks to
better RACH coverage
Enhanced RACH uses improvements made in

release 6:
HARQ retransmission combining: higher

initial BLER is supported so smaller energy
is needed for first data transmission
fast scheduling with introduction of MAC-is

and MAC-i entity: fast reaction to data rate /
load (acknowledgments), adaptability to
interference variance
minimal gain
Results of these enhancements:
at same rate, eRACH brings better

coverage than RACH
at same coverage, eRACH brings better

rate than RACH
about 3dB better RACH coverage with enhanced CELL_FACH (DL +UL)
linked to configuration and trade off between performance (speed) and coverage
Page 27
Enhanced CELL FACH could be interesting in order to reduce

message contribution due to background traffic.
Terminal availability is at stake.
Enhanced CELL FACH should be deployed with both features DL and UL

TOGETHER
Enhanced CELL FACH DL in standalone is less well managed (much less efficient
link adaptation, no more CQI)
Area of actions should be limited to access procedure message & background

traffic (some kbytes)
CELL DCH should remain the main state for user experience
It is also recommended to map Signalling radio bearer on HSDPA and HSUPA
Once starting to map access message to HSPA, it look consistent to do it also for
the other RRC messages
Because SRB will no more benefit from macro-diversity in DL, it is also

recommended to boost HS-SCCH & HS-PDSCH power
However, the degree of efficiency of the feature will be linked to
Terminal penetration across affiliates

The % of time UE will be in 3G while 4G is also deployed in the same area
Page 28
NCFD is ready for deployment at the moment, Enhanced Cell

FACH is still pending
Devices availability or lack of affiliates interests
Network controlled Fast dormancy (+ PCH)
RU20
RAN13
W11B
UA8.1.5
(april)
RAN13
W11B
LR13.3
RAN13
W12B
LR14.2
RAN14
W12B
LR13.3
Enhanced CELL FACH DL
RU30
Enhanced CELL FACH UL
RU40
Direct Up-switch
RU40
Devices status
Fast Dormancy:
Activated in Terminal and available in most of group smartphones

Enhanced CELL FACH (DL+UL):
Not Activated (should be activated with both UL+DL) No T6 in RAN
Page 29
Smartphones features Advantage & Drawbacks in a nutshell

Fast Dormancy
Enhanced CELL FACH DL+UL
+ Less signaling for background traffic

+ Less signaling
+ Lower UL CE consumption
+ lower hardware load
+ Quicker mobility/transition procedure
+ Quicker mobility/transition procedure
+ Better Access Coverage
- FACH/PCH congestion increase
+ FACH Congestion decrease
- More multiRAB (risk on QoS CSSR especially) - More traffic on HSUPA/HSDPA due to signaling
Page 30
Agenda
Annexes
Parameter setting recommendation for Fast Dormancy activation per supplier
List of NCFD compatible devices
Proposals from RAN suppliers on Multi RAB handling
Signaling during states transitions
Page 31
Fast Dormancy parameters setting per supplier

Ericsson case
MO
Attribute
Value
ChannelSwitching=1
dlRlcBufUpswitchMrab
RncFeature=RabCombination0
09
featureState
MO
Parameter
Proposed Value
ChannelSwitching
InactivityTimer
20s
ChannelSwitching
InactivityTimerPch
SccpApLocal=ranapLocal
maxConn
Rrc
t323
29m
depends on
dimensioning outputs
5
RncFunction
Spare[8]
RncFunction
Spare[2]
RabHandling
state128_128Supported
1 (TRUE)
RncFeature=FastDormancyHan
dling
featureState
RncFeature=RabCombination0
21
FACH=1
featureState
maxFach2Power
40(4dB)
Rrc
t305
30 m
RAB PS 0/0
activation
2 steps transition
activation for all UEs
Page 32

Huawei case (RAN 14)
URA_PCH activation
BE FACH to PCH Transition timer : 10 s

PS Inactivity time= 1800 (30 min)
Fast Dormancy activation
SET LICENSE: SETOBJECT=UMTS, ISPRIMARYPLMN=YES,

FastDormancyEnhancement=******;
SET URRCTRLSWITCH: RsvdPara1=RSVDBIT1_BIT21-0;
SET URRCTRLSWITCH: PROCESSSWITCH=FAST_DORMANCY_SWITCH-1;
SET UPSINACTTIMER: PsInactTmrForFstDrmDch=5;
SET UPSINACTTIMER: PsInactTmrForFstDrmFach=7;
SET UPSINACTTIMER: PsInactTmrForPreFstDrm=1800;
SET UUESTATETRANS: FastDormancyF2DHTvmThd=D1024;
SET URRCTRLSWITCH: PROCESSSWITCH=FD_TAC_MATCH_SWITCH-1;
SET UCONNMODETIMER: T323=D30
Page 33

Huawei case (RAN 15)
NCFD activation for
non capable UEs
SCRI sending is
decided by UEs
Direct Upswitch
activation
State transition
timer reduction
These are the default values as recommended in Huawei RAN 15

It shall then be tested before full deployment.
Page 34

ALLU case (UA 08.1)
Parameter
value
isFastDormancyAllowed
True
(feature activation)
ueVersionForScri
R8
(R8 and later UE versions are applicable for Fast
Dormancy supporting 3GPP SCRI IE specification)
t323
T323_30
(30 s)
isExtendedFastDormancyAllowed
False
(NCFD not applicable for pre-rel8 devices)
isAlwaysOnAllowed
True
(to allow always ON state transition)
pchRrcStates
URA_PCH
uraPchToIdleTimer
32 min
(PS inactivity in PCH state)
In ALLU solution, the target state upon SCRI is only PCH state
The two step downswitching towards PCH cannot then be applied (Transition
Cell_DCH to Cell-FACH is not possible)
Page 35
NCFD Orange devices

Important notes and UE list sorted by manufacturer
Devices roadmap is sorted by alphabetical order of manufacturer
Datacards are not taken into account, handsets & tablets only
Orange DEVICES team has defined a list of dedicated requirements to fine tune Fast
Dormancy:
Fast Dormancy must be activated regardless of SCREEN state
Time to activate dormancy (assuming user inactivity) depends on screen state
and the user activity frequency (which is as well controlled by network via T323)
Windows Phone 8 devices were observed to rarely go dormant : issue is

currently under investigation with Microsoft due to OS implementation
additions. However, these devices were kept in roadmap since they have
the feature activated.
The complete list can be found in this attached document
NCFD orange
devices
Page 36
Suppliers proposal to deal with Multi RAB handling

ALU proposal
ALU planned features development
Feature 125855 : EDCH call retainability /R1: Force the Use of E-DCH 10 ms TTI
for CS+EDCH RAB Combination since 2ms TTI is more sensitive to poor radio
condition than 10 ms TTI
Rate adaptation limitation for CS+PS R99 RAB combinations : The reduction of
the signaling for multi RAB calls can also be achieved via reducing the number of
Rate Adaptation procedures, possibly by forbidding high rate (384k, 128k) in
multi-RAB configuration
Mitigate the UL load and the DL power usage by either
spreading the multi RAB among all carriers (if no traffic steering strategy defined)
or favoring the multi RAB on a more clean carrier (in case of a R99 dedicated carrier)
Reducing the drop probability of multi-RAB in case of bad radio quality by either
releasing the PS without invoking a CS call release or by blocking the PS
session establishment (feature 119418)
Page 37

Ericsson proposal
Ericsson planned features development
Have voice and HSDPA on all carriers, spreading hence the multi RAB among all
carriers
Disabling high rate DCH combinations with speech
Increased supervision timers (RAB establishment, RAB release)
Increased supervision timer for channel switching, i.e reduction of the probability
of channel switching
Increased hysteresis for HS cell change
Increased supervision time for HS cell change
Use of RRC Re-establishment features for CS and PS to enable the UE to
restore a call when it has lost the connection thanks to a proper tuning of T313,
T314, T315 timers
Speech retainability - during speech when radio conditions are degraded, limit
the PS session to be established, i.e Reduced signaling and transitions between
radio bearers
Page 38

NSN proposal
NSN planned features development
Activation Time Offset time parameter optimization. Shorter time reduces the
time to be used for reconfiguration procedures Probability for call drop reduces.
Use of RRC Re-establishment features for CS and PS. i.e. T314>0s and
T315>0s.
Parameter settings related to re-establishment: T313 tuning 8s->2s to shorten
the silent period in case of drop
Increase EbNoDCHOfSRB34 to improve Multi-RAB retainability performance.
Decrease reconfigurations due to NRT PS RAB inactivity by increasing inactivity
timers. The drawbacks are resource usage and capacity performance.
Enable both AMR+HSDPA and AMR+HSUPA features. If not enabled multiple
reconfigurations (HSPA to HSDPA or HSPA/HSDPA to DCH) are needed. This
will cause delays to soft handovers and call may drop.
Note: Some Limitation occurs with NSN. It is not possible to disable Multi-RAB
combinations. Only AMR+HSPA Multi-RAB can be configures in RNC,
otherwise RNC cannot restrict combinations
Page 39
PS session establishment procedure from Idle

For small and big data to transfer
extracted from Smartphone Solutions White Paper (from huawei Mlab)

Page 40
PS session establishment procedure from PCH

For big data to transfer (transition to DCH)

Page 41
PS session establishment procedure from PCH

For small data to transfer (no transition in DCH)

Page 42
Fast Dormancy (FD) as a solution to better handle state

transitions for smartphone devices
What is the past network behavior? (1/2)
The network cannot anticipate the data transfer characteristic of particular

applications
The network has no way to determine if a device has more data to transfer or not
The network has only a knowledge of activities at radio level
Even if the device is expecting no further data exchange in both DL and UL, it
has to wait the radio inactivity timer expiration before transiting to a lower UE
state
The device may then remains in a higher consuming state much longer than necessary
This induces a waste of radio resources if this inactivity timer is long and also a higher
device battery consumption
If the inactivity timer is too short, it can imply ping pong effects in state transitions and
generate too many signaling
Past network behavior was to make the states transition based on radio
inactivity timer
Downswitch transition was made based on radio inactivity timer of few seconds
Upswitch transition was made based on buffer filling up to a given amount
Page 43

What is the past network behavior? (2/2)
UE
UE in
DCH
Node B
RNC
SGSN
On going PS I/B service (Packet transfer in UL & DL)

Packet transfer inactivity in UL & DL detected
Inactivity timer expiry: T1
(DCH to FACH inactivity timer)
DCH to FACH
transition
RRC RB RECONFIGURATION
RRC RB RECONFIGURATION COMPLETE
RADIO LINK DELETION REQUEST
RADIO LINK DELETION RESPONSE
UE in
FACH
Inactivity timer expiry: T2

(FACH to Idle inactivity timer)
RANAP Iu-Release Command

RRC CONNECTION RELEASE
RRC CONNEC. RELEASE COMPLETE
Iu- Release
RANAP Iu-Release Request
RANAP Iu-Release Complete
UE in
IDLE
Page 44

Initial Device solution: Proprietary fast dormancy (1/2)
To counteract the potential longer period of time devices could remain in high
consuming state while no data is expected at application level, UEs vendors have
developed a proprietary fast dormancy
Proprietary fast dormancy is a device feature causing the transition from

Cell_DCH/Cell_FACH to Idle mode in case of inactivity of background services (keep alive,
presence status messages)
After a period of inactivity of few seconds (typically ~5s) at application level, UEs will send on their own a
RRC Signaling Connection Release Indication (SCRI) to the RNC without no specific cause
This results in an immediate session tear down
UEs transit then to Idle state
Proprietary Fast Dormancy is initiated by the UE
Advantages
it allows UE battery saving (UEs centric feature)
Drawbacks
not controlled by the network

FACH or PCH states are bypassed
increase of the amount of signaling on RNC side because of multiple RRC connections/
disconnections increase of RNC load
increase of the latency since connection will be restarted from Idle
The root cause of the transition is not known at network level (it is however not counted as call
drop)
Page 45

Initial Device solution: Proprietary fast dormancy (2/2)
UE
Node B
UE in
DCH
RNC
SGSN

Packet transfer inactivity in UL & DL detected (radio level)
UE detects PS inactivity
(application level)
RRC SIGNALING CONNECTION RELEASE INDICATION

(no SCRI cause)
RANAP Iu-Release Command

RRC CONNECTION RELEASE
RRC CONNEC. RELEASE COMPLETE
Iu- Release
RANAP Iu-Release Request
RANAP Iu-Release Complete

UE in
IDLE
Page 46

Network solution: Network Control Fast Dormancy (1/3)
In Release 8 specifications, network can control the state transition when

requested by the UE, namely Network control fast dormancy (NCFD) or
Fast dormancy release 8
UEs are not allowed to release RRC connection and move to Idle state on their
own without the control of the network
Transition is initiated by the UE after a period of inactivity at application level
by sending a RRC:SCRI to the RNC with a newly introduced cause= PS Data
Session End
upon reception, the RNC commands the transition into FACH or PCH instead of
idle mode No interest without PCH state
Advantages
Drawbacks
Reduction of amount of signaling

Reduction of load on RNC
state transition controlled by the network
supported by all recent smartphones
It requires mutual supports and cooperation from chip

suppliers, terminal providers, and wireless networks
No impact on device not implementing this feature
The benefit will be visible only for a large number of
compatible devices
Page 47

NCFD, even controlled by the network, is always initiated by the devices

since
The network cannot anticipate the data transfer characteristic of particular

applications and determine if a device has more data to transfer or not
The network has only a knowledge of activities at radio level
The NCFD capability of a network is noticed to devices thanks to the

broadcast of a specific timer, T323, in SIB1 message
It is included in IE UE Timers and Constants in connected mode

T323 is a waiting time between 2 consecutive RRC:SCRI message
The UE shall not send a SCRI message while T323 is running or while in Cell_PCH or
URA_PCH state
While this timer running the UE 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.
Page 48

UE
Node B
RNC
SGSN
UE in
DCH
Packet transfer inactivity in UL & DL detected

UE detects PS inactivity
and T323 not running
RRC SIGNALING CONNECTION RELEASE INDICATION
(SCRI CAUSE = PS DATA Session END)
UE starts T323
RADIO BEARER RECONFIGURATION
DCH to URA_PCH
transition
(URA_PCH state)
URA update
URA Update Confirm
RADIO BEARER RECONFIGURATION COMPLETE

UE in
URA_PCH
Page 49

Fast Dormancy and Enhanced Cell FACH V1 - OLN

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Fast Dormancy and Enhanced Cell FACH V1 - OLN

Enviado por

Direitos autorais:

Formatos disponíveis

Fast Dormancy activation

and associated impacts

F. Tra, V. Diascorn, S. Bechet

FT Orange Company Confidential

FT Orange Company Confidential

PCH, a RRC connected state to use with Fast Dormancy

Main topics to tackle with PCH states introduction

FT Orange Company Confidential

PCH, a RRC connected state that can be used as the

It is a RRC state between Cell_FACH and Idle States

Transition to PCH is ordered by the UTRAN on timer

if in DL, then UTRAN sends a paging request

In state URA_PCH, UEs are known at

In state cell_PCH, UEs are known at Cell

What is Fast dormancy?

The aim of this capability is to save UE battery so the mobile is

Fast Dormancy was standardized in 3GPP Release 8.

It resulted in the network and the UE sharing control of fast

Referred as Network Control Fast Dormancy (NCFD)

UEs performing Release 8 Fast Dormancy , will be down

FT Orange Company Confidential

Fast Dormancy introduction leads to an enhancement of

OSP with Huawei RAN

RRC connection setup

OFR with ALU RAN

(Cell_PCH,15% of NCFD UEs)

RRC connection setup

In OFR, only URA_PCH tested. FD performance are extrapolated.

FT Orange Company Confidential

Procedure collision with paging Type 1 signaling procedure

Main topics to tackle with Network Control Fast Dormancy introduction

FT Orange Company Confidential

Topics to tackle with PCH state introduction

To reduce this impact, a redesign (size reduction) of URA can be necessary

Topics to tackle with PCH state introduction

All those transitions to Cell_FACH state lead to an increase of the FACH

FT Orange Company Confidential

Topics to tackle with PCH state introduction

It consists in allowing camping

- Reselection in URA_PCH is the

- can breach some affiliates

SCCPCH is a common channel

- double FACH capacity

- Increase the power devoted

Signaling and data in

- increase data rate in Cell_FACH

Bypass Cell_FACH to directly

- avoid FACH channels and its low

- coming in most of RAN

Topics to tackle with PCH state introduction

To counteract these drawbacks, all RAN vendors already plan some

Topics to tackle with PCH state introduction

This Multi RAB CS + PS performance is worse than CS only, due to

Multi RAB performance problematic is not introduced by URA_PCH state introduction

FT Orange Company Confidential

Topics to tackle with PCH state introduction

Ensure the speech retainability in bad radio conditions

FT Orange Company Confidential

Topics to tackle with PCH state introduction

Consequently, it happens that

Ericsson IFLS cannot be applied from URA_PCH

Topics to tackle with PCH state introduction

Ericsson plans a solution in W13A (Feature Multi RAB observability (W13A)

FT Orange Company Confidential