Data Offload. Use Case. AWTG Limited 7th Floor, Westgate House, Westgate Road, London, W5 1YY. Tel , Fax

Transcription

1 Data Offload Use Case AWTG Limited 7th Floor, Westgate House, Westgate Road, London, W5 1YY. Tel , Fax Copyright AWTG Ltd Page 0 of 7 August 2013

2 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

3 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. Data Offload 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. 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. In the integrated model proposed by 3GPP, WiFi is internetworked 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. Copyright AWTG Ltd Page 2 of 7 August 2013

4 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. 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. 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. 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 Copyright AWTG Ltd Page 3 of 7 August 2013

5 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 , 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. 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 ( ) 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. 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 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. Copyright AWTG Ltd Page 4 of 7 August 2013

6 Figure 6. Wireshark Trace for PDP context request and response Step 2: WiFi connectivity- EAP/AKA and EAP-SIM authentication Results: 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 Document V 1.11 Page 5 of 7 August 2013

7 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

8 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 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. 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 Figure 10. Wireshark Trace showing IP addresses are maintained 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 Copyright AWTG Ltd Page 7 of 7 August 2013