UMTS State Switching and Fast Dormancy Evolution

One of the things currently hotly debated in the industry is how to fix a current shortcoming of 3G UMTS networks, switches between different mobile device activity states on the air interface. The topic has many facets but it's possible to put the pieces together because 3GPP is pretty open about the standardization process as all documents are out in the open and available to everyone. That doesn't only include the specification documents but also all change requests and also discussion papers. This significantly helps to understand the issues different parties have with a topic. For this post I am going to draw heavily on them while also explaining my own opinion.

So what's this all about?

Actually, it's about two things: The UMTS air interface knows several activity states that are known as Cell-DCH, Cell-FACH, Cell/URA-PCH and Idle. When transferring data, the mobile is usually in Cell-DCH state and uses high speed channels to transmit and receive data (HSDPA, HSUPA). That's great but even if no data is sent and received, e.g. while the user reads a web page, it still requires a lot of energy on the mobile device's side to keep the connection going. On the network side, it's also a waste of resources to leave a mobile in Cell-DCH state when it is not transmitting data as there are only so many mobiles that can be assigned a high speed channel at a time. So both sides have an interest to move a connection to another state while it is not needed. In most networks today, a connection is moved to Cell-FACH state, which requires less energy and supports more users. Here, however, data throughput is very low and the amount of energy required on the mobile's side is still significant. Consequently, if there is an even longer inactivity time, e.g. 30 seconds, the network then puts the connection in Idle state in which the physical connection is removed while the IP address is kept.

So, what's wrong with that?

From the mobile device side this behavior can be very inefficient as a lot of energy is wasted before the Idle state is reached, especially when only background applications such as e-mail clients and instant messengers every now and then contact a server to remain reachable. As a consequence a number of of manufacturers have come up with a scheme that is referred to as Fast Dormancy. As described in this document, a mobile uses a "Signaling Channel Release Indication" message to trigger a release of the air interface connection when it thinks it is no longer necessary. So instead of waiting for the connection to be put into Cell-FACH and finally into idle, it can trigger a release to idle immediately. This significantly increases battery lifetime and if it is done in a reasonable way, it has no impact on today's networks as they would put the connection into Idle anyway, just a bit later. If for some reason, however, this functionality is improperly used, the air interface starts to oscillate between the states which is very inefficient for both the mobile, as a lot of power is required, and also for the network, because a lot of signaling is required between the Radio Network Controller, the base station and the mobile device to switch between the states.

The problem with the Idle State

While the Idle state is ideal for saving power on the mobile device's side, there is a big downside to using this state: When there is renewed activity it takes around 2.5 seconds before data can be exchanged again, something that is quite noticeable to the user. A solution to this is not putting the mobile device in Idle state but rather in the so called Cell- or URA-PCH state. From a mobile point of view, the Cell-/URA-PCH state is quite similar to Cell-FACH with the major difference being that the downlink does not have to be observed continuously. Only the paging channel must be checked every now and then to make sure incoming IP packets, phone calls or SMS messages can be received. In other words, the energy required to remain in this state is similar to the energy required for maintaining the Idle state but the signaling connection remains in place. When the mobile wants to transmit data again, it can immediately go to Cell-FACH state as there is no need to establish a signaling connection, perform an authentication procedure, enable ciphering, etc. This significantly reduces the time it takes before the first packet can be sent as described here. For the network, the advantage is that much less signaling is required for returning the device to a full Cell-DCH high speed state compared to doing the same from Idle.

Fast Dormancy and Cell-/URA-PCH

The issue with todays Fast Dormancy described above is that in case a network uses Cell-/URA-PCH, these states are not reached as the mobile triggers a complete release of the signalling connection. Hence, while the mobile device saves the maximum amount of energy, the network can not take advantage of the signaling reduction of the Cell-/URA-PCH states. Also, the mobile device can't benefit from the fast return to service times described above. From a mobile point of view, the current fast dormancy behavior being applied when there are only background applications is still preferable to waiting for the network sending it to Cell-/URA-PCH state as a lot of energy is wasted waiting for the network to make the decision. It should be noted at this point that the network is not slow in making the decision, it's rather intentional to ensure a good user experience to only have a user plane latency due to the state switching when absolutely necessary.

The Fix For Everything

So while today's fast dormancy implementations work well and do not have a negative impact on networks as most do not (yet) use the Cell-/URA-PCH states, things are o.k. for the moment. However, if network operators in the future decide to use the Cell-/URA-PCH states, the current fast dormancy implementations will become counter productive. As a result, a new mechanism has been specified in 3GPP TS 25.331 Release 8.10.0 (see chapter 8.1.14). Instead of just releasing the signaling connection when it desires the mobile has to wait for the expiration of a network configured timer (T323). Once the timer expires, the mobile can send a signaling connection release indication message with a new parameter that indicates "UE requested PS data session end". At this point the network can then decide to do nothing, to release the mobile to Idle or to put the connection into Cell-/URA-PCH state.

