Re: [STDS-802-11-TGM] Do STAs inherit or aggregate PHYs?
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
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
_______________________________________________________________________________