New DLS (nDLS) Date: 2007-03-15 Menzo et al. 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>. Menzo et al.
Abstract This presentation provides overview of nDLS, an extension of 802.11 Direct Link Setup (DLS) protocol based on 802.11-REVma Features supported by nDLS include: Frame formats and over-the-air nDLS protocol for STAs to establish bidirectional direct link with other STAs. Over-the-air protocol includes establishing the direct link, adding security to an established direct link, and a teardown mechanism. Frame formats and over-the-air Best Path Selection (BPS) measurement exchange to help STAs decide between direct path (DLS) and AP path. Frame formats and over-the-air Link Suspension (LS) protocol to allow participating STA to go in Power Save or suspend ingress DLS link. Modification to PeerKey security handshake to remove AP dependency. Menzo et al.
Current DLS AP 1b 1a 2a 2b STA2 STA1 1a: Action Frame (Mgmt frame) containing “rate set, capabilities of STA1, and MAC address of STA1/STA2” 1b: Action Frame (Mgmt frame) containing “rate set, capabilities of STA1, and MAC address of STA1/STA2” 2a: Action Frame (Mgmt frame) containing “rate set, capabilities of STA2, and MAC address of STA1/STA2” 2b: Action Frame (Mgmt frame) containing “rate set, capabilities of STA2, and MAC address of STA1/STA2” Menzo et al.
Action Data Frame Encapsulation MPDU format for IEEE 802.3/Ethernet The frame body of a data frame to send one or more IEs or one Action frame is defined below : 2 octets 1 octet 2 octet n octets Ethernet Type Protocol Version Packet Type Packet Length (One or more) IEs or one Action Frame Menzo et al.
nDLS AP 1a 2a STA2 STA1 Define a new “Action Data Frame” Encapsulation which will allow us to send different IEs as data frame payload Send using three address scheme 1a: Action Data Frame containing “nDLS Request” 2a: Action Data Frame containing “nDLS Response” Menzo et al.
Current PeerKey: SMK Handshake AP 1b 1a 3a 2a 3b STA2 STA1 1a: EAPOL-Key frame (Data frame) containing “INonce, MAC I, MAC P, RSNIE_I” 1b: EAPOL-Key frame (Data frame) containing “INonce, MAC P, MAC I, RSNIE_I” 2a: EAPOL-Key frame (Data frame) containing “INonce, PNonce, MAC P, MAC I, RSNIE_P” AP Generates SMK (random number) 3a: EAPOL-Key frame (Data frame) containing “SMK, PNonce, Lifetime, INonce, MAC P, MAC I” 3b: EAPOL-Key frame (Data frame) containing “SMK, INonce, Lifetime, PNonce, MAC I, MAC P, RSNIE_P” Menzo et al.
New PeerKey: SMK Handshake AP 1a 2a 1b STA2 STA1 EAPOL-Key is Data Frame Send using three address scheme 1a: Initiator STA Peer STA: INonce, RSNIE_I, MAC_I, BSSID, Lifetime , DH_I 2a: Peer STA Initiator STA: PNonce, RSNIE_P, MAC_I , MAC_P, BSSID, INonce, Lifetime , DH_P 1b: Initiator STA Peer STA: INonce, MAC_I , BSSID, PNonce Menzo et al.
PeerKey: 4-way STK Handshake No Change ANonce, SMKID AP STA1 SNonce, SMKID, RSNIE_P, Lifetime STA2 ANonce, RSNIE_I, Lifetime Ack Menzo et al.
Best Path Selection: nDLS RCPI Request/Response STA1 STA2 RCPI1 RCPI2 1 octet nDLS RCPI Response STA1 STA2 RCPI1 RCPI2 1 octet RCPI1 indicates the received channel power of the corresponding Link Measurement Request frame in dBm. This represents RCPI value of nDLS link. RCPI2 indicates the received channel power of the corresponding Link Measurement Request frame in dBm. This represents RCPI value of peer STA and AP link. Menzo et al.
DLS Power Save Requirement AP STA2 STA1 Any STA participating in DLS wants to go to Power Save When one STA is in Power Save, other STA wants to go to Power Save STA in Power Save, wakes up Menzo et al.
DLS Power Save using LS: Case 1/Case 2 Assumes STAs/AP has APSD Use Action Data Frame Encapsulation to send messages Send using three address scheme 1a: Action Data Frame containing “Indication to STA2 that its going in Power Save” STA1: After sending message 1a, follows APSD Power Save to go to power save Menzo et al.
DLS Power Save using LS: Case 3 STAs/AP has APSD Use Action Data Frame Encapsulation to send messages Send using three address scheme STA1: Follows APSD Power Save and wakes up from Power Save 1a: Action Data Frame containing “Indication to STA2 that its is waking up from Power Save” Menzo et al.