Traffic Offloading: WiFi to Rescue

Last few blogs I have argued the needs for augmenting LTE with WiFi. In parallel I was trying to catch up with the progress in 3GPP with respect to traffic offloading. They have three proposals on the table:

  • Local IP Access (LIPA)
  • Selected IP Traffic Offload (SIPTO)
  • IP Flow Mobility (IFOM)

LIPA addresses the need for access to local devices (file/media servers, printers) at home or office via user devices that are typically connected to the macro network. It achieves the local traffic (break-out) connectivity with the help of a femtocell supersized to include P-GW or GGSN functionality. Following figure is from 3GPP TS 23.829.

SIPTO addresses the need to break out traffic closer to RAN but (above it). It solves congestion in operator’s packet core by placing Internet connectivity closer to RNC. This is already offered by many vendors today (including Juniper, Tellabs, Cisco). I am not convinced that it has significant value since the real congestion is in the radio, that is limited by Shannon’s law. Any current issues with core networks are temporary and will be resolved by reliance on Moore’s law. Following figure from 3GPP TS 23.829 would give an idea about what SIPTO is about.

IFOM is based upon the Dual Stack Mobile IPv6 (DSMIPv6). Furthermore it assumes user equipment can use two radios (WiFi and a macro network radio link) simultaneously. It is defined in 3GPP TS 23.261. It is what I would describe as an end-to-end solution. It is dependent on user equipment and Home Agent (HA) (typically co-located with P-GW or GGSN) intelligence. It has no bearing on radio access network. It can be equally applicable for Wimax, EV-DO, etc. Following figure is my simplification to describe it.

I believe IFOM has the highest chance of success even though the recent history of mobile IP based solutions is full of disappointments. Unfortunately mobile IP has never made into the mainstream consumer grade technology, and stayed limited to the enterprise domain. However, the last three years have significantly shifted the mobile communications industry especially with the arrival of iPhone (IOS) and Android as well as the amazing computational power in these devices. Both iPhone and Android already provide limited dual radio capability, e.g., ability to send MMS over GPRS/3G while being connected to WiFi for local access. What is missing is to enhance this capability with DSMIPv6, implement HA in the packet core and come up with smart algorithms for IP flow mobility based on quality, cost, network status, user preference, etc. DSMIPv6 solves other problems such as the introduction of IPv6 for LTE devices while WiFi radio access networks continue to stay as IPv4.

I have been looking at companies who are coming up with IPR in this field. One interesting company is SNR Labs ( based in Plano, TX. They have been working on this since 2007 and they seem to be partnering with Intel for long time.

Considering 802.21 turned out to be somewhat a disappointment, one needs to be cautious with respect to the future of this field. Probably fate of 802.21 was too closely tied to future of Wimax.

IP flow mobility using mobile IP looks more promising compared to previous attempts using mobile IP, 802.21 or LIPA, SIPTO that are dependent on femtocells. As soon as IOS and Android support for DSMIPv6 becomes available, future of traffic offload will be settled.

I published a white paper on this topic. You can download it at Scribd as well as from

This entry was posted in General and tagged , , , , , , , , , . Bookmark the permalink.

2 Responses to Traffic Offloading: WiFi to Rescue

  1. Dean Bubley says:

    The problem I see with the IFOM solution you propose is that the WiFi traffic is routed back via the operator’s core. This is one of the same flaws which killed UMA.

    At the very least, there needs to be a solution so that *some* WiFi traffic just goes straight from the access point to the public Internet, while diverting other data back to the operator’s network and billing system.

    There is absolutely no need (and quite a lot of cost) associated with trunking all WiFi traffic through a GGSN / P-GW. Apart from anything else, when end-users buy PCs or unlocked smartphones, they will set the WiFi to their own default SSID on their home broadband.

    Dean Bubley

    • wirelesse2e says:


      I agree that a local break-out solution has the advantage of steering traffic away from the operator core. As I argued in my posting, LIPA would provide this. However, the cost of this is a femtocell either the user or the operator has to pay for. I am not convinced yet that femtocells will become a large factor for traffic offload unless operators subsidize them.

      In the absence of that operator controlled intelligent device in the customer premises, only remaining choice is IFOM. It works end-to-end; no dependence on the radio access network, packet core, etc. with the exception of a Home Agent that doesn’t necessarily be co-located with GGSN and DSMIPv6 client in the handset.

      Topologically HA does not have to be too far from the customer’s premises since traffic between mobile and HA traffic doesn’t need to traverse the operator’s core or any of the packet core nodes themselves. HA gateways that can be located in mobile operator’s peering points or better in public peering locations. While this would reduce the impact you are concerned about, it will help the operator to solve regulatory items like Lawful Intercept.

      With respect to the model of using WiFi at home, as customers are doing today, I fully agree with you. That is a working model and it doesn’t need any change. However, my blog and the white paper were about traffic offloading. It is something in the interest of the operator and I believe the cost of carrying offloaded traffic back to a few HA devices is an acceptable cost as opposed to deploying millions of femtocells.

      Thanks for your comments,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s