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.