4G/LTE - WiFi Offload





WiFi OffLoad


WiFi OffLoad means a kind of handover (or selection/reselection) technology between Non-WiFi network and WiFi Network. It is not a new concept, but it has become hot issue recently especially after LTE network is wide spread. So when we say WiFi Offloading, it usually mean that WiFi Offload (handover) between LTE network and WiFi network.


Followings are the list of topics that will be discussed in this page. I will describe these topic at very high level as an introduction. I would write separate pages depending on the subject.




WiFi Offload Protocol Related Notes


Followings are WiFi Offload Protocol Related pages on sharetechnote. Thease are mainly for the initial procedure of the offloading happening right before data traffic starts. Actually these initial procedure is the important topics you need to understand and the procedure for real data traffic is not special for WiFi Offload. For example, if the WiFi Offloading happens for Voice call, only the initial procedure (i.e, Handover process) is specifically designed for WiF offloading. Once the handover protocol is completed, the data protocol is same as regular IMS protocol.




Who is triggering the offload ?


Just from the user's point of view, we can think of several user model as described below.


< Case 1 > UE-Initiated WiFi OffLoading

    i) UE is in connected mode with LTE network while there is no WiFi Network Available.

    ii) UE start seeing WiFi signal.

    iii) User switch the connection from LTE to WiFi Network.

Note : I should say this is over-simplified description. You may have a lot of questions boggling in your mind. In what criteria, user decided to switch from LTE to WiFi ? You said 'Switch the connection to WiFi ?'. Exactly what do you mean by 'Switching' ? What is the exact mechanism ? etc. I will get back to these question later.. for now, just get the big picture.



< Case 2 > Network-Initiated WiFi OffLoading

    i) UE is in connected mode with LTE network while there is no WiFi Network Available.

    ii) UE start seeing WiFi signal.

    iii) Network tells UE to switch the connection from LTE to WiFi Network.

Note : I should this is over simplified description as well. You would have a lot of questions for this as well. How network knows that UE is seeing WiFi Signal ? How network notify UE to switch to WiFi ? etc.


Now let's think about business issues... about money. What is the motivation to go for WiFi offloading?


What would be your motivation to Switch your communication channel from LTE to WiFi while you are in connection?


For mobile phone user it may help him to get access to wider bandwith and probably in lower cost or free

For mobile network operators it would help reduce the load on the LTE network by offloading the subscriber to WiFi network


Then you may ask "What about the money for the network operator? " they may not be able to charge for WiFi network usage as much as for LTE network but they may be able to get some gain from load balancing and still keep some portions of the money from the mobile user by directing to switch to the WiFi network serviced by the mobile network operator (not free WiFi)


This is just tip of WiFi Offload and I will keep updating this page as I have further chance.

If you are eager to know the details before I update, I would recommend following documents.

  • 3GPP TR 22.934 Feasibility study on 3GPP system to Wireless Local Area Network (WLAN) interworking
  • 3GPP TS 23.261 IP flow mobility and seamless Wireless - Local Area Network (WLAN) offload;Stage 2
  • 3GPP TS 23.402 Architecture enhancements for non-3GPP accesses
  • 3GPP TS 33.402 3GPP System Architecture Evolution (SAE);Security aspects of non-3GPP accesses




Overall Network Arichitecture for WiFi Offload


Now let's get just a little bit deeper into WiFi Offload mechanism. The first thing you need to understand is overall network architecture related to WiFi Offload. You would see various network architecture depending various use model.


Following is the architecture showing the combination of following figures in 23.402.

  • Figure 4.2.2-1: Non-Roaming Architecture within EPS using S5, S2a, S2b
  • Figure 4.2.3-3: Roaming Architecture for EPS using S8 S2c - Home Routed
  • Figure 4.2.3-4: Roaming Architecture for EPS using S5, S2a, S2b Local Breakout


