This week I have been reviewing the power consumption of a typical LTE dongle – the Huawei E3276 – chipset is a HiSilicon Hi6920, others specs are available here. I am using a Monsoon Powermonitor which is basically a power source with a high frequency current sampling running at 5Khz. My LTE network is Movistar Spain, so mainly 1800Mhz/10Mhz in LTE, and quite standard 2G and 3G network. I am in an openoffice close to the 2G/4G antennas, and even closer to a 3G antennas if I believe the RSSI meter.


I am using the APN, so this USB stick has a public IP address and I could ping it from a remote server. My process is quite simple : I wait for the modem to reach idleness, then I ping’d the public IP of the modem for 10 packets at the standard payload (64 bytes), then wait for idleness, and then ping’d again for 10 packets with 1200 bytes payload. This way, I am sure to control when to cross the threshold as defined by the network in terms of powerstates. Also, by using a USB stick, I can narrow the consumption of the modem itself, and not the background noise of the operating system on a mobile.

Let’s start with the 4G measurement.

Capture d’écran 2014-02-23 à 20.25.11

On this figure we can clearly identify the connected/idle power state of the 4G state machine. Also, we can detect some spurs which probably betray power used for transmitting. Roughly, I measured , with pretty good coverage, a steady consumption of  93,3 mA Idle, 184 mA Connected. I also measured the timeout set by the operator to be 12s (i.e. between the last ping packet exchange until the timeout).

And then the 3G measurement. This one reveals the complexity of 3G networks regarding state management (more details here and here, and in my recent papers).


In this particular case, the first series of small ping (64 bytes) is using the shared transmission mode (FACH) as the data rate is quite slow (64 B/packet). The ping reply from the mobile device are quite visible (small power spike, I can count 10 packets quite easily). In the second batch, the data rate is more important (1200B/packet) which triggers the dedicated transmission mode, where the network allocate dedicated codes for this transmission. Then, after the end of the transmission, the DCH is demoted into FACH and the final timeout can be observed – should be around 12s on Movistar Spain (as found here). The interesting parameters here is that the consumption is only 78,08 mA Idle, 153 mA in FACH, 218,40 mA in DCH – which means 4G is a bit more expensive in Idle, but is less expensive during connected time. Combined with the high rates and the low latency, it is clear 4G is improving also the situation during active session on this particular device.

Last but not least, I wanted to compare with 2G. Interesting graph :

2G power meter

The radio in 2G is quite simple – consumption is growing with the size of the packet. we can actually see the power spike for each packet transmitted by the modem (ping reply) to my incoming ping. I measured 75,77mA Idle, 186mA-308 mA connected – depending on the payload. Clearly 2G is ideal for low, M2M, keepalive connectivity management.

So let’s look at the results :

  • 4G : Idle : 93,3 mA Idle, 184 mA Connected
  • 3G : Idle : 78,08 mA , 153 mA in FACH (small payload) , 218,40 mA in DCH (large payload)
  • 2G : Idle : 75,77mA, 186mA (small payload) 308 mA (large payload)

So sadly 4G is quite perfect except for idleness – I am not sure if a the DRX is enabled on this particular combo of chipset/network. Nevertheless it also means that to maximize battery life with this chipset one has to play between 3G and 4G. Not easy…

3G complexity is once again demonstrated – not easy to play with the timeout and the different states when one want to spare battery life.

Last word : 2G is quite disappointing- i.e. not saving much in Idle, and ending up consuming as much as 4G during transmission. Probably better to refarm all this 2G frequency in the end.

If anyone interested, I have saved my samples. You can open them with the Monsoon tool.



Catégories : Hackmeasurement