Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Mark, > I’m trying to decide if I think the phrase “multi-band AP device” is understandable enough without a definition. I think it will cause confusion to use this term without a proper definition of how it relates to a regular AP, single PHY (one or more MACs), etc. How this fits the architecture needs to be specified. > Of course, if I understood comments from TGba correctly, this might also be a device with multiple APs that are in the same band, but on different channels. (Not sure that’s useful in this case,
but it is possible, right?) From an architecture point of view, this is ok and is covered by the multi-band device definition we have today in the standard.
Thanks, Carlos. From: mark.hamilton2152@xxxxxxxxx [mailto:mark.hamilton2152@xxxxxxxxx]
Thanks, Carlos. Sadly, you’re right, strictly. I’m trying to decide if I think the phrase “multi-band AP device” is understandable enough without a definition. Grey area. Alternatively (or if we have to word-smith a definition), it probably needs to be slightly modified from your suggestion, to be, “multi-band device that contains _multiple APs_”. Otherwise,
a ‘repeater’ would be a “multi-band AP device”, even if it only has one AP. Of course, if I understood comments from TGba correctly, this might also be a device with multiple APs that are in the same band, but on different channels. (Not sure that’s useful in this case, but it is possible, right?) Mark P.S., Yep, I know you were. It was largely just you and me, as I recall (with help from a few others) – and that’s who I meant by “we”!
😊 From: Cordeiro, Carlos [mailto:carlos.cordeiro@xxxxxxxxx]
Mark, We don’t use the term “multi-band AP device” or “Multi-band device AP” in 802.11-2016. For the purpose you are looking for, the options we have today would be something like “multi-band device that contains
an AP” when referring to the device as a whole and “AP within a multi-band device” when referring to the AP within the device. Of course, if this usage is expected to become commonplace in the standard, then we probably should think of a shorthand terminology
for it. Thanks, Carlos. P.S.: agree with your P.S. below. I was very much involved in those discussions defining the architecture in 4.9.3
J. From: mark.hamilton2152@xxxxxxxxx [mailto:mark.hamilton2152@xxxxxxxxx]
Carlos, Good point, and my bad (having working through this in TGad!). Should be “multi-band”. I guess the full term is “multi-band AP device”? “multi-band device AP”? (The latter feels awkward; the former is potentially confusing and leads
to use of “multi-band AP” again…) Mark P.S., a nit, but a STA has a single MAC. It has only one PHY interface. But, it may share that PHY with other STAs. (See 4.9.3.) We worked through that one in TGad, painfully, also… So, here we are again (with the non-AP STA having
more than one PHY, and maybe a (vestigial) MAC) - Ugh! From: Cordeiro, Carlos [mailto:carlos.cordeiro@xxxxxxxxx]
Hi Mark, Is there any reason for introducing the term “dual-band”? Back in the 11ad/11mc days, we had quite a bit of discussion on the use of such terms. We avoided using terms like “dual-band”, but instead decided
to use “multi-band”. Architecturally, a STA has a single MAC and PHY entities. To refer to any box that has more than a single MAC and PHY entity, the 802.11 standard uses the term “multi-band device” (several occurrences of this term in 802.11-2016). Thanks, Carlos. From: *** 802.11 TGba - WUR- Wake-up Radio Operation *** [mailto:STDS-802-11-TGBA@xxxxxxxx]
On Behalf Of Mark Hamilton All, (CC: TGba, just FYI, for those who have undying interest…) I have uploaded updates to my discussion documents with proposed architecture (reference models) for WUR-capable AP and non-AP STAs, and the state machine view of WUR operation. I think I captured the comments made on the last ARC teleconference.
And, these are now pasted as embedded Visio objects within a Word file, so hopefully they will upload and download correctly. These can be found here:
-
https://mentor.ieee.org/802.11/dcn/18/11-18-1017-01-0arc-wur-multi-ap-reference-model.docx
-
https://mentor.ieee.org/802.11/dcn/18/11-18-1016-02-0arc-wur-state-diagram-proposal-hamilton.docx We (the ARC SC) can review these at the F2F in July (San Diego), and decide what to present/discuss with TGba in our joint session on Thursday PM2. Mark To unsubscribe from the STDS-802-11-TGBA list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBA&A=1 To unsubscribe from the STDS-802-11-TGBA list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBA&A=1 |