Most of the components are the ones that you are already familiar with normal LTE/IMS operation. The component and interfaces that you need to pay attention for WiFi Offload would be as follows : (Don't try to memorize it.. just try to follow the path with pen whenever you are studing any specific use case).

  • Untrusted Non-3GPP IP
  • Trusted Non-3GPP IP
  • ePDG
  • 3GPP AAA Server
  • SWu, SWn,Swa,SWm,STa,S2c,S2a,S2b



Now let's think of how WiFi network get anchored to 3GPP network (e.g, LTE network). There are a couple of different ways to do it but if I am allowed for another oversimplifcation, it can be only two categories. One is through 'Trusted Access Point' and the other one is through 'Non-Trusted Access Point'. You can think of 'Trusted' as that the WiFi Security is protected by the 3GPP network, so you would not need any separate authentication process between 3GPP and Non-3GPP Network (WiFi). 'Non-Trusted' means that the WiFi Security is not protected by the 3GPP network, so you need to go through separate authentication process between 3GPP and Non-3GPP Network (WiFi)



'Trusted vs Untrusted' Access


If you see the network structure for Non-3GPP Access, you would see two different path. One is through 'Trusted' path and the other one is through 'Untrusted' path.


What does it mean by 'Trusted' ? Who trust who ?

'Trust' in this case is that 'Operator TRUST the access(path)'. It doesn't necessarily mean (may or may not mean) 'UE trust the path'.

The biggest difference between trusted access and untrusted access would be the requirement of authentication requirement.


In trusted access, UE would not need any separate authentication/security process when it switches from 3GPP access to non-3GPP access (WiFi) since UE already has gone through this process when it was camping on the 3GPP access and network trust the process and assume that the non-3GPP access can be protected by the same security procedure. In this access, it is highly likely that Network Operator distribute their own WiFi Access points and let UE get access through those Access Point.


On the other hand, in Untrusted access, network would require UE to go through additional authentication/security process when UE switches to non-3GPP access and use special IP tunneling mechanism (e.g, IPSec) for data transaction. In most of this case, UE would get WiFi access via public WiFi access point and those access points would be anchored to ePDG.



ANDSF, what is it ? why we need it ?


ANDSF stands for 'Access Network Discovery and Selection Function'. This is a set of services that would answer to following questions.

  • I am at such and such location now, which network (3GPP or Non-3GPP) are available for me ?
  • Now my mobile phone detected 3GPP network and WiFi network, which network I have to get access to ?



Session Mobility


Mobility is a mechanism of switching between 3GPP (e.g LTE) and non-3GPP (e.g, WiFi) networks. Largely there are two methods you can think of, NBM (Network Based Mobility - Network Initiated) and HBM(Host Based Mobility - UE Initiated)



Interplay between ANDSF and Mobility





Interplay between UE and ANDSF





What kind of Information are provided by ANDSF


It provides huge set of information. so it is hard to describe everything in this section. You can get the full sets of information about this in 3GPP as summarized below


The specification that I referred to is ETSI TS 124 312 V11.6.0 (2013-04). Since this is relatively early stage, it is highly likely that new items or revision will be added as it goes to new version. Try following up the latest specification as it roll out.


Figure 4.2.1~Figure 4.2.8 : Tree diagram of MO ANDSF information

Annex A (informative): an example of minimum set of ANDSF MO DDF



Typical Traffic Flow via 'Untrusted Non-3GPP Access'


One of the 'Untrusted' access that attracts the widest attention as of this writing (Feb 2014) is through ePDG as shown below. Overall procedure and data path are as follows.

    i) UE is in 3GPP network (e.g, LTE)

    ii) UE is triggered to switch to WiFi network

    iii) UE switches to WiFi network and goes to authentication server first  (follow the red line)

    iv) After completing the authentication process, start user data transaction through the green path.

Most important step in this traffic flow is Authentication and Security Association step at the initial step where UE start communicating with 3GPP network over Non-3GPP Access (e.g, WiFi Access Point). This initial step is described in detail in IKE based 3GPP 33.402 section.



