Hi Mike and all,
Document 25/1831r2 has been uploaded including the changes discussed during the last 11mf adhoc meeting, which includes the resolutions for CID 161/162/163.
https://mentor.ieee.org/802.11/dcn/25/11-25-1831-02-000m-lb289-cr-for-cid-161-162-163.docx
The CID 163 has been marked as Ready for Motion. The resolution for this CID is to explicitly make the device be TxOP Holder when it has been allocated/shared a TxOP portion.
CID
Clause Number(C)
Page
Comment
Proposed Change
Resolution
163
35.2.1.2.3
5242.35
In the TxOP TXS mechanism, it does not specify whether a STA under the shared allocated time is TxOP Holder or not. Under current NAV setting rule caused by TXOP_DURATION (see 10.3.2.4 or 26.2.4), a device will have different behavior to set or not set its NAV according to its TxOP role (holder or not).
For example, a TxOP Holder will not set its NAV by the TXOP_DURATION in the PPDU responded by its TxOP responder, when the TxoP Holder only decodes the PHY header of the PPDU.To address the case as in the comment (whether to set NAV by TXOP_DURATION by reponse PPDU)The spec may need explicitly state the STA with shared allocated time in TxOP TXS procedure is TxOP Holder during the allocated time. Or if not, there should be other rules to handle the NAV setting rule for this STA.
Revised.
Add additional condition in the definition of the term of TxOP Holder to make the device with shared TxOP portion also be a TxOP Holder.
Incorporate the change for CID 163 in doc 11-25/1831r1 with tag #163.
And the corresponding redline change in REVmf D1.0 P277L27,
During the discussion in the adhoc meeting, the resolution has received comments about whether it’s appropriate to always let the STA within shared TxOP be a TxOP Holder for all cases. So more feedback is welcomed for this CID, and if you have any concern/feedback, please respond back to this thread. Thanks.
Regards,
Yanchao Xu
