1. Ready to transition/ Clear to transition
Nov 2005
doc.: IEEE /1105r0
Nov 2005
Ready to transition/ Clear to transition
Date:
Authors:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Jon Edney, Stefano Faccin (Nokia)
Jon Edney, Stefano Faccin (Nokia)

2. Nov 2005
doc.: IEEE /1105r0
Nov 2005
Abstract
Describes an approach to enhance TGr draft to avoid loss of frames during a transition.
Jon Edney, Stefano Faccin (Nokia)
Jon Edney, Stefano Faccin (Nokia)

3. Causes of Lost Packets in Transition
Nov 2005
Causes of Lost Packets in Transition
When station makes a transition, packets may be lost for one of two reasons:
They are queued in the old AP awaiting transmission
They are misdirected to the wrong AP by the DS during the transition process DS DS
Packet delivered
to old AP
AP1
AP2
AP1
AP2
STA
STA
Packet “left
behind”
Jon Edney, Stefano Faccin (Nokia)

4. Nov 2005
Potential Approaches
Ignore lost packets and assume higher layer protocols will cure (current approach)
Return to AP to pick-up lost packets after connecting to new AP
Don’t leave old AP until all packets are delivered
Jon Edney, Stefano Faccin (Nokia)

5. Approach 1: ignore lost packets
Nov 2005
Approach 1: ignore lost packets
Lost packets can have substantial impact of certain protocols such as TCP (see Ref [1])
However, wireless is already an unreliable medium so perhaps lost packets should be expected
But note: substantial break in TCP transmission due to lost packets makes fast transition pointless
Schemes that recover lost packets after a delay may be problematic because delayed packets might be as useless as lost packets
Ref[1] concludes in favor of Approach 1
Jon Edney, Stefano Faccin (Nokia)

6. Approach 2: Return to collect
Nov 2005
Approach 2: Return to collect
AP successfully associates to new AP but then returns to old AP to collect any packets that have arrived before proceeding.
DS is
“Switched” DS DS DS
AP1
AP2
AP1
AP2
AP1
AP2
STA
STA
STA
Packet “left
behind” 1 2 3
Associate
Retrieve
Continue
Jon Edney, Stefano Faccin (Nokia)

7. Approach 2: Pros and Cons
Nov 2005
Approach 2: Pros and Cons
Pro
DS is switched by association so any new packets should get directed to the new AP. Any misdirected packets can be collected when returning to old AP
Cons
DS switching delay is unknown so STA doesn’t know how long to wait for misdirected packets
Have to change channel to get old packets so new packets are delayed at new AP waiting to be delivered
Jon Edney, Stefano Faccin (Nokia)

8. Approach 3: Wait for delivery
Nov 2005
Approach 3: Wait for delivery
AP pre-authenticates and requests DS switch
Wait for delivery of all packets
Associate to new AP to start new packet flow
DS is
“Switched” DS DS DS
AP1
AP2
AP1
AP2
AP1
AP2
STA
STA
STA
Pre-authenticate &
switch DS 1 2 3
Wait for packet
flush
Associate
Jon Edney, Stefano Faccin (Nokia)

9. Nov 2005
RTT/CTT Mechanism
After switching DS how long does STA wait to receive packets?
Proposed solution - use “Ready To Transition”(RTT) and “Clear To Transition”(CTT) messages
Synchronize transition through two message exchange
extension to the FT Authentication sequence using Actions Frames
Jon Edney, Stefano Faccin (Nokia)

10. Nov 2005
Details
Immediately prior to transition, TSTA sends “ready to transition” (RTT) frame to target AP (via broker).
Target AP switches DS and sends “clear to transition” (CTT) to current AP
Current AP waits until all queued frames are delivered to TSTA and then issues CTT frame to TSTA
Upon receipt of CTT, TSTA immediately proceeds with transition by associating with target AP.
STA has option to transition without waiting if time is too long
Jon Edney, Stefano Faccin (Nokia)

11. Nov 2005
Message Flow
Jon Edney, Stefano Faccin (Nokia)

12. Steps in transition Nov 2005 1 3 2 4 Pre-authenticate
(as for pre-reservation
mechanism)
DS is “Switched” 1 3 DS 2 DS DS
CTT
frame is sent
AP1
AP2
AP1
AP2
AP1
AP2
STA
Issue RTT
(authenticated)
STA
CTT Action frame delivered
STA
New
packets
start to
arrive DS 4
AP1
AP2
STA associates and
collects pending frames
STA
Jon Edney, Stefano Faccin (Nokia)

13. Key Features Optional mechansim
Nov 2005
Key Features
Optional mechansim
Does not affect base mechanism
Optional extension to pre-authentication mechanism
Adds one message exchange: “FT-RTT” and “FT-CTT” sent in action frames
Gives high confidence that frames are delivered
use of clearing frame ensures buffers are emptied
Static time-out to deal with pathological conditions
Does not delay frames
frames are transmitted with normal latency and queue delays
no unusual forwarding or copying of data frames
Jon Edney, Stefano Faccin (Nokia)

14. References [1] 11-05-1646-00-000r-no-packet-left-behind.ppt
Nov 2005
References
[1] r-no-packet-left-behind.ppt
Normative text
Jon Edney, Stefano Faccin (Nokia)