Slide 1OLN/RNM/REP/RCT
FT Orange Company Confidential
Page *
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
PCH, a RRC connected state to use with Fast Dormancy
Fast Dormancy features’ description
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 *
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 Cell_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
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
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
Cell_FACH
Inactivity in UL & DL for z seconds
Inactivity in UL & DL for y seconds
FT Orange Company Confidential
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 *
Fast Dormancy introduction leads to an enhancement of dimensioning KPIs whatever the RAN vendor
* In OFR, only URA_PCH tested. FD performance are extrapolated.
Fast Dormancy benefits can vary from a network to another one due to
device population,
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
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
OSP with Huawei RAN (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
OJO with E/// RAN (URA_PCH)
70 % reduction of RRC connection setup & PS RAB Attempts
20 % reduction of RNC load
OFR with ALU RAN
Main topics to tackle with PCH states introduction
Procedure collision with paging Type 1 signaling procedure
Potential FACH congestion
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
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 in URA_PCH, SMS are sent thanks to Paging type 1 message, there will be an increase of this message;
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
To reduce this impact, a redesign (size reduction) of URA can be necessary
FT Orange Company Confidential
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
Transition PCH to FACH leading to FACH congestion (2/2)
Means to tackle this potential FACH congestion lie in one of the followings
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
Means
Description
Pros
Cons
Free camping Parameter Tuning
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
Activation of a secondary SCCPCH Parameter Tuning
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
Activation of HS-FACH (enhanced FACH) in DL New feature to deploy
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
Direct upswitch from URA_PCH to DCH New feature to deploy
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)
FT Orange Company Confidential
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
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
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 *
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
Topics to tackle with PCH state introduction
Mobility and service steering mechanisms
Load balancing and traffic steering policy shall be reviewed with the introduction of URA_PCH and fast Dormancy features
FT Orange Company Confidential
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
Main topics to tackle with PCH states introduction
Main topics to tackle with Network Control Fast Dormancy introduction
Management of legacy UEs
Impact on signaling capacity at PS Core network level
General recommendations with Network Control Fast Dormancy activation
Focus on Enhanced Cell FACH feature
Annexes
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)
Topics to tackle with NCFD introduction
Non NCFD capable UEs
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 *
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
Topics to tackle with NCFD introduction
IOT with some Rel8 devices, supposed to be NCFD capable
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
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 on-going traffic
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
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 case of 3G Direct Tunnel used, the usage of NCFD should decrease the signaling on the GGSN and SGSN
FT Orange Company Confidential
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
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
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
step 1: Activate NCFD only for capable devices
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
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)
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
If the strategy above is not sufficient, apply an early release of PS session in bad radio condition
FT Orange Company Confidential
Fast Dormancy activation strategy (2/2)
step 2: Activate the direct upswitch transition (PCH to DCH) and potentially activate NCFD for all type of devices
Upon validation of this feature, activate it in the 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
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
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
List of NCFD compatible devices
Proposals from RAN suppliers on Multi RAB handling
Signaling during states’ transitions
Faster message exchanges: about 100/200 ms improvement
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 E-DCH resources are quickly released by the UE (saving CE & dummy connections)
Access coverage can be improved (better CSSR ?)
RACH de-congestion
Enhanced CELL FACH enables to improve signaling & save capacity over the network.
Transport channels
Physical channels
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
cons
pros
FACH
SCCPCH
32kbps/10ms
HS-DSCH
HSPDSCH
5.76Mbps/2ms
42Mbps/2ms
Page *
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
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)
CE usage
More CE consumption in signalling phase
Throughput in cell DCH is not limited
Throughput is limited in cell FACH (2 Mbps max)
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
UL PS call example
minrate for SRBoHSUPA
Page *
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
Results of these enhancements:
about 3dB better RACH coverage with enhanced CELL_FACH (DL +UL)
linked to configuration and trade off between performance (speed) and coverage
minimal gain
presentation title
Page *
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
presentation title
Network controlled Fast dormancy (+ PCH)
NCFD is ready for deployment at the moment, Enhanced Cell FACH is still pending
Devices availability or lack of affiliates interests
W11B
RAN13
RU20
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
presentation title
Enhanced CELL FACH DL+UL
+ Less signaling for background traffic
+ Lower UL CE consumption
Fast Dormancy
+ Less signaling
presentation title
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
List of NCFD compatible devices
Proposals from RAN suppliers on Multi RAB handling
Signaling during states’ transitions
Ericsson case
MO
Attribute
Value
Huawei case (RAN 14)
URA_PCH activation
BE FACH to PCH Transition timer : 10 s PS Inactivity time= 1800 (30 min)
Fast Dormancy activation
FT Orange Company Confidential
Huawei case (RAN 15)
These are the default values as recommended in Huawei RAN 15
It shall then be tested before full deployment.
SCRI sending is decided by UEs
State transition timer reduction
Direct Upswitch activation
ALLU case (UA 08.1)
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)
Parameter
value
isFastDormancyAllowed
ueVersionForScri
R8 (R8 and later UE versions are applicable for Fast Dormancy supporting 3GPP SCRI IE specification)
t323
isAlwaysOnAllowed
pchRrcStates
URA_PCH
uraPchToIdleTimer
FT Orange Company Confidential
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
interne Orange
sorted by manufacturer
ONE TOUCH IDOL / Orange San Remo
ONE TOUCH Scribe Easy
ONE TOUCH STAR (6010)
sorted by manufacturer
Desire HD
One S
Huawei
sorted by manufacturer
Nexus5
Optimus L9
Prada 3.0
Lumia 620
Lumia 625
Lumia 710
Lumia 720
Lumia 800
Lumia 820
Lumia 920
Lumia 925
interne Orange
sorted by manufacturer
GT-I8160P - Galaxy Ace 2 NFC
GT-I8190 - Galaxy S III Mini
GT-I8190N - Galaxy S III mini NFC
GT-I8260 - Galaxy Core
GT-I9105P - Galaxy S II Plus NFC
GT-I9195 - Galaxy S4 mini
GT-I9295 - Galaxy S4 Active
GT-I9300 - Galaxy S III
GT-I9505 - Galaxy S4
GT-N7000 - Galaxy Note
interne Orange
sorted by manufacturer
GT-P3100 - Galaxy Tab 2 7'' 3G
GT-P5100 - Galaxy Tab 2 10'' 3G
GT-P5200 - Galaxy Tab 3 10.1'' 3G
GT-P5220 - Galaxy Tab 3 10.1'' LTE
GT-P6200 - Galaxy Tab 7.0 Plus 3G
GT-P6800 - Galaxy Tab 7.7 3G
GT-P7300 - Galaxy Tab 8.9
GT-P7500 - Galaxy Tab 10.1
GT-S5310 - Galaxy Pocket Neo
GT-S7390 - Galaxy Trend Lite
GT-S7500 - Galaxy Ace Plus
GT-S7562 - Galaxy S Duos
GT-S7710 - Galaxy Xcover 2
SM-G350 - Galaxy Core Plus
SM-N9005 - Galaxy Note 3
XE500T1C - ATIV Smart PC
sorted by manufacturer
Kis / Orange Dublin
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
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
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
For small and big data to transfer
extracted from Smartphone Solutions White Paper (from huawei Mlab)
FT Orange Company Confidential
Page *
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
For small data to transfer (no transition in DCH)
extracted from Smartphone Solutions White Paper (from huawei Mlab)
FT Orange Company Confidential
Page *
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 *
Fast Dormancy (FD) as a solution to better handle state transitions for smartphone devices
What is the past network behavior? (2/2)
UE in DCH
UE in FACH
UE in IDLE
On going PS I/B service (Packet transfer in UL & DL)
Packet transfer inactivity in UL & DL detected
Inactivity timer expiry: T1
Inactivity timer expiry: T2
RRC RB RECONFIGURATION
Page *
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
Drawbacks
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 *
Fast Dormancy (FD) as a solution to better handle state transitions for smartphone devices
Initial Device solution: Proprietary fast dormancy (2/2)
UE in DCH
UE in IDLE
On going PS I/B service (Packet transfer in UL & DL)
Packet transfer inactivity in UL & DL detected (radio level)
UE detects PS inactivity
(no SCRI cause)
Page *
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
state transition controlled by the network
supported by all recent smartphones
Drawbacks
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 *
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 *
Fast Dormancy (FD) as a solution to better handle state transitions for smartphone devices
Network solution: Network Control Fast Dormancy (3/3)
UE in DCH
UE in URA_PCH
DCH to URA_PCH
On going PS I/B service (Packet transfer in UL & DL)
Packet transfer inactivity in UL & DL detected
RRC SIGNALING CONNECTION RELEASE INDICATION
(SCRI CAUSE = PS DATA Session END)
RADIO LINK DELETION REQUEST
RADIO LINK DELETION RESPONSE