I recently noticed that LTE power saving settings are significantly different across different networks in different countries. Before sharing this info I thought it would be good to have a quick overview post of how LTE power saving works and which main parameters the network can configure.
In LTE, the air interface between the mobile device and the base station (the eNodeB) can be in two main states:
When tranmitting data the mobile device is in RRC-CONNECTED state and data can be sent and received at any time. In addition the core network, i.e. the Mobility Management Entity (MME) is aware in which cell the device is located and the Serving Gateway (S-GW) can send and receive user data for that device to the cell at any time.
In RRC-CONNECTED state the device has to listen to the downlink control channel in every subframe, i.e. once per millisecond if data is scheduled in the downlink direction and to find out if resources have been assigned to it for uplink data transmission. In addition the mobile device has to send control information in the uplink direction to remain synchronized to the network and for the network to be able to estimate the channel quality, e.g. by scheduling Sounding Reference Signals (SRS) the mobile device has to periodically transmit in the uplink direction.
When no data is transmitted for a longer period of time it is not economic to keep the mobile in this state as it wastes resources on the air interface and power requirements are high on the mobile device side. So after some time the network will set the connection into RRC-IDLE state. The mobile device keeps its IP address(es) but the physical connection to the base station is cut. If data arrives in the downlink direction while the device is in RRC-IDLE state, the MME has to page the device in one or more cells and wait for the device to re-establish a physical connection. As the paging cycle in practice is between one and two seconds, there is a significant delay associated to this. Also, the MME and S-GW become involved in this process so the network usually wants to be sure there is no further data traffic for quite some time (e.g. ideally several minutes) before setting the mobile device into RRC-IDLE state.
Bursty Data Transmission
In practice many applications have quite irregular data transmission patterns. A lot of data can arrive within a few seconds, e.g. when the user clicks on a link to load a new web page. After that nothing may happen for many seconds. After that time, the user might click on another link and the procedure repeats. Setting the air interface connection into IDLE state between such events is not every economical from a signaling point of view. Also, there might be occasional IP traffic in between such events such as TCP ACK packages or TCP FIN when IP connections are closed. Setting up a new air interface connection for such events is even more uneconomical. On the other hand, keeping a mobile device in RRC-CONNECTED state for a long time without data flowing wastes air interface resources and power on the mobile device and is uneconomical as well.
RRC-CONNECTED With DRX
This is why there is a Discontinous Reception (DRX) mode that can be activated by the network while the mobile device is in RRC-CONNECTED state. In this mode the device does not have to listen to uplink and downlink assignments in each 1 millisecond subframe but can deactivate its transmitter and receiver for much longer periods of time. DRX parameters are commonly signaled by the network during an RRC connection setup procedure in an RRC Reconfiguration message either separately or together with other parameters. For DRX the following parameters are relevant:
DRX Inactivity Timer: Informs the device after which time (number of 1 ms subframes) it can go into DRX mode if it hasn’t received any downlink data and hasn’t sent any user data in the uplink direction.
Long Drx Cycle Start Offset: Informs the device how many subframes (i.e. 1 ms chunks) it can deactivate its receiver before it has to wake up again. The name of the parameter sounds a bit strange as it doesn’t only inform the mobile device of the DRX periodicity but also when the cycle starts in the overall transmission pattern. Furthermore, there is an optional short drx cycle parameter so the network can first schedule a short period after which a mobile device has to wake up and later-on a longer period. In practice, only few networks make use of this two staged approach.
On-Duration Timer: How many subframes a device has to listen to the downlink control channel for potential downlink transmission assignments before it can go back to sleep for the rest of the DRX cycle.
Time Alignment Timer Dedicated: One catch in this approach is that even while DRX is activated the mobile device has to continue to send uplink control information not only in during the “On” time but during the complete DRX cycle. While such control information is sent, power saving is rather limited. After some time in DRX state (in the order of a few seconds) the mobile can stop sending uplink control information as well and has to consider itself to be no longer time aligned with the network. At this point it can no longer ask for uplink transmission opportunities quickly in dedicated time instances but has to use a standard random uplink request procedure which takes much longer to complete. Also, it has to first synchronize itself with the network again before it can acknowledge data sent in the downlink direction.
Here we go, that’s how LTE DRX on the air interface works on a high level. For the nitty gritty details I found this post very helpful. So much for the theory, but how are networks configured in practice!? Now that the groundwork is laid, I’ll describe some parameter sets in a follow up post that I have observed in practice.