Fair and Protected DLS September 2007 Date:2007-09-18 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>.

Outline Simulation scenario Simulation results (Cases 1-7) September 2007 Outline Simulation scenario Simulation results (Cases 1-7) RTS/CTS approach DLA approach Poll?

September 2007 Simulation scenario Two direct links QSTA 1-> QSTA 2 and QSTA 3-> QSTA 4 All QSTAs use Block ACK transmission Initiators of direct transmissions work in saturation 11a PHY, 54 Mbps QSTAs are moving as it is shown in the slide 2 1 3 4

Case 1: OK September 2007 All four QSTAs are in TX-range of one another Existing methods are good enough

Case 2: EIFS instead of DIFS September 2007 QSTA 3 sends data to QSTA 4 When QSTA 4 replies with an ACK, QSTA 1 senses noise QSTA 1 waits EIFS, while QSTA 3 waits only DIFS<EIFS, before backoff QSTA 3 has an advantage over QSTA 1

Case 3: unfair collision September 2007 QSTA 1 and QSTA 3 send RTS frames at the same time It is a collision for QSTA 2, but not for QSTA 4 QSTA 4 replies with an ACK, and QSTA 3 starts a data transmission QSTA 3 has an advantage over QSTA 1

Case 4: unfair collision + EIFS instead of DIFS September 2007 Both problems as in Cases 2 and 3

Case 5: unfair CW growth September 2007 QSTA 3 starts a data transmission, QSTA 2 sets its NAV QSTA 1 sends an RTS, but QSTA 2 does not reply QSTA 1 increases its CW, performs backoff and sends the RTS again, and again… … QSTA 1 drops the planning data packet, CW of QSTA 1 is huge

Case 6: unfair CW growth - EIFS instead of DIFS September 2007 The same problems as in Cases 2 and 5

Case 7: spatial reuse benefit September 2007 Pairs of QSTAs are absolutely hidden from each other: spatial reuse is possible More than good: total throughput is more than 54Mbps

Summary of simulation analysis September 2007 Summary of simulation analysis Problems: unfair distribution of channel capacity Using EIFS instead of DIFS Unfair growth of CW Unfair collisions Opportunities: using of spatial reuse benefit Not to lose it while resolving problems

RTS/CTS approach September 2007 This approach: Simple Standard frames Reliable protection of direct links RTS CTS But it does not resolve the problem of using EIFS instead of DIFS (e.g., see Case 2) DATA But…

RTS/CTS approach September 2007 But it allows NO spatial reuse 3->AP RTS AP->3 CTS (all STAs receive) The CTS from AP prohibits all other transmissions However, transmissions 1->2 and 3->4 would be possible at the same time DATA RTS CTS DATA

Direct Link Announcement September 2007 Direct Link Announcement We propose to introduce a special Direct Link Announcement (DLA) data frame Basic idea: the source QSTA shall broadcast/multicast the DLA frame over the AP by setting ‘To DS’ bit to 1 DLA frame includes: Direct transmission source and its destination Duration of the planning direct transmission (a-lá NAV) DLA expiration time; after the time, DLA should be ignored

DLA September 2007 Protection: All QSTAs are informed of the planning direct transmission and its duration Upon receiving DLA back, QSTA 3 starts DATA after PIFS without contention Fairness: DLA resolves problems: Using EIFS instead of DIFS Unfair growth of CW Unfair collisions AP queues the DLA DLA DLA ACK ACK DATA

DLA: option 1 September 2007 Spatial reuse : During DL Setup or by other radio measurement procedures, QSTAs collect a list of neighbors which it may interfere with If the list is included into the DLA payload, spatial reuse is possible QSTAs which are not in the list may communicate during the direct transmission without sending DLA frames DATA DLA 5 DATA

DLA: option 2 September 2007 In addition to DLA, RTS/CTS approach Aim: to protect direct links from legacy STAs DLA DATA 5 RTS CTS DATA

September 2007 DLA + option 1 vs. Legacy

September 2007 Straw poll Should we prepare the normative text on Direct Link Announcement (DLA)? Yes: No: Abstain: