Data Offload

Use Case

AWTG Limited
7th Floor, Westgate House, Westgate Road,
London, W5 1YY.
Tel. 0208 799 0368, Fax. 0208 728 9610

www.awtg.co.uk

Copyright AWTG Ltd Page 0 of 7 August 2013

Document V 1.13 Use Case: Data Offload
Contents

Executive Summary ..................................................................................................................................... 2

Introduction ................................................................................................................................................. 2

Use Case ...................................................................................................................................................... 3

Objective & Scope of Work .....................................................................................................................3
Demonstration and Results .....................................................................................................................4
Step 1: 3G connectivity- EAP/AKA authentication: .............................................................................4
Step 2: WiFi connectivity- EAP/AKA and EAP-SIM authentication......................................................5
Step 3: 3G to WiFi handover, EAP-AKA authentication ......................................................................6
Step 4: WiFi to 3G handover, EAP-AKA authentication ......................................................................6

Conclusion ................................................................................................................................................... 7

Future work ................................................................................................................................................. 7

References ................................................................................................................................................... 7

Copyright AWTG Ltd Page 1 of 7 August 2013

Document V 1.13 Use Case: Data Offload
 Data Offload
Executive Summary
WiFi enabled Smartphones, Tablets and Mobile Broadband
enabled Laptops have led to an increased appetite for
mobile data bandwidth hungry applications. Many of today’s
devices are dual mode, for example a 3G/LTE handset often
has a WiFi chipset onboard. With the amount of cellular
traffic being consumed by these Smart devices set to
increase further, mobile operators are increasingly turning
to WiFi as a complementary technology to work alongside
traditional mobile access technologies.
Figure 1. Wireless data traffic generated of out of home and place of work
by network type, developed markets
(Source :Analysis Manson 2013)
With the rise in number of Carrier-class WiFi networks and
the uptake of WiFi by mobile carriers as shown in Figure 1, it
becomes extremely important to ensure that end user
experience is not degraded when a mobile handset switches
between access technologies.
AWTG has carried out a 3G data offloading demonstration
under lab conditions to study the results and challenges of
seamless offloading, the demonstration was defined based
on real life scenarios and used industrial standards as a
basis. The network design and topology was based on Cisco
and Ericsson solutions.
Introduction
During recent years, WiFi enabled Smart phones and Mobile
Broadband enabled laptops have increased the data usage
demand from bandwidth-hungry, real-time streaming video
and data applications. This unexpected demand has
increased the operator’s network usage exponentially as
shown in figure 2 whilst the operator’s network was not fully
ready to support the amount of requested data.
Copyright AWTG Ltd
Document V 1.13
Use Case
Figure 2. Global Handset Data Traffic
One of the available options for operators to answer the
data hungry users is to offload 3G data to WiFi networks.
There are different approaches for mobile operators to
offload data onto WiFi and these approaches differ based on
the level of integration of WiFi into the mobile core network,
each approach gives the operator different levels of control
over the subscriber.
In the integrated model proposed by 3GPP, WiFi is inter-
networked with the core mobile network through a bridge
for controlling and managing the mobile data offloading. In
this approach, operators can seamlessly move the mobile
device from the cellular network to the WiFi network and
seamlessly transfer the data through WiFi. However, this
approach adds more complexity to the 3G/4G core network
architecture in terms of mobile and WiFi network integration
challenges. The offloading solution may also require access
layer applications to be installed on handsets to make this
technology available to more customers.
There are already handsets on the market which can use 3G
offloading solutions without additional applications on the
client side, this can help operators connect these clients to
their WiFi network seamlessly and offload data traffic to the
WiFi. This model is called clientless offload solution.
Clientless offload solutions provide operators with relatively
quick solutions with low cost to their capacity issue by
having solutions without heavy investment in complex
integration level issues. Another advantage of this approach
is that it does not require any special application running on
the mobile devices to enable operators to define and enable
QoS, security policies and accounting services.
Page 2 of 7 August 2013
Use Case: Data Offload
Use Case
Objective & Scope of Work
Data traffic has increased significantly on today’s 3G
network, this situation is not only creating the problem but
also creating an opportunity for carriers. Providers are
focusing on WiFi networks and using 3G data offloading
solutions. 3G data offloading has numerous challenges.
The demonstration has been defined to simulate a 3G data
offloading solution based on the combination of Cisco (WiFi
AP and ASR5K used as Gateway) and Ericsson (SGSN, HLR)
hardware as shown in figure 3. The detailed scope of work
for this document includes user authentication, testing both
trusted and untrusted WiFi, clientless and client based and
also seamless mobility for real time applications.
Figure 3. Demonstration Topology
User authentication is an important aspect in 3G data
offloading, in the demonstration we capture and verify the
message flows for authentication and mobility between 3G
and WiFi networks.
Untrusted WiFi networks were introduced in the early phase
of WiFi specification in 3GPP release 6, access to these
networks includes any type of WiFi access that is not
controlled by the operator. Another scenario for untrusted
access could be that the network might be under control of
the operator but does not present a satisfactory level of
security. Examples of Untrusted Access are Home WLAN and
publically open hotspots.
Trusted IP Access was introduced only with the LTE model in
3GPP release 8. Trusted WiFi Access refers to provider or
mobile operator owned or controlled WiFi access providing
over the air encryption and secure authentication methods.
Mobile operators are not only focusing on deploying their
own WiFi networks but also willing to expand their WiFi
access via untrusted networks. In this demonstration we
have set up the solution for both trusted and untrusted WiFi
access and tested both clientless and client based solutions.
Copyright AWTG Ltd Page 3 of 7
Document V 1.13
There are various ways to authenticate and manage
subscriber access to WiFi networks. Transparency in the
authentication method could affect the subscriber
confidence in the network, the more transparent the
authentication method, the larger the probability that the
subscriber will connect to the network. There are two
different authentication methods, portal based
authentication and EAP authentication. Portal based
authentication is a complicated method which requires HTTP
and layer-3 connectivity before the authentication process
starts. The alternative way is EAP authentication which
provides easy and transparent access. In this demonstration
we simulate EAP authentication. EAP-AKA (EAP
Authentication and Key Agreement) and EAP-SIM are two
different standards used for the encapsulation, we test both
EAP-AKA and EAP-SIM authentication with a WiFi Network.
Another crucial challenge in 3G data offloading is the
behaviour of near real time applications such as YouTube,
FTP and real time applications such as VoIP and VPN during
handover between 3G and WiFi, we go further and test
seamless mobility for these near real time applications and
Real Time applications for mobility between 3G and WiFi.
Based on the defined scope of work we have set the
objectives of the demonstration and track the results and
also ensure that the chosen architecture and message flows
to authenticate (using EAP-SIM and EAP-AKA) between the
Mobile Packet Core and the WiFi Core are inline with the
scope.
We analyze a clientless solution to monitor its limitations in
seamless mobility and then prove functions of a client based
solution for seamless mobility.
Various test scenarios are run to show that there is no
impairment in user experience when the user moves
between WiFi and the 3G Packet Core. The network used for
the 3G offload solution simulation has been illustrated as
below:
Figure 4. Network layout used for the 3G offload simulation
August 2013
Use Case: Data Offload
Lab Setup
This section describes the devices, applications and
protocols we have used to simulate 3G data offloading.
 Cisco Access Point
 Wireless LAN Controller
 Cisco ASR5K used as Gateway
 Ericsson SGSN
 Ericsson HLR
 GTP and Mobile IP protocols are used to maintain the
