When most people refer to latency in mobile networks, they are talking about the inherent lag in traffic going through the network, which includes aspects like buffering of traffic in the various nodes like base stations and controllers, as well as any processing in the network core and the handset itself.
There will always be a trade-off between latency and spectral efficiency, because the best compression algorithms have to wait for enough inbound data to arrive before processing it and crunching it down in size. Error correction also plays a part here.
All this is well-known, and the subject of focus in the industry. Recent generations of technology like HSPA have improved latency considerably.
However, there is a second class of latency which often gets overlooked. It is initial call-setup time, or initial data connection time. I'm old enough to remember when the PSTN network was digitalised - and how miraculous it seemed that a call recipient's phone started ringing as soon as you pressed the last digit on your own handset. Yet in mobile, we're still stuck with the type-in-numbers-then-hit-send mentality. We still have to wait for 5, 10, even 20 seconds before the call connects.
And it's the same for data too. What's called the "wake-from-idle" time on the current generation of HSDPA phones and modems is frequently dreadful (although this is also down to how the network is configured). The "idle mode" is used to conserve power, but it's a trade-off against good user experience. The first time I use the browser on a phone during a day (or worse, after I emerge from a tube station) it takes an age to connect, then display a downloaded page. Same thing after the network drops into idle mode during occasional use - it's a noticeable lag compared with a PC. Both connection time to WiFi/broadband, and response time when you go to a web page, are much faster in most circumstances.
HSPA Evolved (aka HSPA+) should help with the data wake-from-idle. But in the meantime, referring to HSPA as always-on is a misnomer. I also suspect that the whole idle/active state thing probably fits very poorly with always-on apps like many background services, presence, AJAX web pages and the like. As usual, there's been a disconnect between the network side of mobile innovation and application/user-behaviour aspects.
Yes, it's only a few seconds, but it's this type of thing that will lead to niggling customer dissatisfaction with mobile broadband compared to fixed connections. If you're used to instantaneous DSL or cable - or better still, ethernet in a school or workplace - then that extra bit of initial latency could have a disproportionate effect on overall quality of experience.
On the voice call set-up time, I'm not sure what the answer is, because I suspect that much of the problem is in the telephony application and signalling, rather than the network. It strikes me that this could well be a killer differentiator for VoIP in mobile - either operator-based or independent. It seems strange now, but I remember well just how different and better phone calls became with instant connection. Never mind price, or fancy voice mashups - maybe wVoIP companies should think about a really obvious and tangible benefit to end users - not wasting 10 seconds of your life every time you make a call.
"Instantaneous" has a lot of value. The mobile industry should focus on it more.