Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[STDS-802-11-TGM] Discussion on LSIG Reserved bit, EVM of PPDU vs Data field, PER as PSDU error rate (etc)

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

Hi

 

In regards to resolving CIDs 18, 14, 15, 527 in CC35 on 11meD0.0, several questions came up for which wider discussion is solicited:

 

1)

The RESERVED Bit in the LSIG SERVICE field has not always been used as a reserved bit:

  • Reportedly there is some (11n-era) use of it where it was set to a non-zero value
  • Reportedly there is some (much wider) use of the RESERVED bit as an 11be-style “Validate” bit, such that a non-zero value is treated as akin to a parity error
    • Note: when 11a/g was defined, there was no definition of “RESERVED” that applied to the PHY clause

 

This CID could be resolved via:

  • Explicitly allow 11be-style “Validate” behavior for the RESERVED bit (conditioned on a MIB variable since not all legacy might perform this checking)
  • Add a NOTE to the effect that transmitters setting the RESERVED bit to a value other than 0 in a PPDU might find that the PPDU is not received successfully at peer STAs, and CCA might not be reported as busy at peer STAs.
  • No change: i.e. “Bit 4 is reserved. It shall be set to 0 on transmit and ignored on receive.”

 

Discussion, alternative resolutions and recommendations are welcome.

 

2)-5)

Three CIDs relate to cleaning up usage of improper terms in the PHY clauses (such as “frame” and “packet”). “Frame” is very clearly defined as MPDU and shouldn’t be used when PSDU or PPDU is meant instead. Similarly, although “packet” is a familiar term due to its usage in the cellular industry, yet it doesn’t map well to IEEE + IETF terminology where the L1 terms are PSDU, PPDU and transmission, the L2 terms are MSDU, MMPDU, A-MSDU, frame, MPDU and A-MPDU and the L3 term is the packet (“IP packet”, etc).

 

2)

The EVM test is very vague in its use of packets / frames /etc. Specifically, is the EVM calculated over the Data field or the entire PPDU (including LSTF, LLTF, …)? Test equipment vendors interpret the calculation as performed over the Data field, but the language itself is very unclear. Looking at clause 17 for instance:

 

 

 

Arguments that EVM is calculated over the Data field only

  • Primary
    • Step g) refers to “data-carrying subcarriers”. Taken together with “data OFDM symbols” in step “f)” this implies only the Data field is considered
    • The last line says “random data shall be used for the symbols”, where “the symbols” refers back to “packets … shall be at least 16 OFDM symbols long”. Since it only makes sense for the Data field to hold random data, then it seems that “packets” is being used as a synonym for “Data field”
      • If so, when Lp is defined as “the length of the packet” then this is the length of the Data field
    • It is not explained how to find the closest constellation point for LSTF or LLTF, and indeed the LSTF is a mix of +-sqrt(13/6) * (1+j) and 0, and this is nowhere described as a constellation point or symbol point
      • i.e. “the dog that didn’t bark”
    • Related, it is arguable if the LSIG contains “data carrying” subcarriers or not.
    • LSTF is arguably made up of 10 short symbols, which would be an anomalously high proportion of the “16 OFDM symbols”
  • Secondary
    • LSTFs don’t have to be transmitted very cleanly
    • The EVM is compared against an MCS-dependent threshold, and that MCS only appears in the Data field

Arguments that EVM is calculated over the entire PPDU

  • Primary
    • Apart from some ambiguous cases, “packet” is used unambiguously elsewhere to mean the entire PPDU – e.g.,
      • Equation (17-2):
      • Annex I where “I.1.8 The entire packet for the BCC example / The packet in its entirety is shown in the tables in this subclause. … short training field sequence … long training sequence … SIGNAL field …Data field ”
      • “The CCA of the OFDM PHY shall indicate a busy medium for the intended duration of the transmitted packet.”

… so then Lp plausibly refers to the entire PPDU

    • The first highlighted use of “frame”, at “a)” signifies PPDU, but if so then the second and third highlighted use of “frame” implies that EVM is calculated over the whole PPDU.
    • Step “h)” refers to all errors in a PPDU.

Arguments that EVM is calculated over the LSIG and Data field

  • According to the definition at P2900L42, Ck modulating tones are either data, pilots or training symbols, so the 48 Ck during LSIG are certainly data symbols. Arguably data symbols modulate data-carrying subcarriers, and if this is accepted then the LSIG falls within the scope of g)

 

It is proposed to clarify that EVM is calculated over the Data field only.

 

Discussion, alternative directions and recommendations are welcome.

 

3)

The PHY clauses have a mix of “Frame Error Rate” (which is a layer violation) and “Packet Error Rate”. To correct and harmonize these terms, the proposal is to replace “frame error rate” and “packet error rate” by “PSDU error rate”: i.e., number of errored PSDUs divided by the number of transmitted PSDUs. This works well with the existing text, such as “The PSDUpacket error ratio (PER) shall be 10% or less when the PSDU length is 1000 octets”

 

Discussion, alternative resolutions and recommendations are welcome.

 

4)

The definition of aSIFSTime has not been refreshed for the signal extension, the AGC or TRN fields (used in the in millimeter wave PHYs) and is not future proofed for the PE of 11ax. In these cases, “end of the last symbol of a frame on the WM” is ambiguous or even incorrect. The proposal is to repurpose some suitable 11ax language, i.e., “later of the end of a PPDU or the end of the signal extension if present, on the WM”. Then change:

 

“aSIFSTime Integer The nominal time (in microseconds) that the MAC and PHY require in order to receive the last symbol of a frame on the WM, process the frame, and respond with the first symbol on the WM of the earliest possible response frame. See 10.3.7 (DCF timing relations).”

 

... to something like:

 

“aSIFSTime Integer The nominal time (in microseconds) that the MAC and PHY require from reception of the later of the end of a PPDU or the end of the signal extension if present, on the WM, until the MAC and PHY have processed the PPDU and any frame(s) therein, and responded with the start on the WM of the PPDU containing the earliest possible response frame. See 10.3.7 (DCF timing relations).”

 

Discussion, alternative resolutions and recommendations are welcome.

 

5)

The definition of aRxPHYDelay has not been refreshed for the signal extension and is not future proofed for the PE of 11ax. In these cases, “end of the last symbol” is incorrect. The proposal is to repurpose some suitable 11ax language, i.e., “later of the end of a PPDU or the end of the signal extension if present, on the WM”. Then change:

 

“aRxPHYDelay Integer The nominal time (in microseconds) that the PHY uses to deliver the last bit of a received frame from end of the last symbol on the WM to the MAC.”

 

… to something like

 

“aRxPHYDelay Integer The nominal time (in microseconds) that the PHY uses to deliver the last bit of a received PSDU to the MAC from the later of the end of the PPDU or the end of the signal extension if present, on the WM.”

 

(As background, for OFDM, originally aSIFSTime = 16us = aRxPHYDelay (12us) + aMACProcessingDelay (2us) + aRxTxTurnaroundTime (2us). However, at 2.4 GHz, aSIFSTime = 10us so we have aSIFSTime = 10us = aRxPHYDelay (6us) + aMACProcessingDelay (2us) + aRxTxTurnaroundTime (2us). Thus, we see that aRxPHYDelay does not include the signal extension.)

 

Discussion, alternative resolutions and recommendations are welcome.

 

Best regards

Brian

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