This email is to kick off some discussion on how to specify the max PPDU duration and related requirements that are dependent on the max PPDU duration (e.g., maximum NGV MPDU length).
The way NGV PPDU duration limits and maximum NGV MPDU size are described in the spec, should be consistent. (See background discussion below.)
Should we progress by:
1) Use the specified 10 968 microseconds max PPDU duration and align the rest of the PHY and MAC clauses using this value.
2) Acknowledging that the "actual" max PPDU duration is not specified in the 802.11 spec, but is specified by regulations and that these regulations are region dependent and subject to change. If so we should specify the max PPDU duration and related requirements based on the "actual" max PPDU duration.
If we decide to move forward with 2), we would need to align the PHY and MAC clauses so that the "actual" max PPDU (defined by regulations) defines the requirements. (This will probably mean that formulas will need to be added to define all "max PPDU duration" dependent requirements (e.g., the maximum MPDU length). Also, should we make it clear in the specification the max PPDU duration may vary based on the regulatory domain.
Please provide your thoughts on how we proceed.
Background:
During the TGbd teleconference on 24 August comment resolutions were proposed for CIDs 2001 and 2162 in 11-21/1372r2. The resolution of these CIDs and some PHY CIDs (e.g., CID 2012 and 2147) are dependent on how the 802.11bd amendment will specify the maximum PPDU size and duration, the maximum MPDU length, and how these values are specified.
Currently in the draft:
802.11bd D2.0 specifies that the maximum PPDU size in the following locations (page.line reference):
(34.12) PPDU size is 246 780 octets
(119.35) aPPDUMaxLength 121 320 octets (NOTE 1—This is the maximum length in octets for a NGV PPDU with a bandwidth of 20 MHz, NGV-MCS 9, and 2 spatial streams, and limited by 674 possible data symbols in aPPDUMaxTime. This is the maximum PSDU length an NGV PHY could support assuming no restrictions in MAC. See Clause 10.3.2 (Procedures common to the DCF and EDCAF) and Clause 9.2.4.7.1 (General) for additional restrictions on the maximum number of octets the MAC could support.)
802.11bd D2.0 specifies that the maximum PPDU duration in the following locations (page.line reference):
(34.27) PPDU duration is 10 968 microseconds
(39.63) "A STA shall not transmit an NGV PPDU that has a duration (as determined by the PHY-TXTIME.confirm primitive defined in 6.5.6 (PLME-TXTIME.confirm)) that is greater than aPPDUMaxTime defined in Table 32-19 (NGV PHY characteristics)."
(58.1) Table 31-1 provides the maximum MPDU length corresponding to a maximum PPDU duration of 5 484 μs.
(119.33) aPPDUMaxTime 5.484 ms.
During the teleconference it was noted that the specified PPDU duration should be 10 967 microseconds in the spec. Though, some regulatory bodies limit the PPDU duration and in these regulatory domains the allowed PPDU duration may be shorter. The PPDU duration limits the maximum MPDU length for some MCSs (this is dependent if the MCS is PPDU duration limited or MPDU length limited). Therefore, when the PPDU duration is limited to less than 10 967 microseconds, the MSDU length is also reduced for some MCSs.
Also, it should be noted that If we use a table to set the maximum MPDU length based a the maximum PPDU duration, the table will only provide information for the specific max PPDU duration used to generate the table. Given the 7991 limit on the max MPDU length if the actual maximum PPDU length is shorter there is really no way to know how the shorter PPDU length will impact the maximum MPDU length for some MCSs. If we create a table based on the shortest maximum PPDU length, then the table could be used to estimate the maximum MPDU length for longer maximum PPDU lengths. But, creating a table for the "shortest" maximum PPDU duration may lead to confusion as to what the actual maximum PPDU duration is. Also it may not be clear to the reader as to how estimation can be done, so an equation would probably be clearer.
--