Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGAX] TGax CRC Teleconference 2020-04-02



Hello,

 

       Motions related to submissions discussed during previous teleconferences, if ready:

       https://mentor.ieee.org/802.11/dcn/20/11-20-0297-00-00ax-cr-for-7-cids.docx - Jarkko Kneckt

       https://mentor.ieee.org/802.11/dcn/20/11-20-0369-02-00ax-cr-cid-24054.docx - Po-Kai Huang

       https://mentor.ieee.org/802.11/dcn/20/11-20-0352-01-00ax-cr-d6-0-he-phy-service-interface.docx - Bo Sun

       https://mentor.ieee.org/802.11/dcn/20/11-20-0348-01-00ax-mac-cr-misc-cids-in-clause-3.docx - Alfred Asterjadhi

       https://mentor.ieee.org/802.11/dcn/20/11-20-0349-00-00ax-mac-cr-misc-cids-in-clause-10.docx - Alfred Asterjadhi

       https://mentor.ieee.org/802.11/dcn/20/11-20-0315-02-00ax-resolution-for-cids-related-to-multiple-bssid.docx   - Abhishek Patil

       https://mentor.ieee.org/802.11/dcn/20/11-20-0316-02-00ax-resolution-for-cids-related-to-bss-color.docx  – Abhishek Patil

       https://mentor.ieee.org/802.11/dcn/20/11-20-0318-01-00ax-resolution-for-cids-related-to-uora.docx – Abhishek Patil

       https://mentor.ieee.org/802.11/dcn/20/11-20-0445-01-00ax-mac-cr-misc-cids-in-clause-9.docx – Alfred Asterjadh

       https://mentor.ieee.org/802.11/dcn/20/11-20-0317-02-00ax-resolution-for-misc-cids.docx – Abhishek Patil

 

I have some comments on some of the resolutions that are proposed for motion.  I will

be unable to attend today’s teleconf, so I will make them here and I request that they

please be discussed at the relevant point during the motion process, despite my absence.


       https://mentor.ieee.org/802.11/dcn/20/11-20-0297-00-00ax-cr-for-7-cids.docx - Jarkko Kneckt

 

I'm going to assume the motion will be on the stuff in r3, not the

stuff in r0.

 

I'm confused re CID 24457.  I thought we had agreed to resolve this

during the last teleconf as follows:

 

Straw Poll (Suggestions for changes supporting CID 24457): Do you accept to resolve CID 24457 as Revised and change the following text:

l     At 49.16 change "the 5 to 7.125 GHz bands" [sic] to "the 5 and 6 GHz bands”

Result: Y/N/A = 11/2/8

 

I continue to oppose the resolution shown for CID 24523.  If

"the OM parameters that AP uses are not reliable for the STAs" then the feature is

useless and should be deleted entirely.

 

Also, for CID 24124 you need to delete the commas at the start too,

otherwise you get "These features can, improve the average throughput".

 

Finally, for CID 24458, since TB PPDUs are sent in response to triggering

frames, I think it would be better to say:

 

An HE STA that is a mesh STA shall not transmit a triggering frame.


For CID 24294:

 

- A design in which a parameter that is N/A is present is not “simple and clean”

 

- The baseline convention is to only pass in parameters that are applicable

(that is why we have conditions like “FORMAT is HE_TB” in the TXVECTOR table)

 

- The commenter's proposed change explicitly identifies how the issue

can be fixed in a "simple and clean" manner, and should be adopted

 

For CID 24498:

 

- Calling a parameter SCRAMBLER_INITIAL_VALUE when it does NOT contain

the scrambler initial value is, well, completely irrational

 

- There have been interop issues caused by the confusion between the

scrambler initial value and the (scrambled) value of the Scrambler

Initialization field, so it is even more important to make sure the

parameter naming is not misleading

 

- There are only 3 instances of the term, so there is no editorial

cost to fixing this

 

- I think a concern was expressed that SCRAMBLER_INITIALIZATION_FIELD itself

was misleading, because it's the value in that field after scrambling.

I am happy to change the proposed parameter name to

SCRAMBLED_SCRAMBLER_INITIALIZATION_FIELD to address that concern

 

Similarly for CID 24499, the issue is quite subtle and this has caused

interop issues.  To minimise the chance of future interop issues,

a NOTE is more than justified.

 

       https://mentor.ieee.org/802.11/dcn/20/11-20-0317-02-00ax-resolution-for-misc-cids.docx – Abhishek Patil

       the following CIDs are deferred: 24552, 24311, 24400, 24401, 24352, 24348

 

For CID 24349, where it says "parameter STA-ID" it should be "parameter STA_ID".

 

       https://mentor.ieee.org/802.11/dcn/20/11-20-0369-02-00ax-cr-cid-24054.docx - Po-Kai Huang

 

CID 24054

 

As discussed during the last teleconf, there seems to be disagreement

as to whether a unicast 1SS Trigger frame will take a STA that supports

dynamic HT SMPS but not HE SMPS out of 1SS-only mode.  We need to agree

on what the answer is here; we cannot leave this interop issue open.

 

It we agree that it does, then I suggest we make this clear by adding in the HE SMPS subclause:

 

NOTE—A non-AP HE STA in dynamic SM power save mode that does not support

HE dynamic SM power save and that receives an individually addressed Trigger frame

addressed to it behaves as described in 11.2.6 (SM power save).

 

Also,

 

The STA switches to the multiple receive chain mode if it responds to the Trigger frame addressed to it

 

is just duplication of "shall also enable its multiple receive chains if it responds to a

Trigger frame [that starts a frame exchange sequence] that satisfies the following conditions" above

and should be deleted.  (Also "addressed to it" is weird -- a STA is

not, I hope, going to respond to a Trigger frame not addressed to it.)

I agree the baseline has this duplication too, and I will raise it in TGmd.

 

       https://mentor.ieee.org/802.11/dcn/20/11-20-0316-02-00ax-resolution-for-cids-related-to-bss-color.docx  – Abhishek Patil

      the following CIDs are deferred 24248, 24249, 24250

 

- I don't think the resolutions to 24242 and 24243 make sense (see attached)

 

- "one of the following condition" needs to be "… conditions"

 

- For 24248, 24249, 24250 the terminology is all over the place (see attached).

Also some stuff is in a NOTE but needs to be normative (because it's

a definition)

 

- For the non-CID proposal at the end, why not delete "HE" in the first bullet

too?  Looks inconsistent otherwise

 

- For 24147 you said you had added "HE" in "so that other STAs can benefit from features relying on BSS color"

but it's still missing

 

- For 24515 there are some editorials (see attached)

 

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


To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1

Attachment: 11-20-0316-02-00ax-resolution-for-cids-related-to-bss-color-mgr.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document