| 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 ---
Hi Jon, Interesting questions. Some thoughts: in 6.5.4.2 – the specification states “The values assigned to the parameters are as specified in the PLME SAP interface specification contained
within each PHY subclass of this standard. Not all parameters are used by all PHYs defined within this standard.” Taking a quick look at the PHYs I find: In the DSSS PHY @ 2883.33:
aRxPHYStartDelay: 192 μs In the HR PHY @ 2909.22: aRxPHYStartDelay: 192
μs for long preamble and 96
μs for short preamble In the OFDM PHY @ 2968.36: aRxPHYStartDelay: 20
μs 40
μs 80
μs (in table form for different BWs) In the ERP PHY @ 2981.27: aRxPHYStartDelay: 20
μs for ERP-OFDM, 192
μs for ERP-DSSS/CCK with long preamble, and 96
μs for ERP-DSSS/CCK with short preamble In the HT PHY @ 3079.40: aRxPHYStartDelay: 28
μs for HT-mixed format, 24
μs for HT-greenfield format In the DMG PHY @ 3137.38: aRxPHYStartDelay: DMG control mode: 10
μs; DMG SC and SC lowpower modes: 3.6
μs(#64) In the VHT PHY @ 3255.30: aRxPHYStartDelay 36 + 4
× the maximum possible value for NVHT-LTF supported + 4 In the TVHT PHY @ 3318.27: aRxPHYStartDelay (36 + 4
× the maximum possible value for NVHT-LTF supported + 4)
× 7.5 (6 and 7 MHz channels) or 5.625 (8 MHz channels) In the S1G PHY @ 3318.27:: 600
μs for S1G_1M preamble; 280
μs for S1G_SHORT preamble and S1G_LONG preamble. These all appear to be integers and not a list of integers. So based on the above I think this comment should be rejected,
aRxPHYStartDelay is defined as an integer in each of the PHYs. Joseph From: ***** 802.11 REVm - Revision Maintainance List ***** <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>
On Behalf Of Jon Rosdahl --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Greetings, This email is discussing CID 4738 (GEN) see
text in D3.0 p755.34.
Comment: aRxPHYSTartDelay needs to be a set of delays indexed by PPDU format. The MAC then needs to use the right delay in the particular context, e.g. if it's expecting an immediate response and that
has to be in a 1 Mbps long-preamble CCK PPDU then it should use the value for that, buf if the response has to be a 24 Mbps OFDM PPDU it should use the value for that Proposed Change:
At the referenced location in the middle cell change "Integer" to "List of integers indexed by PPDU format; the STA chooses the largest value among all those corresponding to the PPDU formats
that are valid at the point the PHY start delay is required" Discussion: Note that this CID is similar to CID 1413 - with resolution: REJECTED (GEN: 2018-10-05) Reject. The proposed change is insufficient; normative text describing how
this list of integers is used or indexed, and when a worst case must be used, is required. So the question to you all is if aRxPHYSTartDelay type or description needs to be changed. I look forward to your feedback, Jon ----------------------------------------------------------------------------- Jon Rosdahl Engineer, Senior Staff
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 |