IP address for UE when moving between technologies
 Both Trusted (VF-X1-TEST) and Untrusted WiFi (VF-X1-
TTG) SSIDs configured in the lab WiFi network
 Four Samsung phones (UE) are used in this testing with
SIM IDs of 311480000000226, 259, 260 and 267. These
are configured on both 3G and WiFi core so that
interworking can be tested.
 Third-Party client is used to test client based solution
for seamless mobility.
Test Execution Methodology
To simulate 3G data offloading and the scenarios that we
have discussed in this document, we have executed
following test plan.
To simulate the scenario we first turned off both WiFi and
3G on the UE and then whilst the WiFi was off we turned on
3G connectivity. Once the UE successfully connected to 3G
we verified the IP address allocated to the UE from the
GGSN/HA pool. After verification that the UE is connected to
3G we started an application under test for mobility from 3G
to WiFi. While the application was running we turned on
WiFi and verified that UE was connected to the WiFi network
and received the IP allocated to the UE from the client pool
and also that the application was not disrupted. We turned
off the WiFi to move back to 3G and again confirmed the IP
address allocation and checked the application status and
confirmed that the application was not disrupted at this
stage.
To summarise, the following steps were completed during
the procedure:
 Turn off WiFi, attach the UE to the 3G network and
start an application under test for mobility
 Check the IP address allocated to the UE from the
