Hi Mark and Carlos,
Some of thoughts:
- This discussion is having difficulty defining terms and names, therefore I think it is best to formally define whatever is eventually agreed as the name of this “device”.
- 802.11 has clearly defined an AP and a STA to be single logical entities (from P802.11REVmd D1.0):
“access point (AP): An entity that contains one station (STA) and provides access to the distribution system services, via the wireless medium (WM) for associated STAs. An AP comprises a STA and a distribution system access function (DSAF).”
And a STA to be:
“station (STA): A logical entity that is a singly addressable instance of a medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM).”
I think we need another term do define a grouping of these single logical entities.
- There are currently several “types” of use of the word “device” in the 802.11 specification (P802.1REVmd D1.0):
- The words “physical device”, “multi-band device”, and “device that is multi-band capable” are used to describe an entity that has several radios or capabilities:
“collocated interference: Interference that is caused by another radio or station (STA) emitting radio energy located in the same
physical device as the reporting STA, where the reported characteristics of the interference are known a priori without interference detection, measurement, or characterization by the reporting
STA.”
collocated radio: A radio capable of emitting radio-frequency energy located in the same
physical device as the reporting station (STA), where the radio’s type and some link characteristics are known without signal detection or measurement by the reporting STA.
“In certain applications, the AS might be integrated into the same physical device as the AP, or into a STA in an IBSS or PBSS.” “A DMG STA has MAC features that include frame aggregation, block ack features, service periods, contention based access periods,
DMG protected period, AP or PCP clustering, dynamic channel time management, reverse direction, spatial sharing, beamforming, and operation (fast session transfer) in a
multi-band device.”
“If this model is used in conjunction with the reference model for multi-band operation (see 4.9.4 (Reference model for multi-band operation)), the multiple MAC reference model applies within each physical layer entity contained in the
multi-band device whereas the multi-band operation reference model applies to different physical layers.”
“The reference model of a device that is multi-band capable (see 11.31 (Multi-band operation)) and that supports transparent fast session transfer (FST) is shown in Figure 4-23 (Reference model
for a multi-band capable device (transparent FST)). The reference model of a
device that is multi-band capable and that supports nontransparent FST is shown in Figure 4-24 (Reference model for a multi-band capable device (nontransparent FST)).”
“A multi-band capable device can manage operation over more than one frequency band/channel. The operation across the different frequency bands/channels can be simultaneous or nonsimultaneous.”
“A multi-band capable device can also support multiple MAC sublayers; in this case, it is coordinated by an MM-SME.”
“A multi-band capable device (11.31 (Multi-band operation)) shall maintain a local TSF timer for each channel in which the STA operates.”
“A multi-band capable device that uses OCT to move from State 2 to either State 3 or State 4 shall not transmit frames before the transmitting STA becomes over-the-WM enabled (see 11.31.4 (On-channel
Tunneling (OCT) operation)).”
“A device is multi-band capable if the value of dot11MultibandImplemented is true. A
multi-band capable device is said to be a member of a BSS when one or more of the STAs in the
device is a member of the BSS. A STA that is part of a
multi-band capable device advertises the capability by including the Multi-band element in Beacon, DMG Beacon, (Re)Association Request, (Re)Association Response, Information Request, Information Response,
Probe Request, Probe Response, Announce, FST Setup Request, FST Setup Response, TDLS Discovery Request, TDLS Discovery Response, TDLS Setup Request, and TDLS Setup Response frames.”
(italics and highlighting added) - The word “device” is also used to describe entities which meet certain rules or lump various “functions/capabilities” together:
“television band device (TVBD): An intentional radiator that operates on an unlicensed basis on available channels in the broadcast television frequency bands [US].”
“white space device (WSD): An entity that employs cognitive facilities to use white space spectrum without causing harmful interference to protected services [EU].”
“It is possible for one device to offer both the functions of an AP and a portal. For example, a portal to a wired IEEE 802 LAN is shown in Figure 4-6 (Connecting to other IEEE 802 LANs).”
“It is possible for one device to offer any combination of the functions of an AP, a portal, and a mesh gate; see 14.11.5 (Mesh STA collocation). An example
device combining the functions of an AP and a mesh gate is shown in Figure 4-10 (Example device consisting of mesh STA and AP STA to connect an MBSS and an infrastructure BSS). The implementation
of such collocated entities is beyond the scope of this standard.”
“Indicates the device characteristic of the non-AP STA requesting AID assignment. This parameter is optionally present if dot11S1GOptionImplemented is true; otherwise not present.”
“The Device Type subelement reports the type of device in which the IEEE 802.11 STA resides. The format of the Device Type subelement is shown in Figure 9-408 (Device Type subelement format).”
“Potential methods for determining the regulatory domain include receiving a country indication in the Beacon frame, user confirmation, or configuration information within the
device.”
“The Configuration Profile report enables an AP to discover the current profile in use for an associated
device, and additional profiles for the current ESS. A non-AP STA that supports diagnostic reporting and receives a Configuration Profile report request type shall respond with a Diagnostic
Report frame that includes all available Diagnostic elements allowed for the type.”
“Each Diagnostic Report element shall contain a Profile ID element that uniquely identifies the configuration profile(s) for the current ESS that are available on the
device.”
“The Manufacturer Information STA Report enables an AP to discover static manufacturer specific data about an associated STA
device.”
“A non-AP STA’s SME that has received an MLME-BTM.indication primitive forwards the MLME-BTM.indication parameters to the appropriate entity within the
device (e.g., web browser) to inform the end user; the means and protocol by which the SME accomplishes this is outside the scope of this standard.”
“Such interference might be due to an interaction between radios where a reporting STA is collocated with another radio
device.”
“A GDD enabling STA sending the Channel Availability Query frame should provide its
device identification information in a format specified in 9.4.4.2.2 (Device Identification Information).”
“Entities outside the scope of this standard that might control the traffic steering decision of a
device benefit by being able to predict the throughput that might be obtained through a link with a STA.”
“Furthermore, the device shall not receive or transmit any TKIP-encrypted Data frames, and shall not receive or transmit any unencrypted Data frames other than IEEE 802.1X messages, to or from
any peer for a period of at least 60 s after it detects the second failure. If the
device is an AP, it shall disallow new associations using TKIP during this 60 s period; at the end of the 60 s period, the AP shall resume normal operations and allow STAs to (re)associate.
If the device is an IBSS STA, it shall disallow any new security associations using TKIP during this 60 s period. If the
device is a Supplicant, it shall first send a Michael MIC Failure Report frame prior to revoking its PTKSA and deauthenticating itself.”
(italics and highlighting added) - The word “device” is also used in field and element names.
- The word “device” is also used to mean a STA or some test entity (this should probably be changed – in my humble opinion):
“Implicit feedback beamforming is a technique that relies on reciprocity in the time division duplex channel to estimate the channel over which a
device is transmitting based on the MIMO reference that is received from the
device to which it plans to transmit.”
“The number of spatial streams under test shall be equal to the number of utilized transmitting STA antenna (output) ports and also equal to the number of utilized device under test input ports.”
“Each output port of the transmitting STA shall be connected through a cable to one input port of the
device under test.”
“The transmit spectrum shall have a 0 dBr (dB relative to the maximum spectral density of the signal) bandwidth not exceeding 1.88 GHz, –17 dBr at a 1.2 GHz offset, –22 dBr at a 2.7 GHz offset and –30 dBr at a 3.06 GHz offset and above, inside the channels
allowed for the regulatory domain in which the device is transmitting.”
(italics and highlighting added)
- So my preference would be to define a “physical device” to be an entity that contains whatever, needs to be lumped in to the “physical device” to address the need of the specification.
Hence we could define:
- A “WUR AP physical device” that contains a STA that is capable of transmitting WUR frames and providing the PRC function (normal 802.11 AP frame exchanges), and whatever control/(MAC?) is
necessary for WUR functionality.
- A “WUR non-AP STA physical device” that contains a STA capable of providing the PRC function (Normal 802.11 STA frame exchanges), a WUR receiver, and whatever control/(MAC?) is necessary
for WUR functionality.
- One last thought: the use of PRC in the current draft, while an attempt to clarify PRC vs. WRU operation, does not in my opinion solve the problem. Hence, I think it would be clearer to
simply refer to the non-AP STA and AP entities, deal with the WURx as a separate entity, and define a WUR TX capable AP entity. But, this obviously need to be discussed.
Joseph
From: *** 802.11 TGba - WUR- Wake-up Radio Operation *** [mailto:STDS-802-11-TGBA@xxxxxxxx]
On Behalf Of Cordeiro, Carlos
Sent: Monday, July 2, 2018 10:56 PM
To: STDS-802-11-TGBA@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBA] Updated WUR architecture and state machines uploaded
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.
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”!
😊
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.
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!
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.
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:
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
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
|