| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Thank you Mark for your questions.
I see your points, but as you know from our emails exchange we do not have a clear consensus
on how the interface between MAC and PHY should be interpreted (SAP or no SAP). I think more discussions in a larger group are necessary to decide if deleting “.confirm” could
have any negative impact on specs. For the other questions please see my reply inline. George From: Mark RISON [mailto:m.rison@xxxxxxxxxxx]
Thanks for these proposed resolutions, George. I have the following comments: What about 8.3.5.12.4 [PHY-CCA.indication]?
[George] I do not understand this question.
Instruct the editor to replace in Clause 8.3.5.3.4 [PHY-DATA.indication]:
“The effect of receipt of this primitive by the MAC is unspecified”
With
“The receipt of this primitive by the MAC entity causes the MAC to collect the data octet provided by the PHY layer and to add it to the newly created A-MPDU in the current MAC RX state.” What is “the newly created A-MPDU”? There is nothing in 8.3.5.3 about
creation of anything. [George] Please refer to Figure 5-1- MAC data plane architecture What if the PPDU doesn’t contain an A-MPDU? [George] Please refer
to Figure 5-1- MAC data plane architecture What is “the current MAC RX state”? [George] This is a good point. I could replace “MAC RX state” with “MAC MSDU receiving flow”
Instruct the editor to replace in Clause 8.3.5.11.4 [PHY-CCARESET.confirm]:
“The effect of receipt of this primitive by the MAC is unspecified”
With
“The receipt of this primitive by the MAC entity causes the MAC to determine that the PHY CCA state machine was reset followinga PHY-CCARESET.request and the MAC may collect the observed IPI values if
they requested in the PHY-CCARESET.request primitive.” “causes the MAC to determine that the PHY CCA state machine was reset” is no better than “is unspecified”. Maybe the primitive
should only be issued if dot11RadioMeasurementActivated is true and IPI-STATE in the .request was IPI-ON? [George] Maybe. I think this should be discussed in the group. I do not see strong arguments in the text for
it. Also missing a space in “followinga”. [George] Good catch.
Instruct the editor to replace in Clause 8.3.5.13.4 [PHY-RXSTART.indication]:
“The effect of receipt of this primitive by the MAC is unspecified”
With
“The receipt of this primitive by the MAC entity causes the MAC to change the state from CS/CCA to RX state and prepare for the creation of a new A-MPDU from the octets provided by PHY layer during the
MAC RX state.” I don’t think the MAC has “CS/CCA” and “RX” states. These are states of the PHY (see Figures 15-9, 17-20, 19-27, etc.). [George] This is a good point. I should probably replace “MAC RX state” with “MAC MSDU receiving flow”
What if the PPDU doesn’t contain an A-MPDU? [George] Please refer to Figure 5-1- MAC data plane architecture
Instruct the editor to replace in Clause 8.3.5.16.4 [PHY-CONFIG.confirm]:
“The effect of receipt of this primitive by the MAC is unspecified”
With
“The receipt of this primitive by the MAC entity causes the MAC to determine that the PHY has received and successfully applied the parameters in the PHY-CONFIG.request primitive.” How can the PHY not receive the PHY-CONFIG.request? [George] There are many ways in something could go wrong. I do not plan to explain the thinking behind the design, just make sure that
the resolution addresses the comment. We could discuss in the group your assumption that nothing could ever go wrong in this exchange between PHY and MAC.
How can the PHY not successfully apply the parameters (assuming the MAC passed valid ones in, which a conformant MAC shall)? [George] Same as above. How does the MAC determine that the parameters were not successfully applied? A timeout? That's not appropriate for a
SAP with purely local effect, and would be horrible, and would need to be specified anyway. [George] I see your points, but as you know we do not have a clear consensus , more discussions
are necessary. How does the MAC determine which parameters were not successfully applied? Even if there were a .confirm for this, it would
need to carry a set of result codes identifying the particular problem parameter. And what would the MAC do? Try again with a different (random?) value for the parameter in the hope the PHY will accept it? [George] Same as above. I don’t think any of this makes sense. A (conformant) MAC will generate a valid set of config parameters, which a (conformant)
PHY will receive and apply, instantaneously from a SAP perspective. No .confirm is necessary or makes sense. 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: George Calcev [mailto:George.Calcev@xxxxxxxxxx]
Dear Dorothy, A contribution (https://mentor.ieee.org/802.11/dcn/19/11-19-0656-00-000m-proposed-comment-resolutions-2309-2310.doc
) with resolutions for the CIDs: 2309, 2310 was uploaded to the mentor site. Please consider it for the group discussion. Thanks, George 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 |