[STDS-802-11-TGM] + aSlotTime (CID 229)
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Per the action I took in San Antonio, this is explain why the "+ aSlotTime"s
in the stuff related to the various timeouts anchored off PHY-TXEND seem
wrong to me, and what I think the right answer is.
The things which have a "+ aSlotTime" (or two) are:
- The NAV for RTS/CTS cancel timeout (9.3.2.4)
- The NAV for L-SIG cancel timeout (9.3.2.4 also)
- The CTSTimeout (9.3.2.6)
- The ACKTimeout (9.3.2.8)
- Some CFP thing (9.4.4.4)
- The EDCA successful tx timeout (9.19.2.5)
Let's look at the three which just have one "+ aSlotTime" (namely the ACK,
CTS and EDCA timeouts).
These timeouts are all specified as:
aSIFSTime + aSlotTime + aPRSD
where aPRSD is aPHY-RX-START-Delay.
In all cases, the timeout needs to be, starting from the time the last symbol
goes on the air (as indicated by PHY-TXEND.confirm [*]) the sum of:
1) The time it takes the transmission to get to the peer
2) The SIFS time the peer responds after
3) The time it takes the response to get back
4) The time it takes the PHY to tell the MAC that something is coming back
5) The time it takes the MAC to act on this and cancel the timeout
1)+3) is easy, it's the aAirPropagationTime.
2) is easy, it's aSIFSTime.
5) is reasonably easy: we can treat is as aMACProcessingDelay (though the
description in 6.5.4.2 does not explicitly cover cancelling timeouts).
So the question is what 4) is. The problem is that aPRSD is defined
as "The delay, in microseconds, from a point in time specified by the PHY to
the issuance of the PHY-RXSTART.indication primitive." and the only
PHY which actually defines the point in time is the FH PHY (which, ironically,
we've agreed to euthanise):
The delay from the start of the preamble to the issuance of the RXSTART.
indication primitive by the PHY.
All the other PHYs fail to specify the "point in time".
If we assume we will fix this, and say that the aPRSD is the time starting
from the time the start of the PPDU goes on the air [#], then 4) would be
just aPRSD (note it would then include the aRxRFDelay and aRxPLCPDelay).
So the correct timeout would be:
aAirPropagationTime + aSIFSTime + aPRSD + aMACProcessingDelay
and since aSlotTime is:
aCCATime + aRxTxTurnaroundTime + aAirPropagationTime + aMACProcessingDelay
the correct timeout is:
aSIFSTime + aPRSD + aSlotTime - aCCATime - aRxTxTurnaroundTime
and not:
aSIFSTime + aPRSD + aSlotTime
Mark
[*] Including any signal extension, in fact.
[##] I'm not sure I can explain the 25 us for OFDM (cf. 24 for ERP)
or 33 us for HT, mind you!
--
Mark RISON, Systems Architect, Wi-Fi English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0ZT Fax: +44 1223 TBCTBC
ROYAUME UNI WWW: http://www.samsung.com/uk
_______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this
CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
SELF SERVICE OPTION:
Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and
then amend your subscription on the form provided. If you require removal from the reflector
press the LEAVE button.
Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________