1. Proposed resolution text for CCF related CIDs
January 2006
doc.: IEEE /340r0
September 2006
Proposed resolution text for CCF related CIDs
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
Rakesh Taori and Sung-Won Lee
Donald Eastlake 3rd, Motorola

2. January 2006
doc.: IEEE /340r0
September 2006
Abstract
This document proposes resolution texts to address CIDs 69, 70, 71, 124, 125, 129 and 208.
Rakesh Taori and Sung-Won Lee
Donald Eastlake 3rd, Motorola

3. January 2006
doc.: IEEE /340r0
September 2006
CID 129
Comment: The specification does not describe the behaviour when a transmitter sends an RTX but does not receive a CTX message from the receiver. The MP may not receive a CTX for similar reasons to not receiving CTS after sending an RTS (e.g. due to collision, NAV value on the receiver, etc). However, not receiving a CTX may also be due to the receiver being on a different channel communicating with a different MP at the time when the RTX message is sent. What should the transmitting MP do in these cases and how does it distinguish the cases?.
Proposed resolution: If the transmitter does not receive CTX frame after SIFS + 1 slot after the completion of the RTX frame, then it will retransmit the RTX frame in accordance with the normal rules.
(to be inserted on page 59, line 6)
Rakesh Taori and Sung-Won Lee
Donald Eastlake 3rd, Motorola

4. January 2006
doc.: IEEE /340r0
September 2006
CID 124
Comment: The specification makes no mention of broadcast data messages. All of the message exchanges shown in the Figure s81 are unicast. It is not clear how broadcast communication works in this scheme given that different MPs may be on different channels at the time of a particular broadcast transmission. Broadcast support is required both for data communication (e.g. ARP messages) as well as for management messages (e.g. route request messages).
Proposed resolution: CCF-compliant MPs shall buffer their broadcast frames until all its one-hop neighbours are available on the common channel. This broadcast can take place from the start of the CCW until the first RTX/CTX exchange.
(to be inserted on page 60, line 3)
Rakesh Taori and Sung-Won Lee
Donald Eastlake 3rd, Motorola

5. January 2006
doc.: IEEE /340r0
September 2006
CID 125
Comment: The specification does not describe how CCF works with power save mode.
Proposed resolution:
(Text in 1505r1): A CCF-compliant MP that is also PSM-compliant shall not transmit RTX frame if the subsequent CCF sequence overlaps with the beacon schedule.
(to be inserted on page 59, line 3)
(Modified text): An MP that has enabled CCF and PSM shall not transmit RTX frame if the subsequent CCF sequence overlaps with the PSM beacon schedules of its neighbours.
Rakesh Taori and Sung-Won Lee
Donald Eastlake 3rd, Motorola

6. CID 69, 70, 71, 208 Comments related to: virtual carrier sensing …
January 2006
doc.: IEEE /340r0
September 2006
CID 69, 70, 71, 208
Comments related to: virtual carrier sensing …
Proposed resolution: The CCA performed immediately after switching from the common channel to a destination channel, or vice versa, shall be carried out with a lower threshold defined by dot11_CCF_CCA_Thresh.
(to be inserted on page 59, line 8)
Rakesh Taori and Sung-Won Lee
Donald Eastlake 3rd, Motorola

7. September 2006
Motion
Move to accept the resolution to CID 129 as proposed in document 11-06/1505r1
Moved:
Seconded:
Result (Yes/No/Abstain):
Move to accept the resolution to CID 125 as proposed in document 11-06/1505r1
Move to accept the resolution to CID 124 as proposed in document 11-06/1505r1
Move to accept the resolution to CID 69, 70, 71 and 208 as proposed in document 11-06/1505r1
Rakesh Taori and Sung-Won Lee