Sign up ×

I'm increasingly seeing mobile networking technologies being used to get internet access in areas where it is otherwise not available.

While mobile networking is usually not yet viable as the primary internet connection, mobile technology looks like a good option for an emergency fallback.

Bandwith is not the problem: With HDSPA, speeds of several MBit are possible, which provides a decent uplink. However, I know from personal experience that mobile networks internet links (via GPRS, UMTS etc.) have much higher latencies than regular DSL (200-400 ms for UMTS, even more for GPRS). This of course makes them unsuitable for many applications, such as VoIP and teleconferencing.

  • Where does this latency come from?
  • Are there any technologies available that can mitigate this problem, to make UMTS viable for low-latency applications?

I assume there must be some inherent technical reason, but what is it? Does it have to do with how data is transmitted over the air? And if it is because of the wireless transmission, why does WLAN have much lower latencies?

share|improve this question
Belongs on ;-) – ceejayoz May 9 '12 at 20:26
mobile device type, cell tower location, barriers to signal, etc – DanBig May 9 '12 at 20:27
@ceejayoz: Yes, I realize this may be borderline off-topic. Still, it is a networking question - and is still in private beta ;-). – sleske May 9 '12 at 20:28
This question is not suitable for superuser. It belongs here. – resmon6 May 9 '12 at 20:33
They'll get over it. As a network engineer I look forward to seeing a thoughtful answer to this question. – resmon6 May 9 '12 at 20:35

4 Answers 4

I'm sorry to get here so late, but there is a book from Ilya Grigorik called "High Performance Browser Networking" that answers exactly this. There is a whole chapter (7th) dedicated to mobile networks. The book states that the problem with high performance is almost always tied to latency, we usually have plenty of bandwidth but the protocols gets in the way. Be it TCP slow start, the Radio Resource Controller or suboptimal configurations. If you are experiencing poor latency only in mobile networks it's the way they are designed.

There is a table in the book about typical latencies:

Table 7-2. Data rates and latency for an active mobile connection

Generation | Data rate      | Latency
2G         | 100–400 Kbit/s | 300–1000 ms
3G         | 0.5–5 Mbit/s   | 100–500 ms
4G         | 1–50 Mbit/s    | < 100 ms

Although very relevant to latency the TCP characteristic three-way handshake or the slow-start doesn't really answers the question, as they affect the same way in a home connection (wired vs. mobile). What does really affect the latency in mobile networks is the layer under IP, if the layer under IP has a latency of half a second, a TCP connection to a server will take ~1.5 sec (0.5s*3), as you see the numbers add up pretty quick. As said before that's supposing that the mobile is not idle, if the handset is idle it first has to "connect" to the network, that requires to negotiate a reserve of resources with the tower (simplified), and that takes between 50-100ms in LTE, up to several seconds in 3G, and more in earlier networks.

Figure 7-12. LTE request flow latencies

  1. Control-plane latency: Fixed, one-time latency cost incurred for RRC negotiation and state transitions: <100 ms for idle to active, and <50 ms for dormant to active.
  2. User-plane latency: Fixed cost for every application packet transferred between the device and the radio tower: <5 ms.
  3. Core network latency: Carrier dependent cost for transporting the packet from the radio tower to the packet gateway: in practice, 30–100 ms.
  4. Internet routing latency: Variable latency cost between the carrier’s packet gateway and the destination address on the public Internet.

In practice, the end-to-end latency of many deployed 4G networks tends to be in the 30–100 ms range once the device is in a connected state.

So, you have for one request (Figure 8-2. Components of a "simple" HTTP request):

  1. RRC negotiation 50-2500 ms
  2. DNS lookup 1 RTT
  3. TCP handshake 1 RTT (preexisting connection) or 3 RTT (new connection)
  4. TLS handshake 1-2 RTTs
  5. HTTP request 1-n RTTs

And with real data:

Table 8-1. Latency overhead of a single HTTP request

                       | 3G           | 4G
Control plane          | 200–2,500 ms | 50–100 ms
DNS lookup             | 200 ms       | 100 ms
TCP handshake          | 200 ms       | 100 ms
TLS handshake          | 200–400 ms   | 100–200 ms
HTTP request           | 200 ms       | 100 ms
Total latency overhead | 200–3500 ms  | 100–600 ms

In addition if you have a interactive application that you want to perform moderately ok in a mobile network you can experiment disabling the Nagle algorithm (the kernel waits for data to coalescence into bigger packets instead of sending multiple smaller packets) look for ways to test it in

There is the option to read the entire book for free by everyone at sponsored by Velocity Conference. This is a very highly recommended book, not only to people developing websites, it is useful to everyone who does serve bytes over some network to a client.