Network operators probably like this new mechanism as control over the air interface is returned to the network. Mobile devices also benefit from it as instead of going to Idle, the network can also put them to Cell-/URA-PCH state and hence, the latency when returning to a fully active state is much shorter than from the Idle state.

It's even possible to implement both fast dormancy approaches in a mobile. The availability of a value for timer T323 in the system broadcast of a cell can be used as a criterion to decide whether to use today's fast dormancy in case T323 is not present in the system broadcast or to use the new mechanism in case it is found. An elegant and backwards compatible solution with benefits for everyone.

Summary

From my point of view today's fast dormancy implementation does not harm networks as most have not activated Cell-/URA-PCH states yet. For the future, the new 3GPP Release 8 feature further improves on today's functionality and is backwards compatible. A win-win situation for everyone involved.

Comments

[Jaime]

Hi Martin,

I worked a couple of years as a 3.5G L1 Embedded Software Engineer for Nokia and I would like to know your opinion about CPC.

Do you think CPC is as effective as fast dormancy or the use of the Cell-PCH and URA-PCH states in terms of energy and network resource optimization?

Thank you very much in advance.

Cheers,

Jaime.-

[Martin]

Hi Jamie,

Thanks for your e-mail. I think Fast Dormancy and CPC are complementary. I see CPC being put to good use when there is bursty traffic ongoing, e.g. web browsing with lots of inactivity time, which is, however not very long (let's say less than a minute). Here CPC will be great to save battery. For other scenarios e.g. polling in the background for e-mail every 5 minutes for e-mails and do other things in such an interval while no other applications such as web browser interact with the network, fast dormancy will be the tool of choice as there is no need to keep the DCH open for a minute as no matter of how efficient CPC is I think it will still require significantly more energy than going to Cell-PCH or Idle. There is only little data on this yet but I can see how much energy is used by the UE being in Cell-FACH and only monitoring the traffic there. Now with CPC, power consumption might be lower than that due to downlink DRX but how much, that's difficult to say at the moment. From what I can tell by looking at the feature description, power consumption is likely to be still much higher then in Idle or Cell-PCH. If you have some insight into this from your days as L1 developer, your views are of course highly welcome!

Hope this helps,
Martin

[SG]

Hi Martin,

I don't really get your point dealing the negative impact of CELL/URA_PCH: from what I remember, the network is not mandated to respond to the UE with a signaling connection release. We could imagine the network answers with a physical channel reconfiguration moving the UE to CELL_PCH state if it does not want the signaling connection to be released.
What's your opinion?

FYI: CELL/URA_PCH are effectively not used (At least I've never seen it) in Europ, but seem to be highly appreciated in Asia.

[Jaime]

Hi Martin,

Thank you very much for the answer to my question.

My opinion is that there will be no clear way of evaluating the impact of CPC on energy saving until handset manufacturers start running hands-on tests on CPC-capable prototypes.

From my view as former L1 engineer, it is very difficult to come up with some sound energy saving numbers as this strongly depends on the specific L1 software implementation (MIPS, memory usage, etc).

Cheers,

Jaime.-

[Martin]

Hi Jamie,

Thanks for the additional info. Yes, I am very much looking forward to see how energy efficient CPC will be in practice and how the parameters for it will be set.

Cheers,
Martin

[Martin]

Hi Sylviane,

You are correct, the network is not required to release the connection after a SCRI as the specs say "may in turn [...]". But what's the point of not releasing the connection and moving to cell-PCH when the UE has told the network that the signaling connection was released? As the mobile no longer listens to the signaling connection the move to cell-PCH ends up nowhere in case the mobile has really released the signaling connection (the initial use for the message...). Hence, I think 3GPP has done the right thing and updated the specs in Release 8 to allow a functional and working way out of this :-)

Cheers,
Martin

[Nasula]

Martin, I believe Sylviane came to the same conclusion as I did from readkin your linked document by NSN and DT et al.

My reading is that the UE should not release the signalling connection unless it's a NAS failure or powerdown. In these cases the cause: “UE Requested PS Data session end” wouldn't be in the request.
If the cause value is there, the message is used as a request from the UE to get moved to PCH. Thus the signalling is not released and the mobile is still listening in cell PCH but at a significantly lower power of course. A brittiant solution.

[lou]

CELL_PCH has been used by operators for many years. I worked for 3 UK and we had it some 7 years ago.

Also we had phones doing this stunt, i.e., asking the nw to release the rrc connection- but in reality it was no request just an info as the decision had already been made by the phone. this is is a very very bad idea. the phone and nw loose state synch which creates all kinds of problems. also this means the operator cannot optimise its nw- each phone vendor will have an implementation to have better battery live in the stats. in the end the issue is clear- the radio layer, in phone or nw, has no knowledge of the app layer so it does not know when data will be coming or not. the phone is as clueless as the nw since an app server can send data at any time. the only rational approach is for the phone to respect the nw instructions which allow the operator to decide where the trade off should be