[STDS-802-11-TGM] FW: [STDS-802-11-TGM] Do STAs inherit or aggregate PHYs?
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Best Regards,
Adrian P STEPHENS
Tel: +44 1954 204 609 (office)
Tel: +44 7920 084 900 (mobile)
Skype: adrian_stephens
----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
-----Original Message-----
From: Perahia, Eldad
Sent: Friday, November 30, 2012 2:02 PM
To: Stephens, Adrian P; Hamilton, Mark; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Cc: Vinko Erceg
Subject: RE: [STDS-802-11-TGM] Do STAs inherit or aggregate PHYs?
Yes, this was a conscious decision to require HT_MF devices to have some level of PHY detection capability to enhance coexistence. The minimum requirement for an HT_MF device is to check the CRC of HT-SIG in an HT_GF PPDU (20.1.4) and hold CCA signal busy for a HT_GF signal received at a level of -72 dBm or greater (20.3.21.5.2).
Specifically to the question of how an HT_MF devices detects a valid HT_GF signal, in 20.1.4 "HT-greenfield format (HT_GF): HT packets of this format do not contain a non-HT compatible part. Support for HT-greenfield format is optional. An HT STA that does not support the reception of an HT-greenfield format packet shall be able to detect that an HT-greenfield format packet is an HT transmission (as opposed to a non-HT transmission). In this case, the receiver shall decode the HT-SIG and determine whether the HT-SIG cyclic redundancy check (CRC) passes."
Regards,
Eldad
-----Original Message-----
From: Stephens, Adrian P
Sent: Friday, November 30, 2012 2:20 AM
To: Hamilton, Mark; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Cc: Perahia, Eldad; Vinko Erceg
Subject: RE: [STDS-802-11-TGM] Do STAs inherit or aggregate PHYs?
Hello all,
This is not a mistake. 802.11n took the conscious decision to require a non-GF-capable .11n STA
to decode the GF signal field. Agreed this means that even a non-GF-capable STA supports
certain elements of GF operation.
This was done to avoid requiring "protection" for GF PPDUs when there were non-GF STAs present.
I'm sure Eldad or Vinko will correct me if I am wrong.
Best Regards,
Adrian P STEPHENS
Tel: +44 1954 204 609 (office)
Tel: +44 7920 084 900 (mobile)
Skype: adrian_stephens
----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
-----Original Message-----
From: ***** IEEE stds-802-11-tgm List ***** [mailto:STDS-802-11-TGM@xxxxxxxx] On Behalf Of Hamilton, Mark
Sent: Thursday, November 29, 2012 5:57 PM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] Do STAs inherit or aggregate PHYs?
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Mark,
> how does a "receiver that does not support the reception of HT-GF format PPDUs" know whether it is dealing with a "valid HT-GF signal" ...
Yeah, I just noticed that, too. Probably needs to be cleaned up. Unless a PHY expert can clarify that there is a chance of such a scenario (a STA that can't receive HT-GF PPDUs completely, but can receive well enough to know that a signal is an HT-GF PPDU signal...)?
Mark
-----Original Message-----
From: Mark Rison [mailto:m.rison@xxxxxxxxxxx]
Sent: Thursday, November 29, 2012 10:49 AM
To: Hamilton, Mark
Cc: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGM] Do STAs inherit or aggregate PHYs?
> I meant the last sentence of the first paragraph of 20.3.21.5.2 and
> the last paragraph of 20.3.21.5.3, which talk about "any signal" (and
> uses -62 dBm consistently) and I read as the 'default' behavior if none of the above rules for various "valid ... signal" situations applies.
Ah, I see. OK, makes sense. Would need to be clarified by:
- Splitting the first para of 20.3.21.5.2 into two paras, so that it is clear the second sentence is not contingent on the first
- Clarifying the intent of "indicate" v "hold" (ISTR you already have a comment on this)
Hm, but how does a "receiver that does not support the reception of HT-GF format PPDUs" know whether it is dealing with a "valid HT-GF signal", in the context of the last para of 20.3.21.5.2/penultimate para of 20.3.21.5.3, though?
Mark
--
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 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
> -----Original Message-----
> From: Hamilton, Mark [mailto:Mark.Hamilton@xxxxxxxxxxx]
> Sent: 29 November 2012 17:42
> To: m.rison@xxxxxxxxxxx
> Cc: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
> Subject: RE: [STDS-802-11-TGM] Do STAs inherit or aggregate PHYs?
>
> Mark,
>
> > Do you mean the 11a/11g ones referred to from 20.3.21.5.1?
>
> No, that would apply only if the STA is getting a PPDU (so not just
> "any signal" but a recognizable
> signal) that is non-HT.
>
> I meant the last sentence of the first paragraph of 20.3.21.5.2 and
> the last paragraph of 20.3.21.5.3, which talk about "any signal" (and
> uses -62 dBm consistently) and I read as the 'default' behavior if none of the above rules for various "valid ... signal" situations applies.
>
> Mark
>
> -----Original Message-----
> From: Mark Rison [mailto:m.rison@xxxxxxxxxxx]
> Sent: Thursday, November 29, 2012 7:00 AM
> To: Hamilton, Mark
> Cc: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
> Subject: RE: [STDS-802-11-TGM] Do STAs inherit or aggregate PHYs?
>
> Hello Mark,
>
> > As for 20.3.21.5, it does seem some clarification could be helpful.
> > But, I assume the intention is that if you do get enough decode to
> > tell the type of PPDU, you apply that rule set, if you can't
> > accomplish that, then you fall back to the more general cases,
>
> Sounds reasonable, but:
>
> > ultimately using only the "any signal"
> > as the least common denominator if all else fails.
>
> Which "any signal" rules are you referring to? Do you mean the
> 11a/11g ones referred to from 20.3.21.5.1, namely -62 dBm for 5G
> (assuming
> 20 MHz channel spacing, and assuming CCA-ED is not required) and
> -76 dBm for 2G4?
>
> Mark
>
> --
> 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 434601
> ROYAUME UNI WWW: http://www.samsung.com/uk
>
>
> > -----Original Message-----
> > From: Hamilton, Mark [mailto:Mark.Hamilton@xxxxxxxxxxx]
> > Sent: 29 November 2012 04:04
> > To: m.rison@xxxxxxxxxxx; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
> > Subject: RE: [STDS-802-11-TGM] Do STAs inherit or aggregate PHYs?
> >
> > Mark,
> >
> > > a non-11n AP *cannot* have both 11g-only and 11a-only STAs
> > > associated at the same time, but an 11n
> > AP *can* have both 11g-only and 11a-only STAs associated at the same time.
> > Unless you're using "sloppy terminology" you can't do this. You can
> > have 2 APs in the same box, one on each band, and each with only one
> > band's type of STAs associated. This is common. You could put 2
> > non-AP STAs in one box and do the
> same thing, but I've rarely seen such a thing.
> >
> > As for 20.3.21.5, it does seem some clarification could be helpful.
> > But, I assume the intention is that if you do get enough decode to
> > tell the type of PPDU, you apply that rule set, if you can't
> > accomplish that, then you fall back to
> the more general cases, ultimately using only the "any signal"
> > as the least common denominator if all else fails.
> >
> > Mark
> >
> > -----Original Message-----
> > From: Mark Rison [mailto:m.rison@xxxxxxxxxxx]
> > Sent: Wednesday, November 28, 2012 5:08 AM
> > To: Hamilton, Mark; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
> > Subject: RE: [STDS-802-11-TGM] Do STAs inherit or aggregate PHYs?
> >
> > Hello Mark,
> >
> > > The point of my "time slicing" view is that [...]
> >
> > OK. I still find it a bit odd that the consequence of the spec is
> > that a non-11n AP *cannot* have both 11g-only and 11a-only STAs
> > associated at the same time, but an 11n AP *can* have both 11g-only
> > and 11a-only STAs associated at the same time. (FAOD: I'm not using
> > sloppy terminology here, I'm using strict terminology: a STA is a
> > device with a single MAC, single MAC address, single PHY, etc.)
> >
> > > > [20.3.21.5.1's "CCA sensitivity requirements for non-HT PPDUs in
> > > > the primary channel are described in 18.3.10.6 and 19.4.7"] how
> > > > do I know what kind of PPDU (if indeed it's an 802.11 PPDU!) I'm
> > > > dealing with, so that I can in turn apply the right ED thresholds?
> > > Similar to other comments (I think I've said this before), the ED
> > > thresholds are based on what kind of PHY _you are_, not the kind
> > > of PHY that is transmitting to you. A clause 18 PHY uses the
> > > clause 18 thresholds. A clause 19 PHY uses the clause 19
> > > thresholds (whether it happens to be detecting a
> > clause 19, clause 17 or clause 16 transmitter). A clause 20 PHY is
> > acting in one or the other
> "mode"
> > > (band), if you will, and uses that mode's thresholds.
> >
> > But that's not what 20.3.21.5 "CCA sensitivity" is saying, is it? It's saying:
> >
> > - If you get a 20M HT PPDU, apply the rules in 20.3.21.5.2 (though
> > I'm a bit unsure how you are supposed to determine whether a signal
> > is a "valid HT-GF signal" if you don't support HT_GF, nor whether
> > the second sentence of the first para is a general statement or
> > contingent on having detected a "valid 20 MHz HT signal" (I think
> > this is related to your concern about "indicate" v "hold"))
> >
> > - If you get a 40M HT PPDU, apply the rules in 20.3.21.5.3
> >
> > - If you get a non-HT PPDU, apply the rules in 20.3.21.5.1, which in
> > turn directs you to apply the 11a or 11g rules
> >
> > So, if you've failed to work out what kind of PPDU you're dealing
> > with (i.e. you weren't able to read the PHY header, so you don't
> > know whether it's a 20M HT PPDU, a 40M HT PPDU, a non-HT PPDU, or
> > some
> > non-802.11 signal), how do you know, as an 11n PHY, which CCA rules to apply?
> >
> > Mark
> >
> > --
> > 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 434601
> > ROYAUME UNI WWW: http://www.samsung.com/uk
> >
> >
> > > -----Original Message-----
> > > From: Hamilton, Mark [mailto:Mark.Hamilton@xxxxxxxxxxx]
> > > Sent: 28 November 2012 06:14
> > > To: m.rison@xxxxxxxxxxx; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
> > > Subject: RE: [STDS-802-11-TGM] Do STAs inherit or aggregate PHYs?
> > >
> > > Mark,
> > >
> > > The point of my "time slicing" view is that this is an implementation trick, outside the Standard.
> > > The Standard only sees one PHY per MAC. An implementation can
> > > change that, only is so much as it continues to behavior and
> > > interoperate as if it followed the Standard. How quickly it can
> > > time-slice, then, is a matter of how it pulls off
> > this hiding of what it's doing.
> > >
> > > Note that there are quite a few things that clearly are intended,
> > > and are done in implementations, but which the Standard doesn't
> > > really cover. Like, a non-AP STA scanning for a new AP while
> > > associated to a current one. Nothing in the way scanning is
> > > discussed implies this is reasonable behavior. But, it doesn't
> > > say you can't either. If you do this within a single band and
> > one PHY, that's one thing. If you do it "multi-band" (and hence
> > "multi-PHY") is that any more of a 'violation' of the Standard?
> > >
> > > That said, yes, I say that a non-11n STA cannot associate to both
> > > an 11g AP and 11a AP at the same time. To do so would be giving
> > > externally visible behavior that the STA has more than one PHY at
> > > the same time, and this is not allowed (I claim), so this does
> > > violate the "implementations can do what
> > they want as long as they appear, externally, to be following the Standard."
> > >
> > > However, APs (even non-11n APs) have 11g STAs and 11a STAs
> > > associated at the same time all the
> time.
> > > But, this is sloppy terminology. Such a device is actually always
> > > (in my experience) two APs in the same physical device. Each has
> > > its own MAC and BSSID, and set of associated STAs. (Even with the
> > > introduction of 11n, I still have yet to have seen an AP which
> > > uses the same MAC/BSSID on both bands.)
> > >
> > > As for your question about what mechanism allows this, the answer
> > > is that in the Standard, there is no mechanism that allows this.
> > > But, again, the rule is that an implementation can do anything it
> > > wants that doesn't violate the Standard in terms of externally
> > > visible behavior. How this is implemented is completely
> > > independent of how the Standard describes SAP, MIB,
> > etc. And, nothing says it is "above the MAC" for that matter; in
> > fact it most likely is done within the MAC implementation.
> > >
> > > > Won't this cause unfairness, for (LR/)DSSS transmissions?
> > > In a very small (probably undetectably small) way, yes, it is unfair. What can I say? Things
> > change.
> > > Legacy devices don't change. As a result, life isn't fair. :)
> > >
> > > > how do I know what kind of PPDU (if indeed it's an 802.11 PPDU!)
> > > > I'm dealing with, so that I can in
> > > turn apply the right ED thresholds?
> > > Similar to other comments (I think I've said this before), the ED
> > > thresholds are based on what kind of PHY _you are_, not the kind
> > > of PHY that is transmitting to you. A clause 18 PHY uses the
> > > clause 18 thresholds. A clause 19 PHY uses the clause 19
> > > thresholds (whether it happens to be detecting a
> > clause 19, clause 17 or clause 16 transmitter). A clause 20 PHY is
> > acting in one or the other
> "mode"
> > > (band), if you will, and uses that mode's thresholds.
> > >
> > > Mark
> > >
> > > -----Original Message-----
> > > From: Mark Rison [mailto:m.rison@xxxxxxxxxxx]
> > > Sent: Tuesday, November 27, 2012 9:34 AM
> > > To: Hamilton, Mark; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
> > > Subject: RE: [STDS-802-11-TGM] Do STAs inherit or aggregate PHYs?
> > >
> > > Hello Mark,
> > >
> > > Thanks for your reply.
> > >
> > > > > You cannot have a STA with both an 11g PHY and an 11a PHY
> > > > > (because a STA can only have one PHY)
> > > > [OK if] implementation actually has two, and sort of fakes this
> > > > one-at-a-time part
> > >
> > > Well, how far do you think the time-slicing goes? I have no
> > > problems with the notion that something above the MAC could choose
> > > to flick this or that switch, and then cause the MAC to use this
> > > or that PHY for the duration of participation in a BSS (e.g.
> > > association, in the case of an infrastructure BSS,
> > membership, in the case of an IBSS).
> > > However, I see nothing in the spec which allows finer time-slicing than that.
> > >
> > > So, specifically, would you accept that a non-11n STA (being the
> > > thing which has a unique MAC address) could not be associated to
> > > an 11g-only AP and an 11a-only AP at the same time, and that a
> > > non-11n AP cannot have both 11g STAs and 11a STAs associated at
> > > the same time -- though an 11n AP could have 11g- only
> > STAs and 11a-only STAs associated at the same time?
> > >
> > > If you wouldn't, then what mechanisms would the thing above the
> > > MAC use to perform the
> timeslicing?
> > > Which MAC SAP primitives/MIB variables could be used to effect
> > > this, while participating in the two BSSes?
> > >
> > > > > [HR/DSSS PHY is] only required to detect HR/DSSS signals, not
> > > > > (LR/)DSSS signals, right?
> > > > I think it has to interpreted to include the (LR/) signals,
> > > > though, or it doesn’t make any sense.
> > >
> > > OK, but in that case why aren't the ED thresholds the same as for
> > > the (LR/)DSSS PHY? Won't this cause unfairness, for (LR/)DSSS transmissions?
> > >
> > > > > How does the receiver know the transmitter's power?
> > > > I’ve assumed in these clauses, the “TX power” refers to the
> > > > detecting STAs TX power that it will use when it transmits.
> > > > That is, if a STA wants to use higher TX power, it needs to
> > > > detect weaker incoming signals since its higher power will “reach”
> > > > those (presumed) more distant devices.
> > >
> > > Ah, yes, makes sense. Definitely merits at least a NOTE, though.
> > >
> > > > > How does 20.3.21.5.1's "CCA sensitivity requirements for
> > > > > non-HT PPDUs in the primary channel are described in 18.3.10.6 and 19.4.7"
> > > > > work for the ED part of (CS/)CCA? Isn't the point of ED that
> > > > > you don't know exactly what's there, just that there's something there?
> > > > I’m missing the point of your question. A clause 20 PHY has to
> > > > perform to clause 18 and 19 rules in the presence of
> > > > transmissions from STAs using those PHYs. That includes signal
> > > > detection, and ED detection.
> > >
> > > But how? If I'm just detecting energy, i.e. I've failed to catch
> > > a PHY header, how do I know what kind of PPDU (if indeed it's an
> > > 802.11
> > > PPDU!) I'm dealing with, so that I can in turn apply the right ED thresholds?
> > >
> > > Mark
> > >
> > > --
> > > 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 434601
> > > ROYAUME UNI WWW: http://www.samsung.com/uk
> > >
> > >
> > > > -----Original Message-----
> > > > From: ***** IEEE stds-802-11-tgm List *****
> > > > [mailto:STDS-802-11-TGM@xxxxxxxx] On Behalf Of Hamilton, Mark
> > > > Sent: 27 November 2012 04:47
> > > > To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
> > > > Subject: Re: [STDS-802-11-TGM] Do STAs inherit or aggregate PHYs?
> > > >
> > > > --- This message came from the IEEE 802.11 Task Group M
> > > > Technical Reflector ---
> > > >
> > > > Hi, Mark,
> > > >
> > > >
> > > >
> > > > My personal opinions, below...
> > > >
> > > >
> > > >
> > > > Mark
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Mark Rison [mailto:m.rison@xxxxxxxxxxx]
> > > > Sent: Wednesday, November 21, 2012 8:16 AM
> > > > To: Hamilton, Mark
> > > > Cc: STDS-802-11-TGM@xxxxxxxx
> > > > Subject: RE: Do STAs inherit or aggregate PHYs?
> > > >
> > > >
> > > >
> > > > Hello Mark,
> > > >
> > > >
> > > >
> > > > > [Just one PHY per STA]
> > > >
> > > >
> > > >
> > > > OK, so let me see what the implications of all this seem to be,
> > > > putting aside anything 11ad might or might not have done to the architecture:
> > > >
> > > >
> > > >
> > > > - You cannot have a STA with both an 11g PHY and an 11a PHY
> > > > (because a STA can only have one PHY)
> > > >
> > > > [MAH] Technically, I suppose that's true. But, now we're going
> > > > to get into theory versus implementation. Since only one PHY
> > > > can be "connected" (that is, associated, or similar externally
> > > > visible things), an implementation can only be using one at a
> > > > time. As long as the STA _acts_ like it only has one, it fits
> > > > the rules of behavior and interoperability per the Standard.
> > > > Then, in the next moment of time, it might switch to the
> > > other one by turning that radio on and the other one off. It
> > > can't ever actually use both PHYs (for example, being associated over them both) at the same time.
> > > > From the Standard's point of view, it only has one. Then,
> > > > (another) one. Then, (another) one. And so on. It's a subtle
> > > > difference, and I know I'm arm-waving. But, I see a real
> > > > difference in how the Standard is written, in that the
> > > MAC/xLME entities only ever deal with a single PHY at the same time.
> > > > That the implementation actually has two, and sort of fakes this
> > > > one-at-a-time part is an implementation detail. Note that this
> > > > is a clear distinction from how 11ad handles the multiple-MAC
> > > > stuff, where a device with more than one PHY must explicitly
> > > > have more than one MAC, to map to them, so no single
> > > MAC has to deal with multiple PHYs.
> > > >
> > > >
> > > >
> > > > - You can, however, have a STA with an 11n PHY operating both in
> > > > the
> > > >
> > > > 2G4 band and the 5G band (because this is one PHY, just
> > > > operating in different channels), even though this includes the
> > > > functionality of 11g and 11a PHYs, and might in theory only
> > > > transmit 11g or 11a PPDUs
> > > >
> > > >
> > > >
> > > > - The 11g PHY has the following non-CCA-ED ED requirement (i.e.
> > > > not the 11y regulatory requirement, the mandatory requirement of all STAs), from 19.4.7:
> > > >
> > > >
> > > >
> > > > "a valid signal with a signal power of –76 dBm or greater at the
> > > > receiver antenna connector is present at the start of the PHY slot"
> > > >
> > > >
> > > >
> > > > - The 11b PHY has the following different ED requirement, from
> > > >
> > > > 17.4.8.5:
> > > >
> > > >
> > > >
> > > > "If a valid High Rate signal is detected during its preamble
> > > > within the CCA window, the ED threshold shall be less than or
> > > > equal to –76 dBm for TX power > 100 mW; –73 dBm for 50 mW < TX
> > > > power ≤ 100 mW; and –70 dBm for TX power ≤ 50
> > mW."
> > > >
> > > >
> > > >
> > > > N.B.: You are only required to detect HR/DSSS signals, not (LR/)DSSS signals, right?
> > > >
> > > > [MAH] Well, what do we think a “High Rate signal” is? It could
> > > > be interpreted as any signal validly sent by a High Rate DSSS
> > > > PHY (since that PHY includes the original PHY, that means the (LR/) rates, too).
> > > > But, I agree that this text is ambiguous. I think it has to
> > > > interpreted to include the (LR/)
> > > signals, though, or it doesn’t make any sense.
> > > >
> > > >
> > > >
> > > > - The 802.11-1997 PHY has the following different ED
> > > > requirement, from
> > > >
> > > > 16.4.8.5:
> > > >
> > > >
> > > >
> > > > "The ED threshold shall be ≤ –80 dBm for TX power > 100 mW, –76
> > > > dBm for 50 mW < TX power ≤
> > > >
> > > > 100 mW, and –70 dBm for TX power ≤ 50 mW."
> > > >
> > > >
> > > >
> > > > While I'm at it:
> > > >
> > > >
> > > >
> > > > - What's a "PHY slot"?
> > > >
> > > > [MAH] Hmm. Interesting. I don’t know. Other than to guess that it is the CCA detection time
> > > > reference points known to the PHY, a la the Matthew Fischer presentation in San Antonio.
> > > >
> > > >
> > > >
> > > > - How does the receiver know the transmitter's power?
> > > >
> > > > [MAH] I’ve assumed in these clauses, the “TX power” refers to
> > > > the detecting STAs TX power that it will use when it transmits.
> > > > That is, if a STA wants to use higher TX power, it needs to
> > > > detect weaker incoming signals since its higher
> > > power will “reach” those (presumed) more distant devices.
> > > >
> > > >
> > > >
> > > > - The ERP does not have to do CCA on non-HR DSSS PPDUs? 19.1.3
> > > > says "The ERP has the capability to detect ERP and Clause 17
> > > > preambles whenever a CCA is requested" -- no "and Clause 16".
> > > > You can't wave your hands around to say Clause 17 preambles
> > > > includes Clause 16 preambles because a few lines up it says "The
> > > > ERP has the capability to decode all Clause 16 and
> > > Clause 17 PLCPs" -- not just "Clause 17 PLCPs".
> > > >
> > > > [MAH] Well, I’m going to wave my hands just like that, anyway.
> > > > Okay, the wording is inconsistent – there’s earth-shattering news!
> > > > J. But, like above, it only makes any sense if each PHY still
> > > > has to detect the previous/older/slower
> > > versions.
> > > >
> > > >
> > > >
> > > > - How does 20.3.21.5.1's "CCA sensitivity requirements for
> > > > non-HT PPDUs in the primary channel are described in 18.3.10.6 and 19.4.7"
> > > > work for the ED part of (CS/)CCA? Isn't the point of ED that
> > > > you don't know exactly what's there,
> > > just that there's something there?
> > > >
> > > > [MAH] I’m missing the point of your question. A clause 20 PHY
> > > > has to perform to clause 18 and 19 rules in the presence of
> > > > transmissions from STAs using those PHYs. That includes signal detection, and ED detection.
> > > >
> > > >
> > > >
> > > > Sorry if I'm just a MAC bull wrecking the PHY china shop!
> > > >
> > > > [MAH] That’s a myth you know…
> > > > (http://www.youtube.com/watch?v=Nk_zpMory-0
> > > > <http://www.youtube.com/watch?v=Nk_zpMory-0> )
> > > >
> > > >
> > > >
> > > > Mark
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > 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
> <http://www.samsung.com/uk>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > >
> > > > > From: Hamilton, Mark [mailto:Mark.Hamilton@xxxxxxxxxxx
> > > > > <mailto:Mark.Hamilton@xxxxxxxxxxx> ]
> > > >
> > > > > Sent: 17 November 2012 05:30
> > > >
> > > > > To: m.rison@xxxxxxxxxxx <mailto:m.rison@xxxxxxxxxxx>
> > > >
> > > > > Cc: STDS-802-11-TGM@xxxxxxxx <mailto:STDS-802-11-TGM@xxxxxxxx>
> > > >
> > > > > Subject: RE: Do STAs inherit or aggregate PHYs?
> > > >
> > > > >
> > > >
> > > > > Mark,
> > > >
> > > > >
> > > >
> > > > > I see the wording you mean, but to me that wording does
> > > > > exactly what I
> > > >
> > > > > thought. That is, when the ERP PHY builds on DSSS/CCK, for
> > > > > example, that means you could view/model
> > > > this as the ERP PHY "containing"
> > > >
> > > > > the DSSS/CCK PHY, or as the ERP PHY being implemented by
> > > > > including all
> > > >
> > > > > the implementation of the DSSS/CCK PHY as an integral part of
> > > > > the ERP PHY. But, either way, it
> > > > isn't "a STA with multiple PHYs"
> > > >
> > > > > in the sense of those PHYs being side-by-side and accessible
> > > > > to the
> > > >
> > > > > MAC. The MAC sees one PHY. What that PHY does internally is
> > > > > not visible or of interest to the
> > > MAC.
> > > >
> > > > >
> > > >
> > > > > Of course, 11ad complicates all this. Note, though, that this
> > > > > allows
> > > >
> > > > > multiple MACs to share a single PHY. In this case, we have
> > > > > multiple
> > > >
> > > > > STAs but only one PHY between them. It carefully never talks
> > > > > about allowing more than one PHY
> > > > accessed by a given MAC entity.
> > > >
> > > > >
> > > >
> > > > > Mark
> > > >
> > > > >
> > > >
> > > > > -----Original Message-----
> > > >
> > > > > From: Mark Rison [mailto:m.rison@xxxxxxxxxxx
> > > > > <mailto:m.rison@xxxxxxxxxxx> ]
> > > >
> > > > > Sent: Friday, November 16, 2012 1:51 PM
> > > >
> > > > > To: Hamilton, Mark
> > > >
> > > > > Cc: STDS-802-11-TGM@xxxxxxxx <mailto:STDS-802-11-TGM@xxxxxxxx>
> > > >
> > > > > Subject: Do STAs inherit or aggregate PHYs?
> > > >
> > > > >
> > > >
> > > > > Hello Mark,
> > > >
> > > > >
> > > >
> > > > > You asked me to explain why it's not clear to me whether the
> > > > > ERP
> > > >
> > > > > includes the DSSS PHYs' functionality or adds to them (and
> > > > > ditto the HT PHY and the HR/DSSS PHY
> > > > w.r.t. their predecessors).
> > > >
> > > > >
> > > >
> > > > > I think the problem is wording like:
> > > >
> > > > >
> > > >
> > > > > - "The ERP builds on [DSSS/CCK]" in 19.1. "builds on" to me
> > > > > suggests
> > > >
> > > > > to me that the foundations are owned by someone else -- think of it as freehold v. leasehold!
> > > >
> > > > >
> > > >
> > > > > - "[HR/DSSS] builds on [DSSS]" in 17.1 (ditto)
> > > >
> > > > >
> > > >
> > > > > - "In addition to [Clause 20], an HT STA shall be capable of
> > > >
> > > > > transmitting and receiving frames that are compliant with
> > > > > [Clause
> > > > > 18
> > > >
> > > > > and/or 17 and 19]" in 20.1. Note the HT *STA* is capable, but
> > > > > is this done by the HT *PHY* or by
> > > > having multiple PHYs?
> > > >
> > > > >
> > > >
> > > > > Mark
> > > >
> > > > >
> > > >
> > > > > --
> > > >
> > > > > 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
> > <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
> > > > ________________________________________________________________
> > > > __
> > > > __
> > > > ___________
> > >
> >
> >
>
>
_______________________________________________________________________________
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
_______________________________________________________________________________
_______________________________________________________________________________
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
_______________________________________________________________________________