Proposed DLS Teardown Date: 2006-03-07 Ovadia, Ginzburg, Intel Notice: This document has been prepared to assist IEEE 802.11. 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 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// 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 <stuart.kerry@philips.com> 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Ovadia, Ginzburg, Intel

Abstract This submission addresses DLS teardown conditions that are not included in IEEE 802.11ma/D5.1 draft Standard. Ovadia, Ginzburg, Intel

Agenda DLS Teardown Process DLS Teardown Problem Proposed solution AP-initiated DLS teardown Ovadia, Ginzburg, Intel

DLS Teardown Assumptions: Initiating & recipient QSTAs are in the same BSS and still within reach of the QAP. Initiating & recipient QSTAs are able to reliably transmit and receive frames over the WM before starting the DLS teardown operation. Ovadia, Ginzburg, Intel

DLS Teardown Problem Under certain operating conditions, one or both of the STAs participating in the DLS link suddenly can not ‘hear’ the AP, but can still hear its DLS peer. What is the status of the DLS link? Who is responsible for DLS link teardown? Wireless AP / Router DLS Request DLS Response DMA TV Bidirectional DLS PC PC Ovadia, Ginzburg, Intel

Proposed Solution DLS teardown frame is sent directly to the peer STA (1) by either the DLS initiating STA or by the STA that can not ‘hear’ the AP The peer STA sends the DLS teardown frame to AP (2) L2 ACK is sent to Peer STA (DMA) AP removes the link from its DLS list Wireless AP / Router DLS Request DLS Response (2) Bidirectional DLS DMA TV DLS Teardown frame (1) Ovadia, Ginzburg, Intel

Proposed Solution (continue) Conditions for direct DLS Teardown include: One or both of the STAs move out-of-range of the AP (peer STAs can still ‘hear’ each other) Sudden reboot of the STA (assuming DLS inactivity timer expired) If target STA wants to go off channel (e.g., channel scanning) Order Information 1 Category (2) 2 Action (2) 3 Destination MAC Address 4 Source MAC Address 5 Reason Code (46) Add new Reason Code to describe a new condition Ovadia, Ginzburg, Intel

DLS Teardown Reason Code Table Reason Code Field Applicable at QSTA_LEAVING 36 Non-AP QSTA END_DLS 37 UNKNOWN_DLS 38 TIMEOUT 39 STAKEY_MISMATCH 45 PEER_INITIATED 46 AP and Non-AP QSTA AP_INITIATED 47 Proposed Reason Codes * The Peer STA sends DLS Teardown frame to AP. Ovadia, Ginzburg, Intel

AP-initiated DLS Teardown Under certain operating conditions, an AP can remove one or more STAs from its BSS list. The DLS teardown should be applied to specific DLS session. These conditions include: If STA left the BSS Teardown with Reason Code = 36 Sudden reboot or failure of the STA AP detects that the STA left its BSS AP loses its DLS session state  Teardown with Reason Code =47 If these STAs have open DLS connections, then the AP send a DLS Teardown message to all the peers of the removed STAs. Ovadia, Ginzburg, Intel

Feedback? Ovadia, Ginzburg, Intel