| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hi, Mark, Comments on the rest, below. Mark From: ***** 802.11 REVm - Revision Maintainance List ***** [mailto:STDS-802-11-TGM@xxxxxxxx] On Behalf Of Graham Smith --- This message came from the IEEE 802.11 Task Group M Technical Reflector --- Hi Mark, My observations in line for the comments I resolved. Graham From: ***** 802.11 REVm - Revision Maintainance List ***** [mailto:STDS-802-11-TGM@xxxxxxxx] On Behalf Of Mark Rison --- This message came from the IEEE 802.11 Task Group M Technical Reflector --- Thanks for this. I have the following comments: - CID 1391. The new 10.25.3 says nothing about the promised Ack frames ("Once the block ack exchange has been set up, Data and Ack frames are transferred using the procedure described in 10.25.3(#57).") GS – That was not the 1391 comment. The comment was what does “sent under block ack policy’ mean? This was answered and sorted out. CID 1308 (same document 0672r1) put 10.25.3 back in as originally agreed in D0.1. This, I think, answers your question. - CID 1347. The point has been missed. The proposed change aligns DCF with EDCA (and presumably with what DCF implementations already do) GS – I spent a lot of time on this one and went through the steps as defined for EDCA. EDCA is basically the same backoff scheme as DCF but uses AIFSN x Slottime in place of DIFS. DCF uses DIFS when it know the duration of the received external packet, and EIFS when it does not (e.g. FCS error). The condition a) in EDCA corresponds to the DCF case where DIFS is used, with DIFS replaced with AIFSN x Slottime. Condition b) corresponds to the case where EIFS is used because, for example, the FCS failed. Hence EDCA and DCF are aligned. - CID 1356. "data or management frames" should be "Data or Management frames" GS – I don’t know, but I assume the editor will correct. - CID 1356. Why is "If dot11RTSThreshold is 0, an RTS/CTS exchange shall precede all frame exchanges including an individually addressed data or management frame" needed? This is covered by the previous para's "A STA using the DCF shall use an RTS/CTS preceding a frame exchange including an individually addressed data or management frame when the length of the PSDU is greater than the length threshold indicated by dot11RTSThreshold." (except for the "using the DCF", which should either be deleted or replaced with "using the DCF or EDCA") GS – We felt that a value of 0 is a special case because it is a “shall” and should be spelt out. We did clarify it I feel. - CID 1356. "A STA may also use an RTS/CTS exchange for individually addressed frames when it is necessary to distribute the NAV or when it is necessary to establish protection (see 10.27 (Protection mechanisms)). A STA may also use an RTS/CTS exchange for other purposes. " would be nicer as "A STA may also use an RTS/CTS exchange for individually addressed frames when it is necessary to distribute the NAV, or when it is necessary to establish protection (see 10.27 (Protection mechanisms)), or for other purposes." GS – Maybe, but I made the minimum changes and followed the commenter’s proposal. - CID 1358. Is the NOTE still appropriate under the new reduced para, or should it be moved to 10.3.5 or deleted? GS – I think it is OK here but agree it could go into 10.3.5. But that’s a separate comment. - CID 1398. I don't think reference should be made to "or the STA Channel Width field in the HT Operation element". NCW is at its core about non-AP STAs changing their operating width. An AP always has the option of fiddling with the HT Operation, but that's a different thing, and is an option whether or not the peers support OMN [MAH] OK. I can live without the added phrase. The net result will change the CID to ACCEPTED. We can discussion on the call, and see if there is any objection. - CID 1469, 1477. I'd like these pulled for now for more time to consider - CID 1382. For dot11BSSTransitionActivated to be true, logically, dot11BSSTransitionImplemented must also be true, yes, but the spec should not (and does not) rely on such inferences (e.g. in 11.25.2 "If dot11SCSActivated is true, dot11SCSImplemented shall be true.") [MAH] This whole mess of *Activated and *Implemented is being discussed ad nauseum in ARC, and all agreement is that both attributes should not be used for the same feature. While we have lots of examples of other places where the duality is ignored (granting you that you have found one where it is handled cleanly), at this point, my suggestion is to change the surrounding text, to simply remove the *Implemented version completely. Thus, a new proposed resolution: REVISED. At 2170.37, delete the sentence, “A STA that implements BSS transition management has dot11BSSTransitionImplemented equal to true.” At 2170.39 ½, change “dot11BSSTransitionImplemented” to “dot11BSSTransitionActivated”. Thanks, Mark -- Mark RISON, Standards Architect, WLAN English/Esperanto/Français Samsung Cambridge Solution Centre Tel: +44 1223 434600 Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601 ROYAUME UNI WWW: http://www.samsung.com/uk From: ***** 802.11 REVm - Revision Maintainance List ***** [mailto:STDS-802-11-TGM@xxxxxxxx] On Behalf Of Mark Hamilton --- This message came from the IEEE 802.11 Task Group M Technical Reflector --- All, I have uploaded an updated REVmd MAC ad hoc comment spreadsheet, here: https://mentor.ieee.org/802.11/dcn/17/11-17-0927-16-000m-revmd-mac-comments.xls This includes resolutions that will be considered for MOTION at the Warsaw meeting, for CIDs: 1391, 1299, 1308, 1313, 1347, 1356, 1358, 1381, 1147, 1390, 1554, 1392, 1398, 1425, 1504, 1469, 1528, 1477, and 1382, as discussed on recent teleconferences or at the Fort Lauderdate ad hoc session. I am still looking for volunteers to look at comments on MAC-level material that is PHY-specific, for DMG and S1G support. If anyone is willing to contribute in these areas, please let me know. Thanks. Mark To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1 To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1 To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1 To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1 |