Pages

Pages

Tuesday, March 30, 2010

LTE and offload - a few random questions

A quick series of observations:

1) It is highly likely that LTE will have to be provided (at least in part) by femtocells and/or WiFi access points, rather than being solely transmitted via the macro network. This will be for coverage reasons, especially for 2.6GHz, but also because of the limits of capacity which will be quickly reached in some areas.

2) Given rising traffic volumes, there will also be a strong desire to offload bulk IP traffic direct to the Internet close to the edge of the network, rather than backhauling it all through to the operator core & then out again

3) Voice will in some packetised form on LTE, whether it's VoLTE or VoLGA or Skype or CSFB.

So... there will need to be a mechanism to send VoIP to the operator core, but dump bulk web traffic locally. I guess that could be achieved by using separate APNs (or whatever they're called in LTE-speak).

Or, will it need the new "Selective IP Traffic Offload" standard being worked on by 3GPP?

Or, could you use some sort of dual-radio solution in handsets, sending certain traffic over the macro LTE network (or HSPA), while sending low-value data via WiFi / femto?

Separately... presumably this also means than any VoIP that *does* go via an offload path (femto / WiFi) will need to be tunnelled back to the operator core via some sort of VPN.

So potentially we may see some LTE phones using CS-Fallback over a GAN-type tunnel.....

4 comments:

  1. isn't the latter exactly what VoLGA is all about?

    ReplyDelete
  2. Barney6:54 pm

    Voice will in some packetised form on LTE, whether it's ... or Skype ... so... there will need to be a mechanism to send VoIP to the operator core.....

    As 'Skype' scales precisely because its peer-peer, why does it have to go to an operator 'core'?

    ReplyDelete
  3. I'd rather say it is highly likely that LTE will have to be provided at least in part by pico cells. I use pico here to indicate the eNB is fully owned and operated by an operator. Femto with LTE could happen, but I wonder if fibre to the home is required before LTE femto brings any benefit over 3G femto. But most confused I'm with your proposal to "provide LTE by WiFi access points". Please elaborate.

    Voice for sure will be in some packetised form on LTE. But, CSFB is not packetised. And I don't understand what could be the reason to combine CSFB and GAN-type tunnel?

    You propose high value packet data to be sent over macro network and low value over WiFi/femto. What in your mind are the characteristics of high value packet data vs. low value packet data? How would you differentiate between the two? Or, are you saying that only voice traffic is high value and all other data low value? Do you consider 'bulk web traffic' to be low value in relative or absolute terms?

    As before, I work for Nokia and the opinions above are mine.

    ReplyDelete
  4. OK, some clarifications, having read through the original post.

    I meant that some notional LTE services will likely be *offloaded* to WiFi access.

    I would classify "high value" data as being:
    - voice
    - operator messaging
    - operator "managed services" such as their own appstore downloads or multimedia content
    - partner content / apps which are QoS-guaranteed or otherwise optimised
    - meta-data about offloaded traffic which might be important for customer databases, policy etc
    - signalling (eg reporting on local radio network conditions)
    - device management traffic

    "Low-value" would be the majority of public web and email, 3rd-party streaming video, data from non-operator applications and so forth.

    Re: Skype traffic, it may depend if it's "open Internet Skype", or some form of operator/Skype partnered service. I can see a scenario in which an operator either co-brands or white-labels Skype as its LTE voice service, especially if they don't want IMS. In that scenario, they may want to backhaul it / partly-control it more.

    CSFB *will* be packetised if it's offloaded to a dual-mode 3G/LTE femtocell, as the 3G femto itself will need to set up an IPsec tunnel back to the gateway. The point here is that the femto/gateway IuH standard is essentially a variant of GAN.

    If it's still on the macro network, it will obviously remain as CS throughout.

    Dean

    ReplyDelete