Network Working Group Dapeng. Liu Internet-Draft China Mobile Intended status: Informational October 13, 2012 Expires: April 16, 2013 Wi-Fi fast recovery analysis draft-liu-wifi-fast-recovery-00 Abstract Wi-Fi network has been widely deployed and used. Smart phones usually have both cellular and Wi-Fi interface. This document analysis the user experience of Wi-Fi network, especially in the scenario of smart phones/terminals that equip with both Wi-Fi and cellular interfaces. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 16, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Liu Expires April 16, 2013 [Page 1] Internet-Draft Wi-Fi user experience October 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem analysis of Wi-Fi/cellular network . . . . . . . . . . 3 3. Potential optimization . . . . . . . . . . . . . . . . . . . . 4 4. Conclution . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 7 Liu Expires April 16, 2013 [Page 2] Internet-Draft Wi-Fi user experience October 2012 1. Introduction for the smart phones and other smart terminals that equiped with both Wi-Fi and cellular network interface, there are many factors that can affect the user experience. Normally, there is no mobility support between the Wi-Fi network and the cellular network. 2. Problem analysis of Wi-Fi/cellular network Fast recovery of network connection It is a common scenario for a smart phone/smart device that originally uses the cellular network connection then offload the traffic to Wi-Fi network. In this case, it is very important for the Wi-Fi network connection can be established in a timely manner. As an example, we can consider a user is using his smartphone to watch a online video. The user use 3G network when he is in the bus. After he get off from the bus and enter his home, he prefer to use Wi-Fi over 3G, then he turn on his smart phone's Wi-Fi switch. At this moment, the following procedure would happen before he can use the Wi-Fi connection: The Wi-Fi device discover the network and select an access point to associate. Authentication: depends on the authentication mechanism the Wi-Fi network used, the Wi-Fi device finish the authentication procedure. IP address allocation and other IP layer paramters configuration. After the successful authentication, Wi-Fi network allocates an IP address for the smart phone. Along with the IP address configuration, other IP layer parameters, such as default gateway/DNS would also be configured. Note: the actual sequence of IP address configuration and authentication depends on the specific authentication mechanism being used. After the above procedure, the Wi-Fi network is ready for communiction. From the application's perspective, the IP address has been changed during this handoff, the application need to detect the IP address changing in a timely manner then re-establish the connection using he new IP address. In the above use case analysis, the crucial point is that the Wi-Fi network connection should be established in an timely manner, thence can reduce the user experience interruption. for example, when the Liu Expires April 16, 2013 [Page 3] Internet-Draft Wi-Fi user experience October 2012 user is browsing a website, after the handoff, if the brower can refresh the webpage automatically or even refreshed manually by the user, the user experience interruption would be minimized. Conversely, if the Wi-Fi network connection is not established in time, the user would see an error page after refresh the broswer. 3. Potential optimization Following t the optential optimization work that could be done in IETF: 1. Fast IP address configuration Operator deployed Wi-Fi network usually use DHCP for IPv4 address auto configuration. There is a Rapid Commit Option for DHCP that defined in RFC 4039. The following figure is the procedure of DHCP rapid commit option. Different from normall DHCP procedure, with the rapid commit option, the IPv4 address configuration will need only one roundtrip. The DHCP rapid commint option could be used for fast IP adddress configuration. Liu Expires April 16, 2013 [Page 4] Internet-Draft Wi-Fi user experience October 2012 Server Client Server (not selected) (selected) v v v | | | | Begins initialization | | | | | _____________/|\____________ | |/DHCPDISCOVER | DHCPDISCOVER \| | w/Rapid Commit| w/Rapid Commit| | | | Determines | Determines configuration | configuration | | Commits configuration | Collects replies | |\ | ____________/| | \________ | / DHCPACK | | DHCPOFFER\ |/w/Rapid Commit| | (discarded) | | | Initialization complete | | | | . . . . . . | | | | Graceful shutdown | | | | | |\_____________ | | | DHCPRELEASE \| | | | | | Discards lease | | | v v v Rapid Commit Option for DHCP Another way to improve the speed of IP address configuration is to bind the IP address configuration procedure into the 802.11 MAC layer. IEEE 802.11ai working group is currently working on this direction. The goal of 802.11ai is to achieve the "Fast Initial Link Setup". The design goal of 802.11ai is to minimize the link setup delay of 802.11 network to less than 100ms. Current link setup delay usually spend several seconds. This is not acceptable to achieve the seamless user experience during the handover from cellular network to Wi-Fi network. 802.11ai is still under development and it is could be one potential building block of the fast Wi-Fi recovery solution. 2. Fast authentication, that may be combine with other network configuration procedures to decrease the delay Liu Expires April 16, 2013 [Page 5] Internet-Draft Wi-Fi user experience October 2012 IEEE 802.11ai also deal with the fast authentication problem. The basic idea is to bind the authentication procedure in the MAC layer protocol procedures to reduce the roundtrip needed by authentication and parallelize the different procedures needed during the link setup. 3. Fast network connectivity testing In some cases, the finish of link layer setup and IP address configuration does not mean that the Wi-Fi network is ready for use. For example, the widely deployed portal based Wi-Fi authentication can allocate IP address to the user before authentication, but the user can not get Internet access until input the user name and password in an redirect authentication web page. In this scenario, only the application layer can detect the usability of the Wi-Fi network. As an example, Apple device will try to send http Get request to the url: "http://www.apple.com/library/test/success.html" to test the usability of current connected Wi-Fi network. If the response of this http Get request is "Success", then the Apple device will know that the current connected Wi-Fi network is ready for use. This solution is workable for a specific vendor but is not a general solution for the Internet. Some IETF work may needed to define a general protocol to test the usability of the Wi-Fi network. 4. Virtual Interface Another key point of the Wi-Fi fast recovery solution is the virtual interface in the terminal. In current IP stack implementation, if the physical network status changes, the TCP and other IP layer connection usually will be broken. For example, if the user handover from 3G network to Wi-Fi, even the IP address allocated by the two network is the same IP address, the application's network connection will still be broken due to the physical network interface changes. This problem could be solved using virtual interface. All the application's network connection in the terminal will bind to the virtual interface. The virtual interface have all the IP layer configuration of the physical network interface. All the application's data traffic will first send to the virtual interface, then the virtual interface will map the traffic to the actual physical interface. By this appraoch, the physical network handover event will not interupt the application's network connection. 4. Conclution This document discusses the problem and potential solutions for fast Wi-Fi network recovery. Some of the building block of the fast Wi-Fi network recovery may need standardization work in IETF. Liu Expires April 16, 2013 [Page 6] Internet-Draft Wi-Fi user experience October 2012 5. Security Considerations This document does not have any security considerations. 6. IANA Considerations This document does not have any IANA actions. 7. References 7.1. Normative References [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008. 7.2. Informative References Appendix A. Acknowledgements This document has benefitted from discussions with the following people, in no particular order: Basavaraj Patil, Jari Arkko, Brian Haberman, Jouni Korhonen, Hui Deng, Sri Gundavelli, Peter McCann, Alper Yegin,Serge Manning Rajeev Koodli. Author's Address Dapeng Liu China Mobile Phone: +86-139-117-88933 EMail: liudapeng@chinamobile.com Liu Expires April 16, 2013 [Page 7]