| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Mark, Thanks for the comment. I have made some revision based on your comments. A new vision will be uploaded. For the detailed response, please see below. Best, Po-Kai This seems to have a self-contradictory or at least confusing resolution to CID 5772: Based on the agreement for CID 7975, MU-RTS Trigger frame shall not be carried in a VHT MU PPDU or an HE MU PPDU due to the following reasons.
[…] Except these restrictions, MU-RTS Trigger frame can be carried in HT PPDU or VHT PPDU format. Is this trying to say that the answer to the commenter's "Is it possible to transmit MU-RTS in HT PPDU or VHT PPDU format?" is "yes,
except if it's a VHT MU PPDU"? [Po-Kai]: Yes. I can mention this directly in the resolution. Also, the resolution talks of "if the MU-RTS frame is aggregated with other variants of Trigger frame" and "if multiple MU-RTS is aggregated" but the comment is not about these
cases (which seem like strange corner cases). [Po-Kai]: These texts are used to explain why MU-RTS shall not be carried in MU PPDU. I rewrite the sentence so that it can be understood as the explanation. Re CID 9476, you say "Our study indicates that except Power Management and Protected Frame subfields, which are reserved in CTS frame. All the other fields are already defined in the current spec, and the
corresponding texts are shown below." but the Protected Frame subfield is covered by 12.2.7 Requirements for the Protected Frame field The Protected Frame field shall be set to 1 in: — Data frames that are protected using the mechanisms specified in Clause 12 (Security). — Individually addressed robust Management frames. — Authentication frames with Authentication Algorithm Number field equal to 1 (Shared Key) and Authentication Transaction Sequence Number field equal to 3. It shall be set to 0 in all other frames. Additionally, Figure 9-19 already shows that this is 0 in Control frames. [Po-Kai]: Thanks for pointing this out. I will refer to Figure 9-19 directly for most of the explanation. I agree the More Data subfield is required by the baseline to be 0 in a CTS sent by a non-DMG STA. My concern is the Power Management subfield. Where exactly do you see this being reserved in a CTS frame? I agree that if it is indeed reserved then that guarantees it will be 0 on tx for now (though for safety it might be better to require it to be 0), but is it actually reserved? [Po-Kai]: I can explain my thought process here. Based on the spec texts, power management is only valid based on the frame exchange in 11.2.3 and 11.2.7. Since CTS frame
does not give you an acknowledgement, power management field in CTS frame is not even valid. My original assumption is then that it is reserved. I then check again with Robert to see if “invalid” means “reserved”, but Robert said he does not know. I guess
there could be an ambiguity here, so it may be worthwhile to say that power management field is set to 0 for CTS in response to MU-RTS. Corresponding sentence is added. The Power Management subfield is 1 bit in length and is used to indicate the power management mode of a From: Mark Rison [mailto:m.rison@xxxxxxxxxxx] Unfortunately I shall not be able to attend this teleconf, since it will be at 01:00 my time. Some comments: ·
https://mentor.ieee.org/802.11/dcn/17/11-17-1173-01-00ax-proposed-resolutions-to-cid-5011-6900-6998-and-9056.docx
- Osama Aboul-Magd The document referred to in this, 17/0090 suggests (I haven't checked) that the 5 documents referred to on slide 8 provide further evidence that 11ax will achieve the 4x improvement required by the PAR. If this is so, it would be worth mentioning them in the resolution too, or the commenter could just object that 4x needs to be achieved for more than the one case of UL MU-MIMO. ·
11-17-1067-02-00ax-lb225-11ax-d1-0-comment-resolution of OMI Operation Mode – Liwen Chu (to be uploaded) ·
https://mentor.ieee.org/802.11/dcn/17/11-17-1068-00-00ax-comment-resolution-10-7.docx - Liwen Chu I think the "TGax editor makes changes in 11-17/1068 under CID blah" resolutions are needlessly indirect and unhelpful to the commenters. I suggest saying just "Delete the changes to Subclause 10.7.6 (Rate selection for Control frames)". Also, the resolution to CID 9559 does not seem to actually respond to it. CID 9559 is about rate selection for Management frames but the resolution talks of "Rate selection rules for both AP and STA.". ·
https://mentor.ieee.org/802.11/dcn/17/11-17-1174-00-00ax-clauses-3-2-3-3-and-3-4-comment-resolution.docx
- Osama Aboul-Magd "multi-user" should have a hyphen. What are the "(?)"s about? (They're not shown using change tracking, which is doubly confusing.) The definition of DSRP_PPDU is missing and also it's not in the alphabetical position. "No more action is needed." should just be a note to the Editor (the commenter was apparently correct to say DL was missing in D1.0). 802.11ah is -2016 not -2017 (and not _2016 either). "Hiwever “HE” by ioteself" has two typos. "block ack request" should be "block acknowledgment request"
(see the baseline). "resue" should be "reuse". There should probably be a definition of "HTP" and/or "HTP Ack". ·
https://mentor.ieee.org/802.11/dcn/17/11-17-1183-01-00ax-cr-for-cid-5772-9476-9480.docx
- Po-Kai Huang This seems to have a self-contradictory or at least confusing resolution to CID 5772: Based on the agreement for CID 7975, MU-RTS Trigger frame shall not be carried in a VHT MU PPDU or an HE MU PPDU due to the following reasons.
[…] Except these restrictions, MU-RTS Trigger frame can be carried in HT PPDU or VHT PPDU format. Is this trying to say that the answer to the commenter's "Is it possible to transmit MU-RTS in HT PPDU or VHT PPDU format?" is "yes,
except if it's a VHT MU PPDU"? Also, the resolution talks of "if the MU-RTS frame is aggregated with other variants of Trigger frame" and "if multiple MU-RTS is aggregated" but the comment is not about these
cases (which seem like strange corner cases). Re CID 9476, you say "Our study indicates that except Power Management and Protected Frame subfields, which are reserved in CTS frame. All the other fields are already defined in the current spec, and the
corresponding texts are shown below." but the Protected Frame subfield is covered by 12.2.7 Requirements for the Protected Frame field The Protected Frame field shall be set to 1 in: — Data frames that are protected using the mechanisms specified in Clause 12 (Security). — Individually addressed robust Management frames. — Authentication frames with Authentication Algorithm Number field equal to 1 (Shared Key) and Authentication Transaction Sequence Number field equal to 3. It shall be set to 0 in all other frames. Additionally, Figure 9-19 already shows that this is 0 in Control frames. I agree the More Data subfield is required by the baseline to be 0 in a CTS sent by a non-DMG STA. My concern is the Power Management subfield. Where exactly do you see this being reserved in a CTS frame? I agree that if it is indeed reserved then that guarantees it will be 0 on tx for now (though for safety it might be better to require it to be 0), but is it actually reserved? 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 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxx]
On Behalf Of Osama AboulMagd Updated agenda. Regards; Osama. From: *** 802.11 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxx]
On Behalf Of Osama AboulMagd Hello All, A proposed agenda for the telecom this week: ·
Call the meeting to order ·
IEEE 802 and 802.11 IPR policy and procedure ·
Attendance reminder. Please send an e.mail to Yasuhiko Inoue (Inoue.yasuhiko@xxxxxxxxxxxxx) and/or Osama
Aboul-Magd (Osama.aboulmagd@xxxxxxxxxx) ·
Announcements ·
September ad hoc meeting ·
ePoll:
https://mentor.ieee.org/802.11/poll-vote?p=26500008&t=26500008 ·
https://mentor.ieee.org/802.11/dcn/17/11-17-1173-01-00ax-proposed-resolutions-to-cid-5011-6900-6998-and-9056.docx
- Osama Aboul-Magd ·
11-17-1067-02-00ax-lb225-11ax-d1-0-comment-resolution of OMI Operation Mode – Liwen Chu (to be uploaded) ·
https://mentor.ieee.org/802.11/dcn/17/11-17-1068-00-00ax-comment-resolution-10-7.docx - Liwen Chu ·
https://mentor.ieee.org/802.11/dcn/17/11-17-1174-00-00ax-clauses-3-2-3-3-and-3-4-comment-resolution.docx
- Osama Aboul-Magd ·
https://mentor.ieee.org/802.11/dcn/17/11-17-1183-01-00ax-cr-for-cid-5772-9476-9480.docx - Po-Kai Huang ·
AoB ·
Adjourn Please let me know if you have ay submission. Regards; Osama. From: *** 802.11 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxx]
On Behalf Of Osama AboulMagd Hello All, There is a TGax telecon scheduled on Thursday July 27 at 20:00 ET.
Please let me know if you plan a submission. Teleconferences are bound by the conditions stipulated by the documentation below. Please review them and bring up any questions/concerns you may have before proceeding with
the teleconference IEEE Patent Policy - http://standards.ieee.org/board/pat/pat-slideset.ppt To join the meeting: Conference ID: 808-571-868 Regards; Osama. _______________________________________________________________________________
If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.
Instead, go to
http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX and then press the LEAVE button.
Further information can be found at:
http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________
_______________________________________________________________________________
If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.
Instead, go to
http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX and then press the LEAVE button.
Further information can be found at:
http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________
_______________________________________________________________________________
If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.
Instead, go to http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX and then press the
LEAVE button. Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________
If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect. Instead, go to http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX and then press the LEAVE button. Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________ |