| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| 40 | Brian Hart | 0 | 2012 | 19.3.2.4 | 1638 | 1638.00 | 19.3.2.4 | CCA architecture is ambiguous. IsCCARESET a rare event or an every-slot event? I think CCA should be reset at the end of a PPDU (arguably this is described in 7.3.5.9.3 and - upon NAV reset - 9.3.2.4), immediately after a frequency hop (don't care if this is described or not) and immediately after a channel change (kinda obvious - have to reset a lot - but still such guidance could be added). But still, is CCA reset on slot boundaries or not? The language on this topic is absent/unclear. E.g. clause 14, 16, 17 and 19 (2.4 GHz clauses - search for "slot") and 6.5.4.2 aCCATime definition imply that the PHY is slot aware but clauses 18 and 20 are silent. Further, how does the PHY becomes aware of the slot boundaries? 19.3.2.4 implies it is sync-ed to the last frame on the medium (not via a regular train of CCARESETs). BUT there is no requirement that the MAC clock and PHY clock be synced, or primitive to assure us of this, so in the absence of packets the PHY's estimate of slot timing can be expected to diverge from the MAC's estimate. So 19.3.2.4 does not seem to be a complete answer . | Does the PHY need to know slot timings? Be specific for all PHYs. Or is 2.4 different from 5 GHz??? If the PHY needs to know, define how does the PHY sync up initally? For all PHYs. e.g. "From the last *PPDU*"? Then define how the PHY stays in sync? Via regular CCARESETs? Or other? | ||
| 43 | Brian Hart | 0 | 2012 | 18.4.4 | 1623 | 1623.00 | 18.4.4 | 1) From 9.3.7, aCCATime +
RXTXTurn + aAirProp + aMACProcessingDelay must equal slot time. Yet, as
written in clause 18.4.4 and likely other PHY clauses too, these numbers are
all "<" so must add up to "<aSIFSTime. At the very
least, these parameters should be "<=" 2) If the PHY does a bit better on one measure - e.g. aCCATime - it should be able to relax another measure - e.g. RXTXTurn. Yet, if it can do everything ~instantaneously, it will massively undercut SIFS and cause non-reception at the initiator. Suggestions: a) explain/define that the parameters in the equations in 9.3.7 are "max times at design time". Actual implemations may use different values and may even add a wait time so sifs/slot times are consistent. b) at implementation time, allow one PHY parameter to be traded against another as long as the sum is consistent (this is moot for the MAC since that has only 1 param - altho perhaps allow a VS trade btw MAC and PHY?). |
As in comment | ||
| 45 | Brian Hart | 0 | 2012 | 20.1.1 | 1669 | 1669.00 | 20.1.1 | Re "An HT non-AP STA shall support all ...", 802.11 has three distinct concepts: mandatory rates, basic rates and supported rates (which is very confusing for us PHY guys). I think this text is echoing the language in 20.3.5 which explicitly refers to "mandatory", and obviously any specificaiton on Basic/Supported rates is outside the scope of the PHY - and indeed the MAC since it is an SME parameter | Change language using "supported" to language using "mandatory" | ||
| 56 | Dorothy Stanley | 0 | 2012 | 18.4.4 | 1622.00 | 18.4.4 | 18.4.4: 1) aCCATime + RXTXTurn +
aAirProp + aMACProcessingDelay must equal slot time. Yet, as written in this
clause and likely other PHY clauses too, these numbers are all
"<" so must add up to "<aSIFSTime. At the very least,
these parameters should be "<=" 2) If the PHY does a bit better on one measure - e.g. aCCATime - it should be able to relax another measure - e.g. RXTXTurn. Yet, if it can do everything ~instantaneously, it will massively undercut SIFS and cause non-reception at the initiator. Suggestions: a) explain/define that the parameters in the equations in 9.3.7 are "max times at design time". Actual implemations may use different values and may even add a wait time so sifs/slot times are consistent. b) at implementation time, allow one PHY parameter to be traded against another as long as the sum is consistent (this is moot for the MAC since that has only 1 param - altho perhaps allow a VS trade btw MAC and PHY?). |
Fix, as in comment | |||
| 66 | Jens Tingleff | 0 | 2012 | 20.3.7 | 1693 | 1693.00 | 20.3.7 | Equation 20-60 and 20-61 refer to a variable N^TONE_HT-Duplicate which is alleged to be defined in table 20-8. Sadly, there is no such variable in that table. | Add an entry or a Note 4 which adequately defines N^Tone_Field for Non-HT modulations | ||
| 96 | Mark Hamilton | 0 | 2012 | 18.3.10.6 | 1614 | 12 | 1614.12 | 12 | 18.3.10.6 | Requirement for energy detect is unclear, the wording is inconsistent. For example, it first says, "The start of a valid OFDM transmission at a receive level ... shall cause CS/CCA to indicate busy..." The next sentence says, "If the preamble portion was missed, the receiver shall hold the CCA signal busy ..." So, does the signal 'go to' ("indicate") busy at the start of OFDM being detected at the right level, and then 'stay' ("hold") busy only as long as signal is detected about that level? That is, if no OFDM is detected to start the busy indication, does it ever go busy based solely on energy detect? Note that there is no time specified for the energy detect sentence, further implying that this detection does not start the busy indication, but rather just continues it. And, further, the next paragraph talks about the CCA-ED facility as optional, or only used in certain regulatory domains, where that (purely energy detect) is required. | Clarify this section. "Common knowledge" seems to think that pure energy detect must be used as one method for sensing a busy medium, but that seems to be contradicted by this text. However, the text is rather unclear. |
| 299 | Peter Ecclesine | 0 | 2012 | 18.3.10.6 | 1614 | 22 | 1614.22 | 22 | 18.3.10.6 | The statement "The CCA-ED shall not be required for license-exempt operation in any band." is incomplete, and fails to describe that CCA-ED may be required by regulation. | Change to "Unless required by regulation, CCA-ED shall not be required for license-exempt operation in any band." |
| 355 | Youhan Kim | 0 | 2012 | 20.3.11.7.5 | 1713 | 1713.00 | 20.3.11.7.5 | rem() is undefined (within step (c)). | Define the function rem(). |
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 _______________________________________________________________________________