1. doc.: IEEE 802.11-07/0758r2 Submission May 2007 Adrian Stephens, Intel CorporationSlide 1 LB97 Submission related to CID 1969 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, 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfpatcom@ieee.org Date: 2007-05-15 Authors:

2. doc.: IEEE 802.11-07/0758r2 Submission May 2007 Adrian Stephens, Intel CorporationSlide 2 Abstract This presentation contains material that speaks to the issues raised in 802.11 ballot LB97 comment CID 1969 It also contains straw polls to clarify the opinion of the membership on this issue

3. doc.: IEEE 802.11-07/0758r2 Submission May 2007 Adrian Stephens, Intel CorporationSlide 3 Comment 1169 There is a coexistence issue that will probably eventually be addressed in a separate.11 actiity, but it's worth asking the question about whether there's any low-hanging fruit we can get into.11 at this point that would make it far more amenable to addressing such issues. When MACs of different wireless standards are co- located, they may have "inside knowledge" about what will happen in the future that may cause interference. For example, if a.11 MAC is colocated with 802.15.1, the 802.15.1 MAC can predict when it will be in-band of the.11 MAC at any time in the future.

4. doc.: IEEE 802.11-07/0758r2 Submission May 2007 Adrian Stephens, Intel CorporationSlide 4 Comment 1169 (continued) If if it is colocated with an 802.16 MAC it knows that it needs to receive the MAP structures and when its downlink and uplink allocations start. So the question to the group is whether we should say any change to support this, no matter how small, is in scope or not. The argument for it being in scope is that if we improve coexistence we can substantially improve the user experience - remember many of our usage models are predicated on QoS traffic in the 802.11 segment. We can also argue that reduction of interference improves throughput and is therefore in scope.

5. doc.: IEEE 802.11-07/0758r2 Submission May 2007 Adrian Stephens, Intel CorporationSlide 5 Proposed Change 1169 There is one small change that could be considered "low-hanging fruit" - TXOP reduction.Consider an RTS/CTS exchange. The RTS is sent with a Duration/ID field set to the TXOP duration.The responder knows of a future event that will interfere with this TXOP at some time t in the future. It sends a CTS with the Duration/ID set to t < remaining TXOP duration. The TXOP holder observes the reduced Duration/ID value and completes any activity by time t.

6. doc.: IEEE 802.11-07/0758r2 Submission May 2007 Adrian Stephens, Intel CorporationSlide 6 For Better Coexistence of 802.11n with Other Collocated Radios Solution 1: TXOP reduction Solution 2: Notice of Absence

7. doc.: IEEE 802.11-07/0758r2 Submission May 2007 Adrian Stephens, Intel CorporationSlide 7 Goal: to protect WiFi from conflict of the collocated BT/WiMAX radio Problem: –802.11n co-locates with other radios (e.g. WiMax, BT) on a Multi-Radio Device (MRD) –A downlink transmission (AP  STA) might be corrupted or stopped by WiMAX / BT operation, leading AP to unnecessarily back-off, retransmit, or use lower MCS, therefore cause performance degradation –Uplink transmission is easy to control Solutions: –TXOP reduction: instantenously reduce TXOP to fit in the rest of available time before the (random) disruption starts  reactive –Notice of Absence: forecast future (periodic) absences from 802.11n network  proactive

8. doc.: IEEE 802.11-07/0758r2 Submission May 2007 Adrian Stephens, Intel CorporationSlide 8 Solution 1: TXOP Reduction Goal: –Let STA (MRD) reactively reduce the TXOP duration based on local knowledge to prevent data collision Benefits: –no additional overhead, and only logic change –use only when in-bound traffic is present

9. doc.: IEEE 802.11-07/0758r2 Submission May 2007 Adrian Stephens, Intel CorporationSlide 9 TXOP Reduction Process After getting an initial frame of a TXOP from a TXOP holder, the TXOP responder may reduce the value of the Duration/ID field of its response based on local knowledge. It may do this only if the TXOP holder declares support for TXOP reduction. For a TXOP holder that declared support for TXOP reduction, after receiving a response with TXOP reduction, it shall ensure that the rest of TXOP concludes before the truncated duration, including transmissions, acknowledgement, and the final CF-End. –If a TXOP reduction is not possible or meaningful for any reason, the TXOP holder may send out a CF-End immediately after receiving the TXOP reduction response.

10. doc.: IEEE 802.11-07/0758r2 Submission May 2007 Adrian Stephens, Intel CorporationSlide 10 Solution 2: Notice of Absence Goal: –Let AP know the expected disruption schedule of a MRD beforehand to prevent unnecessary activity with that MRD Benefits: –Reserve multiple (periodic) absence intervals at once with a single request –Accurately specify starting times and duration of future absence –Explicit wake-up messages not necessary

11. doc.: IEEE 802.11-07/0758r2 Submission May 2007 Adrian Stephens, Intel CorporationSlide 11 NoA Signaling A STA shall unicast NoA only to a NoA-capable STA, and expects ack A STA announces “NoA-capable” using the NoA field in the extended HT capability field A NoA-capable STA shall not transmit any unicast data frame to the NoA-requesting STA during absences indicated by (t, T, P, N) in the NoA request, where t: starting time of an absence cycle (using the lower two bytes of TSF) STA B compares “t” with the lower two bytes of its local TSF to decide when an absence cycle starts T: duration of each absence P: absence period – i.e., interval between absences N: number of absences in a cycle A new NoA request replaces an existing NoA (if any) from the same requester STA.

12. doc.: IEEE 802.11-07/0758r2 Submission May 2007 Adrian Stephens, Intel CorporationSlide 12 Frame Format 7.4.9.1 Table n31: 7.4.9.11 Notice of Absence frame format –The category field is set to 7 –The action field is set to 10 –The NoA information field contains 8 octets Duration and period in micro-second Action Field ValueMeaning 10Notice of Absence OrderMeaning 1Category 2Action 3NoA fields

13. doc.: IEEE 802.11-07/0758r2 Submission May 2007 Adrian Stephens, Intel CorporationSlide 13 Supporting Feature: two bits in “HT extended capabilities” B12: TXOP reduction B13: NoA

14. doc.: IEEE 802.11-07/0758r2 Submission May 2007 Adrian Stephens, Intel CorporationSlide 14 Summary Two solutions to address the coexistence issue for.11n with other collocated radios –TXOP reduction (reactive)  primarily for random disruption –NoA (proactive)  primarily for periodic disruption Summary of Changes to D2.0 –2 new bits in the HT extended capability field for “NoA” and “TXOP reduction”, respectively –1 new NoA frame (action and unicast) –Changes to clause and control flow

15. doc.: IEEE 802.11-07/0758r2 Submission May 2007 Adrian Stephens, Intel CorporationSlide 15 Straw Poll #1 Do you support (in concept) the addition of any mechanisms in 802.11n to improve coexistence with co- located “other” wireless devices? Yes No Abstain

16. doc.: IEEE 802.11-07/0758r2 Submission May 2007 Adrian Stephens, Intel CorporationSlide 16 Straw Poll #2 Do you like (i.e., would like to see incorporated, once the details are worked out) a TXOP truncation mechanism?

17. doc.: IEEE 802.11-07/0758r2 Submission May 2007 Adrian Stephens, Intel CorporationSlide 17 Straw Poll #3 Do you like (i.e., would like to see incorporated, once the details are worked out) a “Notice of Absence” mechanism?