A bit of a strange post title today but fitting the tech deep dive. When recently looking for something in the UTMS RRC Specification Document (3GPP TS 25.331) I noticed a parameter introduced in Release 6 of the specification which is called "deviceType". The parameter is included for example in the ue-radioAccessCapabilities Information element in the RRC Connection Setup Complete message. By default its value is "doesBenefitFromBatteryConsumptionOptimisation" but can be set to the device to "doesNotBenefitFromBatteryConsumptionOptimisation". No further explanation is given in the spec. I have to say I'm intrigued as to me it looks like something that could be used on top of the Fast Dormancy and Continuous Packet Connectivity extensions. So far the world has mostly looked at these two and I think the combination of the two of them makes a good package indeed as I described here.
A combination of FD and CPC makes a lot of sense for battery driven devices. But what about devices that do not require an optimization to conserve battery power? UMTS Modules in netbooks for example do not have the same battery capacity restrictions and here it might be better, both for the user and the network, to keep the device in Cell-DCH state (with CPC on top) for a much longer time if the user is actively using an application that requires frequent exchanges with a server on the Internet. For the network, fewer state changes would be required while on the UE side, no state changes mean that data can be delivered more quickly after the user has, for example, clicked on a link.
One could even imagine that the parameter could be used to configure CPC in a different way depending on the type of device. For battery constrained devices, CPC could be configured with larger transmission/reception gaps to conserve energy, while for other devices, shorter gaps could be configured for faster reaction times.
But o.k., let's first let the industry figure out how to do FD (Release 8) and CPC well before going to the next level of optimization…