Following is one example of WiFi Offloading From LTE network to WiFi Network. In terms of protocol implementation on UE and Test equipment side in early phase of testing (As of Jun 2014), the colored part has become the major target of validation. According to my experience on testing, step 4 and step 8 is the most tricky step to come over. Especially, passing step 4 (IKEv2) is the most difficult part to step over.



< Handover from LTE to WiFi >


Following diagram shows overall procedure for the case where UE start communication from LTE and switch to WiFi Network (Untrusted Non-3GPP). This case assumes that UE is connected to LTE before the switch (Handover) and not connected in WiFi. If UE is already connected both to LTE and WiFi before this handover, it will skip the step 2~9 and directly jump to step 10.


< 3GPP 23.402 Figure 8.2.3-1: Handover from 3GPP Access to Untrusted Non-3GPP IP Access with PMIPv6 on S2b >


Step 1 : UE is initially attached to LTE network. (In the most of testing situation with test equipment, WiFi on UE turned off at this stage).


Step 2 : (In the most of testing situation with test equipment, we turn on WiFi on UE at this time). UE start detecting WiFi network and initiate switching process to WiFi network.


Step 3 : (This may be an optional step) UE and EPC perform Access authentication process. => This corresponds to 33.402 6 Authentication and key agreement procedures


Step 4 : UE and ePDG performs IKEv2 tunnel establishment procedure. (See the details in IKE page or 3GPP 33.402). Following is the decription for this step in 23.402 and I add some comments to relate 23.402 and 33.402.

  • The IKEv2 tunnel establishment procedure is started by the UE. The ePDG IP address to which the UE needs to form IPsec tunnel with is discovered as specified in clause 4.5.4.
  • After the UE is authenticated, UE is also authorized for access to the APN. The procedure is as described in TS 33.234.
  • As part of access authentication the PDN GW identity is sent to the ePDG by the 3GPP AAA server. => This corresponds to step 5 of 33.402 Figure 8.2.2-1
  • If the UE supports IP address preservation during handover from 3GPP Access to the untrusted non-3GPP IP access, the UE shall include its address (IPv4 address or IPv6 prefix /address or both) allocated when it's attached to 3GPP Access into the CFG_Request sent to the ePDG during IKEv2 message exchange. => This corresponds to step 2 of 33.402 Figure 8.2.2-1


Step 5 : ePDG sends the Proxy Binding Update message to PDN GW. Followings are conveyed in this message

    • MN-NAI
    • Lifetime
    • Access Technology Type
    • Handover Type Indicator
    • GRE key for downlink traffic
    • UE Address Info

Step 6B : PDN GW and AAA Server performs the following transaction.

  • PDN GW sends following information to AAA Server 
    • PDN GW Identity
    • APN corresponding to the UE's PDN Connection
  • AAA Server sends Authorization information to PDN GW

Step 7 : PDN GW processes the Proxy Binding Update from ePDG and update the binding cache entry for the UE. and then sends Proxy Binding Acknowledgement message. This message carries following information.

    • MN-NAI
    • Lifetime
    • GRE key for uplink traffic
    • UE Address Info
    • Charging ID


Step 8 : ePDG and UE continues the IKEv2 exchange and IP address configuration => This corresponds to step 15 of 33.402 Figure 8.2.2-1


Step 9 : End of the Handover procedure. At this step, we would have two IP tunnels as follows

  • IP sec tunnel between UE and ePDG
  • PMIPv6 tunnel between ePDG and PDN GW


Step 10 : This is for the case for connectivity to multiple PDNs. UE establishes connectivity to each PDN that is being transferred from 3GPP access.


Step 11 : Disconnect LTE EPS Bearer.

PDN GW shall initiate the PDN GW Initiated PDN Disconnection procedure or PDN GW Initiated PDN Deactivation procedure (3GPP 23.401)