Internet DRAFT - draft-liu-wifi-fast-recovery
draft-liu-wifi-fast-recovery
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]
