Nokia Siemens Networks has collaborated with Qualcomm to carry out the industry’s first successful interoperability test of the new 3GPP standardized Release 8 Fast Dormancy feature. Unlike proprietary approaches to fast dormancy, the new standard allows operators to take full advantage of smart network features such as Cell_PCH without worrying that individual handset settings will ignore network controls.
The test was conducted at Nokia Siemens Networks’ Smart Lab in Dallas using Nokia Siemens Networks’ Flexi Multiradio Base Station and Radio Network Controller and Qualcomm’s QSC7230TM smartphone optimized chipset. The test showed how smartphones can act dynamically, exploiting Cell_PCH on Nokia Siemens Networks’ smart networks or adjusting to Fast Dormancy on other vendors’ traditional networks.
In fact the operators have been getting upset quite for some time because of smartphone hacks that save the UE battery life but cause network signalling congestion. See here.
To explain the problem, lets look at the actual signalling that occurs when the UE is not transmitting anything. Most probably it gets put into CELL_PCH or URA_PCH state. Then when keep alive messages need to be sent then the state is transitioned to CELL_FACH and once done its sent back to CELL_PCH. Now the transitioning back from CELL_FACH (or CELL_DCH) to CELL_PCH can take quite some time, depending on the operator parameters and this wastes the UE battery life.
To get round this problem, the UE manufacturers put a hack in the phone and what they do is that if there no data to transmit for a small amount of time, the UE sends RRC Signalling Connection Release Indication (SCRI) message. This message is supposed to be used in case when something is gone wrong in the UE and the UE wants the network to tear the connection down by sending RRC Connection Release message. Anyway, the network is forced to Release the connection.
If there is another requirement to send another keep alive message (they are needed for lots of apps like Skype, IM's, etc.) the RRC connection would have to be established all over again and this can cause lots of unnecessary signalling for the network causing congestion at peak times.
If there is another requirement to send another keep alive message (they are needed for lots of apps like Skype, IM's, etc.) the RRC connection would have to be established all over again and this can cause lots of unnecessary signalling for the network causing congestion at peak times.
To speed up the transitioning to CELL_PCH state in Release-8 when the UE sends SCRI message, its supposed to include the cause value as "UE Requested PS Data session end". Once the network receives this cause it should immediately move the UE to CELL_PCH state.
This is a win win situation for both the network and the UE vendors as long as a lot of UE's implement this. The good thing is that even a pre-Rel8 UE can implement this and if the network supports this feature it would work.
GSMA has created a best practices document for this feature which is embedded below.
Fast dormancy from Dono Miguel
Further Reading:
- UMTS State Switching and Fast Dormancy Evolution - Martin Sauter
- RP-090941 - System impact of poor proprietary Fast Dormancy implementations
- RP-090942 - Clarification on Enhanced SCRI approach for fast dormancy
- RP-090960 - Configuration of Fast Dormancy
- R2-096882 - Changes to Release-8 Fast Dormanc
4 comments:
Does Fast Dormancy Matter?
Should we be designing our latest and most advanced cellular network technologies to accommodate inadequate battery technology in today’s devices? It’s been supposed that the fact that smartphones today enter “idle” mode when a data transmission to the mobile device ceases for a few seconds. This repeated disconnect and connect of a data session is purported to save battery life while adding a significant amount of signaling to the LTE network... Read more by Randy Snyder at the following.
http://diametriq.blogspot.com/2012/08/does-fast-dormancy-matter.html
How can i find a list of 3gpp release 8 complying devices ?
Regards
How do you know whether release 8 UE Supports Fast Dormacy or not ?
Which parameter in the UE shows whether it supports Fast dormacy ?
I have looked RRC connection V8 message but could not able to find appropriate parameters ?
There is no easy way to find if the UE is supporting fast dormancy or not. In the test environment, when the data call is started and no data is being sent, if the UE sends SCRI with cause other than "UE Requested PS Data session end" (this cause came in Rel-8) then it supports fast dormancy. A rel-8+ UE will send "UE Requested PS Data session end" showing that it supports Network Controlled Fast Dormancy (NCFD).
Post a Comment