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,
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
_______________________________________________________________________________