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.
Dean Bubley's Disruptive Wireless: Thought-leading wireless industry analysis
6 comments:
Yes, there is the latency / spectral efficiency trade-offs at play here. But there is also the use cases that the standards optimized the design on. [W]CDMA was optimized for relatively long lived data transfers. The relatively high cost and latency to bring up a traffic channel didn't matter that much because lots of bits were expected to be transferred. And then it transitions into the battery saving idle mode.
But as data is getting used more, the use case assumptions aren't matching. A lot more short bursts of data. The effort and energy to bring up that traffic channel is significant. And the latency is more noticeable.
For voice calls, I don't think bringing up a traffic channel (the bulk of the delay) is going to be at all different when passing through an MSC or a GSN.
And then there is the paging of mobiles which really adds delay.
The reason the latency is poor when you
emerge from a tube station is because,
in topological terms, you are likely to
have 'warp' jumped between cell areas
(CS LA, PS RA) . This is a big thing
for the core network (no area updates
have occurred while the terminal is
idle etc) , almost akin to CS/PS attach
when you switch on a terminal for the
first time.
The move from HSPA to HSPA+ does
*nothing* for latency, for the
transition is a traffic *capacity*
increase. Latency is a network/QoS
issue.
Service re-establishment times are
governed by how quickly the radio
bearers can be re-established for a
service (for both U and C-plane) .
Service bearers between the CN/BSC,
and BSC/BS are not so much of a
problem as the bearers are either
available but idle, or temporarily
re-assigned to other services while
your services are idle.
Two years ago I was told that for
telephony services, call setup for
GSM is typically ~3 seconds. And
for UMTS the desired worst case was 5
seconds.
Thanks Mo & Anon
Call setup on GSM is c3 seconds? Maybe my network in the UK is particularly poor then.... or else there are other delays if you have to go via a number-portability server, if you're making a mobile-to-mobile call (which may terminate on 3G) and so on.
In any case, it's too long. Although that said, fixed VoIP can take a while too - Skype sometimes takes 5 sec+
Given that LTE doesn't have a voice service defined yet, maybe that would make a good point to introduce instantaneous call set-up - perhaps by preemptively setting up the call by recognising that the user is typing in a string of digits that look like a phone number, or is scrolling through the contact list on the phone.
MO Yan: ""The move from HSPA to HSPA+ does
*nothing* for latency""
On the contrary, around 40% of the latency of a PS call is related to the air interface, and this is roughly related to 4x the TTI, so for R99 this is 4x 10ms (plus processing time) and for HSPA+ this is 4x 2ms (plus processing time, so there is somewhere in the region of 30ms reduction when moving to HSPA+.
For LTE idle to active time is targetted at 50ms, so instantaneous is pretty much the right word to use.
To Paul :
"On the contrary, around 40% of the latency of a PS call is related to the air interface, and this is roughly related to 4x the TTI, so for R99 this is 4x 10ms (plus processing time) and for HSPA+ this is 4x 2ms (plus processing time, so there is somewhere in the region of 30ms reduction when moving to HSPA+."
Which has no appreciable bearing on
the overall call setup delay (the
delay budget being across both the CN,
and the RAN - the latter of which the
radio link is but one part) , or
radio bearer re-establishment (RRC
exchange etc) .
Similarly, increases in HSPA capacity
does not necessarily improve the
latency of C-plane traffic. Even for
a perfect radio link, traffic is still
subject to the HSPA schedulers.
A mediocre scheduler, coupled with the
fact that HSPA MACs are nowhere near
fully QoS-aware, means that for a
highly-loaded HSPA region you will
soon have C-plane traffic being
delayed.
Regarding call setup times :
The delay is measured from the moment
you enter the *final* digit to the time
you hear *something* (call tones etc) .
A time of 5 seconds has significance.
For example, the ITU defines mean/max
call setup times for various call
scenarios (national, inter-continental
etc) .
So UMTS vendors aiming for 5 seconds
are setting a target used in ITU
standards (I cannot recall offhand
which scenarios equate to this) .
LTE has set the challenge of 50ms
for C-plane latency. This is driven
by services such as "push to talk" ,
which already run like a beast on
radio tech like Tetra, iDEN etc.
Again, more benchmarks against which
4G tech will be judged.
Post a Comment