Download presentation
Presentation is loading. Please wait.
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)
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.