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

Re: [STDS-802-11-TGM] Summary of CIDs in 22/576

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

Hi, Brian.

 

Thank you for all the work.

 

Regarding CID 1059 and 2019, I like the direction of streamlining the “delay” to an earlier point in the PPDUs.

However, I am not convinced with all the details of the changes.

For example, I think it would be simpler to just set the aRxPHYStartDelay to a common 24 usec for Clause 17 (OFDM), 19 (HT), 21 (VHT) and 27 (HE).  That gives enough time for all these PHYs to detect at least L-SIG and/or RL-SIG, and in case of HT-GF, the HT-SIG.  Then, I don’t think we need the new “KeyValueList” variable, and the operation of taking the max. value.

 

Regards,

Youhan

 

 

From: Brian Hart (brianh) <00000c7561051aea-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, September 13, 2022 1:47 PM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] Summary of CIDs in 22/576

 

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

Fixed this. Also aligned the POWER_BOOST_CHANGES with the latest changes in 11be on this topic (from Hanqing’s 22/1270r3). The new doc is now uploaded as r10. -B

 

From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Monday, September 12, 2022 8:11 PM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] Summary of CIDs in 22/576

 

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

Thanks, Brian.

 

So, CID 1056 still has a proposed resolution in 11-22/576, it just has a different proposal, which is to reject.  (Just to make sure the agenda notes – if/as appropriate – that the CID is covered by this submission.)

 

I do have a nit-pick: Since the resolution is Rejected, good practice dictates the actual resolution (not just notes to commenters) provide the rationale for the rejection. In this case, I would recommend just deleting the “Note to Commenter:“ so, this is a full resolution of Rejected and rationale.

 

Thanks. Mark

 

From: Brian Hart (brianh) <brianh@xxxxxxxxx>
Sent: Monday, September 12, 2022 8:35 PM
To: mark.hamilton2152@xxxxxxxxx; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGM] Summary of CIDs in 22/576

 

Hi Mark – inline -B

 

From: mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>
Sent: Monday, September 12, 2022 4:52 PM
To: Brian Hart (brianh) <brianh@xxxxxxxxx>; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGM] Summary of CIDs in 22/576

 

Thanks, Brian,

 

I believe 22/576 also resolves:

  • CID 2109: 22/576 redefines how aRxPHYStartDelay is used, so it is the maximum of a number of possible aRxPHYStartDelay values, depending on other possible TXVECTOR parameters, in the resolution of CID 1059.

[So confirmed.]

  • CID 1056 is covered by 22/576, by adding a new Vendor Specific Trigger frame.

[Actually I’ve changed CID 1056 to a reject, so now there is no proposal in 22/576r9 to add a new VS trigger frame.]

 

Can you confirm this understanding?

 

And, then, does anyone have a concern with agreeing to these resolutions, also?

 

Thanks.  Mark

 

From: Brian Hart (brianh) <00000c7561051aea-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, September 12, 2022 3:14 PM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGM] Summary of CIDs in 22/576

 

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

Hi all

 

Re the resolutions in 22/576, review and email discussion in order to improve the efficiency of the 11me meeting is welcomed. 22/576 resolutions, if accepted, has the following consequences:

  • 1052: Correction to D1 changes to VHT RX procedure to properly account for short PPDUs (HE changes dropped)
  • 1058:
    • Clarify that aRxPHYDelay is after the end of all received PPDU processing
    • In the MAC DCF/EDCF timings (fig 10-25 and -62), remove D1 = aRxPHYDelay (“12us”) from D2 and add to CCADel instead, so timings are non-negative
  • 1059: Add a new primitive PHY-RXEARLYSIG that reports, to the MAC, the existence of a PPDU being actively received, as early as possible and long before the end of the last SIG field. Then define shorter (and fewer) values of aRxPHYStartDelay accordingly.
  • 1062: When a STA with a more advanced PHY invokes the RX procedure of a less advanced PHY when it is receiving a PPDU for the less advanced PHY, more clearly define where the “GOTO” to the RX procedure of the less advanced PHY resumes
  • 1067: Apply the POWER_BOOST_FACTOR changes adopted in EHT to HE also (i.e., given the constraints are known to the MAC, make it explicit that POWER_BOOST_FACTOR is under the control of MAC not PHY)
  • 1072: Add a MIB variable for HE bandwidth

 

Cheers

Brian

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