GGSN/HA pool
 Turn on the WiFi and see that another IP address is
allocated to the UE from the client pool
 Check that the application is not disrupted
 Move back to 3G and check that the earlier IP
addresses are maintained and the application
session is not disrupted
Copyright AWTG Ltd Page 4 of 7
Document V 1.13
Demonstration and Results
The demonstration has been divided into four main
steps as below:
Step 1: 3G connectivity- EAP/AKA authentication:
After setting up our lab we verified the 3G connectivity. We
have the 3G network setup in the lab and verified
connectivity by switching on the UE to get the coverage and
network related configurations from the core network to
establish the connection with the GGSN.
Pre-Conditions
Before we set up 3G connectivity we have to verify some
settings which should be present in the UE. The APN for
vzwinternet-wifi was configured on the Samsung Galaxy 3
phone with a 226 SIM. The SIM was also configured for EAP-
AKA authentication. The 3G connectivity test was an
important prerequisite for the 3G to WiFi offloading test.
Execution Steps
Ensuring that there is no data connection present at the UE,
we monitored the activity on the GGSN to confirm that we
are not receiving any PDP context requests. Then we
switched on the 3G data connection and checked to see if
the phone connects to the 3G UMTS network
Results
The 3G connectivity flow was as expected, Ericsson’s SGSN
received the data connectivity request and the SGSN
communicated with the HLR to authenticate the subscribers
from a 3G perspective. Once authentication was completed,
the SGSN initiated a PDP context request to the ASR5K GGSN
and in turn the GGSN accepted the request and sent PDP
context response. The UE was assigned an address from the
GGSN pool between (192.168.20.192 - 222) stating IUCNAI
for UMTS. We verified the address allocation on the ASR5k
by issuing a "show subs all” command. This info was stored
in a log file for all the test cases.
Figure 5. UE assigned IP Address
Call flows were verified using Wireshark traces stored during
testing, as seen in figure 6 the successful RANAP attach and
PDP context activation message goes to Cisco GGSN using
GTP control messages.
August 2013
Use Case: Data Offload
 Figure 6. Wireshark Trace for PDP context request and response

Step 2: WiFi connectivity- EAP/AKA and EAP-SIM Results:

authentication
Following on from the testing of 3G connectivity, we test
WiFi connectivity. To simulate WiFi connectivity on the UE
the WiFi network was switched on and the connection from
UE to GGSN was traced and monitored.
The connection was established after EAP authentication
and IP addresses assigned from the client pool to the mobile
wireless interface as can be seen in figure below.

Figure 7. Wireshark Trace showing connection established and IP addresses assigned from the pool

Copyright AWTG Ltd Page 5 of 7 August 2013

Document V 1.11 Use Case: Data Offload
Step 3: 3G to WiFi handover, EAP-AKA authentication
During this step the EAP-AKA authentication flow for 3G to
WiFi handover was captured. To observe the impact on data
services on the UE and also observe the packet flow of 3G to
WiFi offloading we took following steps:

 Connect to 3G network
 Monitor EAP-AKA authentication
 Start ICMP traffic
 Switch on the WiFi
 Monitor WiFi Authentication
 Monitor effect on ICMP traffic

