CID 3480 complains that it's not OK for the
CCA.ind to be sent
well after the CCA has actually changed, in Figure 17-19:
Brian has kindly given this some thought and has provided the following:
- Since
aCCATime is 4usec, averaging of up to 4usec is implied. In path-of-least-resistance implementations, this cuts both ways – it could be 4usec before the CCA goes idle too.
- It is desirable, as you are thinking, for CCA to go idle “immediately” after a PPDU[+SigExt],
and pretty quickly (e.g., <1usec) after non-802.11 energy (e.g. a microwave oven) drops below -62
dBm.
- However, there is no delay parameter defined in clause 6.7.4.2 from the end of a PPDU to CCA going idle
- And, AFAIK, there is no clear
requirement that CCA go idle quickly. For instance, the RX procedure just has requirements on when the PHY needs to assert busy: e.g., “17.3.12 Receive PHY: Also, in this case, the CCA of the OFDM PHY shall indicate a busy medium for the intended duration
of the transmitted frame, as indicated by the LENGTH field.”
- Related, 8.3.5.12.2 Semantics of the service primitive does say “The parameter value is BUSY if the assessment
of the channel(s) by the PHY determines that the channel(s) are not available. Otherwise, the value of the parameter is IDLE.” However, if the PHY determination takes some time, then the IDLE signaling could be delayed
- As well, for 14B in an 54 Mbps 11a/g PPDU, it might be a struggle for CCA to go idle at the immediate end of the
PPDU, especially for an 11a/g implementation, because it may not be able to determine the PPDU duration before the PPDU has already ended.
- From Figure 10-29—EDCA mechanism timing relationships, slot timing depends on PHY-RXEND.ind,
not PHY-CCA(IDLE).ind. So slot timings are a don’t care. Indeed, as long as CCA goes idle within SIFS, we’re OK.
So I can’t say CCA going idle quickly at the exact end of a
PPDU is required or especially desirable or even possible for very short PPDUs. And it’s NEVER been drawn so.
On the other hand, CCA going idle quickly at the end of non-802.11 interference does seem important for slot synchronization. And maybe this points out a problem with Figure 10-29??? That
discussion I’m happy to continue, but I’ll stop for now …
If you have any thoughts on any of the above, please do share them!
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
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