Already since the very early days of 3G, there have been 5 air interface states in the specs: Cell-DCH, Cell-FACH, Cell-PCH, URA-PCH and Idle. In all networks I have so far encountered, only Cell-DCH, Cell-FACH and Idle have been used. I haven't seen the other two states yet, which can reduce the time it takes to return from a dormant to a fully active state, so I could only speculate on their effectiveness. Until today.
Here is a typical round trip delay (ping) behavior when returning from Idle to Cell-DCH:
PING 85.214.10.20 1000 (1028) bytes of data.
1008 bytes from 85.214.10.20: icmp_seq=1 ttl=47 time=2571 ms
1008 bytes from 85.214.10.20: icmp_seq=2 ttl=47 time=226 ms
1008 bytes from 85.214.10.20: icmp_seq=3 ttl=47 time=236 ms
Due to the state switching the answer to the first ping, the request takes over 2.5 seconds. Especially when web browsing this delay is quite noticeable.
And this is the round trip delay profile when returning from Cell- or URA-PCH to Cell-DCH:
PING 85.214.10.20 1000 (1028) bytes of data.
1008 bytes from 85.214.10.20: icmp_seq=1 ttl=47 time=987 ms
1008 bytes from 85.214.10.20: icmp_seq=2 ttl=47 time=236 ms
1008 bytes from 85.214.10.20: icmp_seq=3 ttl=47 time=236 ms
Instead of 2.5 seconds, the first answer is already received in less than a second, which significantly improves the overall user experience. Further, I observed that the network is configured with a fully active Cell-DCH state for 20 seconds after which the Cell- or URA-PCH state is entered pretty quickly without staying too long in Cell-FACH state.
Once in Cell- or URA-PCH state the network first goes to Cell-FACH and remains there if only small IP packets are are sent. This was the case for example with a standard ping which is why for the example above, a 1000 byte ping message was used to trigger an immediate state change to Cell-DCH. This is quite typical for web browsing as when clicking on a link, the HTTP request package has that kind of size if the page is on the same web server and hence no DNS lookup is required, the TCP link is already established and the request including cookies are sent straight away.
I also did some tests with my somewhat 'older' N95 8GB and with an old firmware version. Here the first packet took around 1500 ms to arrive. Quite a bit slower than the times above reached with a current Class-7 HSPA 3G USB stick but still much faster than returning from Idle state.
For further background reading on the state changes and procedures there's always my book on the topic for a more detailed introduction and 3GPP specs TS 25.331 for all the details.
Hi Martin. To my understanding, one of the reasons why Cell-PCH (let alone URA-PCH) is not used in many networks is the fact that some of the more prominent vendors don’t necessarily even support them.
Then you have the other fact that by leaving the phones longer in DCH or FACH, the phones keep reporting measurements (for example 2G) and the operators can use that to measure their networks.
Of course this has an effect on battery life especially with bursty smartphones. This is one of the reasons why RIM and Apple use the controversial “Fast dormancy”, which increases signalling load in the networks dramatically.
I suspect that with the rise of dongles and smartphones, the operators are forced to plan with PCH-states and have the DCH timers very low with a quick transition to PCH to save battery.
Interesting post, Martin. Nasula – not sure I understand the measurement frequency argument. Don’t the thresholds control that?
Martin
Nice post. This is extremely timely & very interesting.
Coincidentally, picoChip we’ve just announced support for cell-PCH and a couple other additions to our femtocell chipsets.
This is to better support ‘always-on’ devices, especially for enterprise or ‘metro-femto’ applications.
Residential femto the battery life improvement and responsiveness are nice, but the congestion efffect matters as you get lots of devices in dense areas.
http://www.picochip.com/news/148/
AT&T switched on CELL_PCH well over a year ago where I live in the US. It made a noticeable difference to my experience with the iPhone. In fact I suspect that the popularity of the iPhone and its very bursty traffic profile is what prompted AT&T to buy it (and I assume all the vendors charge extra for CELL_PCH :-)) for their network.