Results:
As expected, when we switched on the WiFi after initiating
ICMP traffic while the 3G connection was established, the UE
connects to WiFi by going through EAP-AKA authentication
in the WiFi core. A GTP tunnel is established between the
eWAG and the Cisco GGSN. The UE is allocated another IP
address from the client pool, we verify the address allocated
to the handset by issuing the "show subs all” command on
the ASR5K, we note that the IP addresses are maintained
from the previous addresses allocated when connected to
3G. This info is stored in the Log file for all the test cases.
During the 3G handover to WiFi we found some ICMP traffic
packets were lost. We use Wireshark traces to verify the call
flows for GTP, IP and Radius messages stored in the file
“WiFi connectivity 226”
Figure 8. Only four packets lost during 3G to WiFi handover
Step 4: WiFi to 3G handover, EAP-AKA authentication
In step 3, we monitored the packet flow and service impact
of 3G to WiFi handover. In this step we observe the
signalling flow of WiFi to 3G handover.
To test WiFi to 3G handover we take the following steps.
 Ensure handset is connected to WiFi and 3G is also
enabled.
 After verification of connectivity, verify that the
handset is receiving an IP address from WiFi client IP
Address pool.
 Initiate the ICMP traffic.
 Switch off WiFi and observed the packet flow and
impact on ICMP traffic.

Figure 9. WiFi to 3G handover flow

Copyright AWTG Ltd Page 6 of 7 August 2013

Document V 1.13 Use Case: Data Offload
Results:
Results of WiFi to 3G handover were as expected, the UE
connects to WiFi by going through EAP AKA authentication.
A GTP tunnel is set between the SGSN and the CISCO GGSN
and the UE gets another IP address from GGSN.
We verified the address allocated to the UE by checking on
GGSN and confirmed that the IP addresses are
Figure 10. Wireshark Trace showing IP addresses are maintained
Conclusion
The main aim of this demonstration was to test a 3G
offloading solution based on Cisco’s ASR5K solution in
AWTG’s lab and to study the challenges and observe the
outcomes.
AWTG’s lab setup enabled us to replicate a 3G offloading
scenario based on a multivendor network consisting of a
combination of Cisco and Ericsson hardware. During these
demonstrations we verified vendor claims and also tested
connectivity and seamless handover between two
technologies.
We demonstrate that WiFi is inter-networked with the core
mobile network through a bridge for controlling and
managing the mobile data offloading. We showed that
operators can seamlessly move the mobile device from the
cellular network to the WiFi network and seamlessly transfer
data through WiFi.
The summary to take from these demonstrations and the
related logs are:
 Successful end-to-end 3G network connectivity using
Ericsson SGSN and HLR for authentication with UE
address allocation from Cisco’s GGSN.
 Successful WiFi network connectivity and IP address
allocation using GTP and Mobile IP with Cisco GGSN/HA
/FA whilst retaining IP address from 3G for mobility.
 When users move between 3G and WiFi, the IP
addresses allocated to the handset by the network are
maintained as users move between the technologies
Copyright AWTG Ltd Page 7 of 7
Document V 1.13
maintained from the previous address allocated when
connected to 3G. This info is stored in the Log file for all the
test cases also verify the call flows in the Wireshark traces
for GTP, IP and Radius messages stored in the file. During the
handover we found a small number of packets were lost.
Only two packets were dropped during handover from WiFi
to 3G.
 The call flows on the 3G and WiFi technologies allow us
to verify our network architecture and the expected
messaging for RANAP, GTP, RADIUS and Mobile IP
protocols.
Future work
AWTG constantly investigate future technologies to help our
clients improve their offloading solutions and such we
continue to develop more use cases in our lab covering the
following bullets:
 Test untrusted WiFi offloading scenario which includes
the TTG function and a client on the UE.
 Testing offloading while reducing the power of 3G or
WiFi AP to force handover between 3G and WiFi rather
than switching on/off
 Change the timer value for IP allocation on ASR5000 to
study the impact on end user experience
 Testing trusted and untrusted scenarios with Ericsson
GGSN to simulate a multivendor offload environment.
 Implement 4G to WiFi offload and test seamless
mobility
References
http://www.prnewswire.com/news-releases/strategy-analytics-handset-
data-traffic-to-grow-over-300-by-2017-to-21-exabytes-214113401.html
August 2013
Use Case: Data Offload