Sei sulla pagina 1di 49

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

FT Orange Company Confidential

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

FT Orange Company Confidential

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
FT Orange Company Confidential

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 ).

FT Orange Company Confidential

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.

FT Orange Company Confidential

Page 6

Agenda
Overview: Fast Dormancy and PCH states
Main topics to tackle with PCH states introduction

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

Main topics to tackle with Network Control Fast Dormancy introduction


General recommendations with Network Control Fast Dormancy activation
Focus on Enhanced Cell FACH feature
Annexes

FT Orange Company Confidential

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


FT Orange Company Confidential

Page 8

Topics to tackle with PCH state introduction


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

FT Orange Company Confidential

Page 9

Topics to tackle with PCH state introduction


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
FT Orange Company Confidential

Page 10

Topics to tackle with PCH state introduction


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
FT Orange Company Confidential

Page 11

Topics to tackle with PCH state introduction


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

FT Orange Company Confidential

Page 12

Topics to tackle with PCH state introduction


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

FT Orange Company Confidential

Page 13

Topics to tackle with PCH state introduction


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
FT Orange Company Confidential

Page 14

Topics to tackle with PCH state introduction


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

FT Orange Company Confidential

Page 15

Agenda
Overview: Fast Dormancy and PCH states
Main topics to tackle with PCH states introduction
Main topics to tackle with Network Control Fast Dormancy introduction
Management of legacy UEs
Deal with some IOT issues on R8 devices
Impact on signaling capacity at PS Core network level

General recommendations with Network Control Fast Dormancy activation


Focus on Enhanced Cell FACH feature
Annexes

FT Orange Company Confidential

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
FT Orange Company Confidential
Page 17

Topics to tackle with NCFD introduction


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
FT Orange Company Confidential

Page 18

Topics to tackle with NCFD introduction


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
FT Orange Company Confidential

Page 19

Agenda
Overview: Fast Dormancy and PCH states
Main topics to tackle with PCH states introduction
Main topics to tackle with Network Control Fast Dormancy introduction
General recommendations with Network Control Fast Dormancy activation
Focus on Enhanced Cell FACH feature
Annexes

FT Orange Company Confidential

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

FT Orange Company Confidential

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

FT Orange Company Confidential

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

FT Orange Company Confidential

Page 23

Agenda
Overview: Fast Dormancy and PCH states
Main topics to tackle with PCH states introduction
Main topics to tackle with Network Control Fast Dormancy introduction
General recommendations with Network Control Fast Dormancy activation
Focus on Enhanced Cell FACH feature
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

FT Orange Company Confidential

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
FT Orange Company Confidential

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
FT Orange Company Confidential

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

FT Orange Company Confidential

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
FT Orange Company Confidential

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
FT Orange Company Confidential

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

FT Orange Company Confidential

Page 30

Agenda
Overview: Fast Dormancy and PCH states
Main topics to tackle with PCH states introduction
Main topics to tackle with Network Control Fast Dormancy introduction
General recommendations with Network Control Fast Dormancy activation
Focus on Enhanced Cell FACH feature
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

FT Orange Company Confidential

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
FT Orange Company Confidential

RAB PS 0/0
activation

2 steps transition
activation for all UEs

Page 32

Fast Dormancy parameters setting per supplier


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: RsvdPara1=RSVDBIT1_BIT20-0;
SET URRCTRLSWITCH: RsvdPara1=RSVDBIT1_BIT29-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

FT Orange Company Confidential

Page 33

Fast Dormancy parameters setting per supplier


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.

FT Orange Company Confidential

Page 34

Fast Dormancy parameters setting per supplier


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)

FT Orange Company Confidential

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

FT Orange Company Confidential

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)

FT Orange Company Confidential

Page 37

Suppliers proposal to deal with Multi RAB handling


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

FT Orange Company Confidential

Page 38

Suppliers proposal to deal with Multi RAB handling


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

FT Orange Company Confidential

Page 39

PS session establishment procedure from Idle


For small and big data to transfer

extracted from Smartphone Solutions White Paper (from huawei Mlab)


FT Orange Company Confidential

Page 40

PS session establishment procedure from PCH


For big data to transfer (transition to DCH)

extracted from Smartphone Solutions White Paper (from huawei Mlab)


FT Orange Company Confidential

Page 41

PS session establishment procedure from PCH


For small data to transfer (no transition in DCH)

extracted from Smartphone Solutions White Paper (from huawei Mlab)


FT Orange Company Confidential

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
FT Orange Company Confidential

Page 43

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


transitions for smartphone devices
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

FT Orange Company Confidential

Page 44

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


transitions for smartphone devices
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)
FT Orange Company Confidential

Page 45

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


transitions for smartphone devices
Initial Device solution: Proprietary fast dormancy (2/2)
UE

Node B

UE in
DCH

RNC

SGSN

On going PS I/B service (Packet transfer in UL & DL)


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


RADIO LINK DELETION REQUEST
RADIO LINK DELETION RESPONSE

UE in
IDLE

FT Orange Company Confidential

Page 46

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


transitions for smartphone devices
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

FT Orange Company Confidential

Page 47

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


transitions for smartphone devices
Network solution: Network Control Fast Dormancy (2/3)

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.

FT Orange Company Confidential

Page 48

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


transitions for smartphone devices
Network solution: Network Control Fast Dormancy (3/3)
UE

Node B

RNC

SGSN

On going PS I/B service (Packet transfer in UL & DL)

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

RADIO LINK DELETION REQUEST


RADIO LINK DELETION RESPONSE
UE in
URA_PCH
FT Orange Company Confidential

Page 49