AW: fyi: An Experimental Study of Web Transport Protocols in Cellular Networks

> > When "keep snappy" = ON, the device will just stay in state DCH _all 
> > the
> time_.
> > Done. Let the user trade off "snappy" vs "power drain".
> 
> While the battery life issue is certainly a very important one, it's 
> important to recognize that the other resource being managed here is 
> the carrier's radio resources.  If you keep the device on in an active 
> state to avoid the latency associated with dormant states, you are
> consuming resources that have a real impact in crowded networks.    I

Thanks for the slides .. interesting. Carrier's network resources .. sure.

2 comments

The mere act of transitioning in and out of DCH consumes network resources too. From the slides:

"That lead time or RAB (Radio Access Bearer) activation delay time sued to transition from Idel to Cell_DCH is not only inconvenient from the user experience point of view, it also involves a long sequence of signalling messages (needed in order to activate the radio
bearer) that puts considerable load on the RNC's (Radio Network Controllers)"

Then the FACH state seems to be designed for low volume, continuous data transfer, but unfortunately, it does not seem to be exceptionally low-latency. When I get this right, FACH is happening on some kind of shared radio channel, different from DCH which uses exclusive channels. Maybe the radio channel sharing in FACH is a reason for the increased latencies?

It's a pity that there isn't a low-bandwidth, low-latency, low-power, always connected mode.

Received on Friday, 30 March 2012 08:17:56 UTC