Fast Dormancy Rel8 in the wild

When fast dormancy was originally introduced a few years back by RIM on the Blackberry, few people would probably have realised how much of a hot topic it would become. A few years later the name has been adopted as a standard and the specifications have been altered to cater for it.

Fast dormancy was initially thought of by UE vendors as a way of saving battery life. Rather than staying in the power hungry state CELL_DCH for as long as the network timers dictated, the UE could send a SCRI RRC message (Signalling Connection Release Indication) which would result in an immediate transition to IDLE. Everything was fine for a while, but as more and more UE vendors started implementing similar mechanisms, the signalling load to transition UEs to IDLE and back to connected mode every time there was even a keep alive, started creating problems. RNC processor load shot up, signalling load on the IuPS and Iub increased and operators started complaining.

The 3GPP finally addresses the whole issue in Rel8, with the standardised implementation of Fast Dormancy. Now the network indicates it supports Fast Dormancy by broadcasting timer T323 in SIB1. The UE is allowed to send the SCRI according to the specs "if the upper layers indicate that there is no more PS data for a prolonged period". Notice the ambiguity in the "prolonged period". This is definately open for interpretation. The difference however now is that within the SCRI is a new IE (information element) "UE Requested PS Data session end". This now gives the network the ability to switch the UE to a more "battery friendly" state such as CELL_PCH or URA_PCH.

The specs also allow the UE to re-send the SCRI from CELL_PCH or URA_PCH if the DRX cycle in this state(s) is shorter than IDLE DRX. However timer T323 has to expire first before any more SCRIs are sent.

The screenshot below shows that networks have already started implementing this (this one taken from T-Mobile UK). On this particular case T323 is set to 0s meaning the device does not have to wait at all in case it decides to send a subsequent SCRI message.