Jing Ma The MAC may not be able to Please add specification about Rejected section – determine whether continue how the MAC determines 27.9.2.4 already backoff countdown because the whether continue backoff clarifies this MAC may not get the clear countdown based on the IPI BUSY/IDLE indication about the values provided by the PHY after medium from the PHY regarding issue PHY-CCARESET.request. procedure described in 27.9.2 and Or add a STATE parameter 28.3.21 HE receive procedure. indicating the medium Further details about the "BUSY/IDLE" to interaction between the MAC and primitive PHY should be added. which is similar with According to the precedure in PHY.CCA.indication primitive 27.9.2.1(General), the MAC issues and sends PHY-CCARESET.request primitive to the PHY. Then no further description about how the PHY reacts and indicates MAC the medium "BUSY" or "IDLE" in current ax draft. If follow the specification of primitive in baseline (see 8.3.5.10 in 802.11-2016), the PHY reset the CCA state machine and send a PHY-CCARESET.confirm to the MAC with observed IPI values which are the values not a BUSY/IDLE indication. As a result, the MAC may not be able to determine whether continue backoff countdown because there seems no clear indication from the PHY saying the medium is BUSY/IDLE Yuichi There is no requirement on when Define requirement on how the Rejected the – Morioka the STA that issued the HE STA issues the BUSY normal rules for CCARESET.request primitive during indication when a) the inter-BSS BUSY indication the inter-BSS PPDU re-issues the is still being sent and b)another apply. BUSY indication. If there is no such HE STA starts an SR PPDU requirement, multiple SR transmission. transmissions will just collide with one another. Liwen Chu Add the rule that the AIFS rule As in comment Revised AIFS – needs to be respected. does not need to be explicitly mentioned because it is implicit when naming the which is “EDCAF” always gated by the medium condition. Apply the changes as defined in doc 1852r1.
Jing Ma The MAC may not be able to determine whether continue backoff countdown because the MAC may not get the clear BUSY/IDLE indication about the medium from the PHY regarding procedure described in 27.9.2 and 28.3.21 HE receive procedure. Further details about the interaction between the MAC and PHY should be added. According to the precedure in 27.9.2.1(General), the MAC issues and sends PHY-CCARESET.request primitive to the PHY. Then no further description about how the PHY reacts and indicates MAC the medium "BUSY" or "IDLE" in current ax draft. If follow the specification of primitive in baseline (see 8.3.5.10 in 802.11-2016), the PHY reset the CCA state machine and send a PHY-CCARESET.confirm to the MAC with observed IPI values which are the values not a BUSY/IDLE indication. As a result, the MAC may not be able to determine whether continue backoff countdown because there seems no clear indication from the PHY saying the medium is BUSY/IDLE Please add specification about how the MAC determines whether continue backoff countdown based on the IPI values provided by the PHY after issue PHY-CCARESET.request. Or add a STATE parameter indicating the medium "BUSY/IDLE" to primitive which is similar with PHY.CCA.indication primitive Rejected – section 27.9.2.4 already clarifies this Yuichi Morioka There is no requirement on when the STA that issued the CCARESET.request primitive during the inter-BSS PPDU re-issues the BUSY indication. If there is no such requirement, multiple SR transmissions will just collide with one another. Define requirement on how the HE STA issues the BUSY indication when a) the inter-BSS is still being sent and b)another HE STA starts an SR PPDU transmission. Rejected – the normal rules for BUSY indication apply. Liwen Chu Add the rule that the AIFS rule needs to be respected. As in comment Revised – AIFS does not need to be explicitly mentioned because it is implicit when naming the “EDCAF” which is always gated by the medium condition. Apply the changes as defined in doc 1852r1.
11-17-1852-01-00ax-cr-for-27-9.docx