Pages

Pages

Tuesday, July 29, 2008

Latency in mobile - more needs to be done

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.

6 comments:

  1. Anonymous11:15 pm

    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.

    ReplyDelete
  2. Anonymous1:19 pm

    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.

    ReplyDelete
  3. 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.

    ReplyDelete
  4. Anonymous5:15 pm

    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.

    ReplyDelete
  5. Anonymous3:43 pm

    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.

    ReplyDelete
  6. Anonymous3:55 pm

    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.

    ReplyDelete