CPC Is Not Sexy - Part 4

Back in 2007 I wrote three posts about Continuous Packet Connectivity (CPC), a bundle of 3GPP features aimed at improving network interactions for applications on 3G HSPA devices that only require a low bitrate or only poll the network periodically (e.g. once every few minutes).For details see here, here and here. All these features were part of 3GPP Release 7. One important feature was missing though, and that was to improve uplink speeds and reaction time in more power efficient states. This feature was added in 3GPP Release 8 in the "Enhanced Uplink for CELL_FACH State" Work Item. For details see RP-070677.

And here is what the feature actually does:

Today, when a HSPA mobile device is not in the Cell-DCH state, i.e. it is not observing and receiving data over the High Speed Shared Channels, but is instead in the less power consuming Cell-FACH, Cell-PCH or URA-PCH states, uplink packets are sent over the Random Access Channel (RACH). While this works quite o.k. there are several shortcomings:

• The capacity of the RACH is very limited. Hence, when the network detects that a device uses this channel for more than just a small IP packet or two, the connection  is immediately transferred to the fully active state (Cell-DCH). That requires a lot of signaling and in case the mobile ceases transmission again afterward, e.g. because it only wanted to send a keep-alive or poll message, it wastes capacity in the cell.

• State transitions from Cell-FACH to Cell-DCH take some time, in the order of hundreds of milliseconds, so it has a negative impact on user experience.

• As capacity on the RACH is very limited, only few users can use it at a time.

• Round trip delay times due to the use of the RACH are in the order of 250 to 300 ms compared to far less than 80 ms in fully active state.

• Only very small data packets can be transferred in on RACH slot. The document linked above contains an analysis that comes to the conclusion that an IP packet with 500 bytes requires over 10 RACH transmissions.

O.k., so what is the solution!? Instead of the RACH, Release 8 has specified how to use a fast Enhanced Uplink Channel (E-DCH) that was originally specified for HSUPA. This E-DCH is configured with default values, i.e. a modulation and coding scheme that is conservative enough so even devices at the edge of a cell can use it. No power control and channel quality feedback is necessary. Access to the channel is controlled by the network with the Acquisition Indication Channel (AICH) as before.

Looks like a very worthwhile feature to me, let's see when it appears in practice.

Comments

[Michal Morawiec]

Generally nice set of reasonable features, but seems like put a little bit aside in the pursuit for higher speeds.... or at least I couldn't find any deployment example beside some test announcement from February on NSN web site.