share|improve this answer
Thanks for the information, very interesting. Since not everyone can read the book (and since answers should stand on their own): Could you explain a bit more how TCP slow start, radio controllers and configuration contribute to latency? – sleske Feb 7 '14 at 9:41
I have just edited the answer with fragments and tables of the book so it's useful on its own. – Jorge Nerín Feb 8 '14 at 15:18
Note to self: Another interesting paper on latency: Latency in HSPA Data Networks, Qualcomm. – sleske Feb 10 '14 at 8:47
Thank you SO much. I'm trying to explain to my boss why we're having trouble with latency over 3G modems for remotely deployed kiosks, and this knocked it out of the park. – jklemmack Apr 16 '14 at 16:18

I suspect that a large proportion of the latency you may experience when using "cellular broadband" technologies is a compound issue of a number of things.

There's distance, but as syneticon-dj's mentioned, that's realistically only a very small proportion of the round-trip time.

Here's something to consider... The delays you experience as a customer (especially as a home, or small business customer) are probably artificially induced, at least to some extent. There is a class of 3G and GSM communications for M2M utilisation, for SCADA and so on, which sometimes can provide a greater reliability and lower latency transmission. As a result, they're usually prohibitively expensive.

So basically, you're up against traffic shaping. Either the ISP/Telco is doing it to prioritise better paying customers, or the cell you're connected to is a bit busy, or their entire network is a little bit sluggish (try 00:00 GMT on 1/1/2012, for example).

But there is a way around all of this, it's a bit sneaky though. You'd basically need a TCP connection proxy before your traffic heads out over the mobile WWAN. This proxy would essentially send a spoofed ACK to your application, as the real ACK might be delayed by the ISP's traffic shaping.
It's distinctly dubious, but a number of satellite providers use this mechanism to make the latency seem lower than it actually is.

share|improve this answer
The tcp proxy is an interesting idea, and will help TCP make better use of the available bandwidth. However, it doesn't really help with the type of application the OP asks about. The latency in the connection is user-visible. I think you could probably use Phoebus: as such a TCP proxy. – Dan Pritts Feb 6 '14 at 17:03

Cell phone modem technologies suffer from high latency due to the nature of open-air communications: WLAN transmission distances are typically much shorter than that of the other technologies you mentioned, hence this is one reason the latency is lower.

share|improve this answer
Distance is really of minor concern here. The radio wave propagation velocity in air is pretty near to the light speed in vaccuum (about 300.000 km/s) so even a distance of 3 km would account for merely 0.02 ms of round-trip delay. – the-wabbit May 10 '12 at 12:13
@syneticon-dj You're partly correct in that tound-trip to the tower is only a (very small fraction) of the delay in cellular networks. There is also transmission redundancy (the radio link is never perfect in the real world and error correction is inherently delay-inducing), backhaul to the telco CO/switching building (usually over a packet network these days, may be one or more hops), connecting you to either a voice or data link at the CO, and then presuming we're talking about data connections you're out on The Big Bad Internet with all its inherent delays. – voretaq7 May 10 '12 at 16:03
I would add collision detection / collision avoidance algorithms and current operation parameters (like a reduced transmission speed resulting in an increased bit time which should account for 1-4 ms) as well. But I do not know enough about UMTS to compose a comprehensive answer. – the-wabbit May 10 '12 at 16:09
@syneticon-dj Good points; I wrote a paper on CDMA technology but that was a long time ago! – Isaac Butt May 10 '12 at 16:42

Kind of late to the game, but you may want to check out my Performance Calendar's article about the topic:

tl;dr - a major part of mobile latency is due to unoptimized routing on the back-haul.

share|improve this answer
Interesting point. However, this explains only part of the problem. GPRS typically has latencies of 500-1,000ms. Latency across a continent, is typically not more than 200-300ms, so even very wasteful routing should not give you 1,000 ms. – sleske Dec 17 '12 at 16:25
@sleske I suspect that with GPRS (and other old technologies) you are hitting a bandwidth bottleneck. You can cram so many packets in 56kb/s (max) before they start to queue (maybe I'm wrong - but doesn't 56kb/s means about four 1500 bytes frames per second?). – r0u1i Dec 18 '12 at 18:30
Backhaul is not the answer. At least from a Metro standpoint. SLA's require backhaul traffic on Carrier ethernet everywhere I've been to be in the 8-12ms range, tower to MSC/MTSO. How the Cell carrier routes traffic from there onto the Backbone is their business, but shouldn't be any different than normal ISP/non-cellular traffic. – user155764 Jan 23 '13 at 18:48

Your Answer


