·
https://mentor.ieee.org/802.11/dcn/17/11-17-0340-00-00ax-cr-for-11-1-3-10.docx
- Yonggang Fang
I will not be able to attend this, so here are some brief comments on 17/0340r0:
`
- "Rejected – See discussion below" (and similar) is not an acceptable comment
resolution. The resolution needs to stand alone
[YG] As a couple of comments address to and request to change the same text, we think it would be better to group them together. But we can separate them to make resolution stand alone if it is possible.
It's fine to have the same resolution for multiple comments, potentially.
What is not fine is to say "see discussion below". There is no "below"
in the comment resolution spreadsheet, which captures the resolutions
for all the comments. Also, saying something like "see 17/1234r3" is
not good enough: there should be some summary of why the comment is being
rejected.
- Re CIDs 5165, 6556, 9334, 9696, I don't buy the claim that "The UL transmission could
gain about up to 10dB". HE ER PPDUs can only be sent with 10 MHz or 20 MHz bandwidth.
So the only gain a non-AP STA can get from transmitting an HE ER PPDU in response
to a Beacon frame sent in an HE ER PPDU too is the gain from concentrating the
energy into 10 MHz rather than 20 MHz. This is not 10 dB
[YG] An non-AP HE STA can transmit UL data in a RU such as 26-tones. There is no restriction to use HE_EXT_SU only for UL transmission. When a non-AP HE STA transmits in 26-tone RU, it is about 10dB
improvement comparing to PPDU in 20MHz BW.
But if the non-AP STA transmits in a 26-tone RU, it is not using HE ER PPDU
format, so is losing the "extended range" advantage of that format, which
the beacon used. There needs to be some justification that
"range of beacon in HE ER PPDU" is the same as "range of frame transmitted
by non-AP STA in 26-tone RU".
- CID 9696 asked for simulation evidence for the benefits of HE ER beacons.
This has not been addressed
[YG] When an HE AP transmits HE Beacon frame in HE_EXT_SU PPDU format, it can use narrower BW such 106 tone RU, and longer CP to provide more robustness of Beacon frame transmission. It is why 11ax needs
OFDMA. I will clarify this in the discussion.
OK. Note the specific request in CID 9696 for simulation evidence.
- Re CIDs 7977, 7978, 9561, I don't think it's necessary to "add the restriction of not
sending HE Beacon and legacy Beacon at same time" since the laws of physics already ensure
this. However, it is necessary to ensure the T HE Beacon TT is well-defined
to minimise power consumption at STAs that are receiving the HE Beacons
[YG] agree. Will remove this restriction.
- The resolution to CID 7961 needs to address the point that the AP needs to
send a given broadcast BU twice: once after the HE beacon (for STAs that are
tracking these only) and once after the legacy beacon (for STAs that are
tracking these only)
[YG] see response below.
Sorry, where exactly?
- Or are you suggesting (as the new 10.7.5.x implies) that if an AP sends
HE beacons it doesn't send legacy beacons? Then "not schedule transmissions of HE Beacon
at the time of legacy Beacon transmission" makes even less sense
[YG] No, an HE AP can schedule the legacy Beacon frame transmission or HE Beacon transmission independently. It is not necessary to bundle them together. HE AP may be configured to send an HE Beacon
with different BSSID from legacy Beacon. Therefore, there is no need to duplicate same content (BUs) in legacy Beacon and HE Beacon. But this is not necessary to specify in the spec.
It is critical for power saving at the non-AP STA that the non-AP STA know
what the expected time of transmission of the beacon is (the TBTT). This
is why the normal TBTT is defined to be those times where TSF % BI == 0.
This is also why, if the HE Beacon is not going to replace the normal Beacon
but be sent additionally, there needs to be a well-defined TBTT for those
beacons (e.g. TSF % BI = BI / 2).
However, I'm confused as to what exactly is being proposed now. Will there
potentially be an HE beacon and non-HE beacon for the same BSS? Or is
it an exclusive or?
- "The HE AP shall transmit buffered non-GCR-SP group addressed BUs, immediately after HE Beacon frames, when they are DTIM Beacons
frames (see 11.2.3.4) "
is grammatically broken (spurious first comma) and duplicates the statement
in 11.2.3.4, which is already clear ("After a DTIM, the AP shall transmit buffered
non-GCR-SP group addressed BUs, before transmitting any individually addressed frames.")
[YG] it is modified to "An HE AP shall transmit buffered non-GCR-SP group addressed BUs immediately after HE Beacon frames with DTIM before transmitting any individually addressed frames."
I don't understand:
a) why the wording is different from that in 11.2.3.4
b) why it is necessary to duplicate the wording anyway
- "An HE Beacon frame may not include fields/IEs that apply only to legacy STAs"
is ambiguous. Change
to "shall not" or "may exclude" depending on what you mean
[YG] Ok. I will change to "shall not".
- "An HE AP may transmit HE
Beacon frames and group addressed traffic in HE_EXT_SU PHY formats " is only
true if there are no non-HE basic rates/MCSes, per 10.7.5.x. This needs to be
made clear
[YG] change to "An HE AP may transmit HE Beacon frames and group addressed traffic in HE_EXT_SU PHY format
using the rate for HE Beacon frame in 10.7.5.x to ensure the BSS discoverability ..."
This does not address the problem.
Your latest wording is saying: you may transmit HE beacon; if you do the rate is specified in 10.7.5.x.
What your wording needs to say is: if there are no non-HE basic rates/MCSes, you may transmit HE beacon; if you do the rate is specified in 10.7.5.x.
(This relates to the question above about whether in a given BSS there might be both HE beacon transmission and non-HE beacon transmission.)
- "An HE Beacon" should be "An
HE Beacon frame"
[YG] agree
- "in HE_EXT_SU PHY formats
" should be "in HE_EXT_SU PHY format
"
[YG] agree
- "of HE Beacon" should be "of
HE Beacon frames"
[YG] agree
- What does "to indicate availability of HE Beacon" mean? And
"frames" is missing
[YG] In the HE Operation Parameter, there is a bit called Dural Beacon in the current text. We propose to rename it to HE Beacon Indication. If an HE AP is going to transmit HE Beacon, it shall set the
HE Beacon Indication to 1.
Fine. Say this, not this vague "availability" wording.
- What does "The additional rate selection restriction for HE PPDU is defined in the clause 27.15.4.3"
mean?
The grammar is poor too
[YG] change to "The additional rate selection rule
restriction for HE_EXT_SU PPDU is defined in the clause 27.15.2 and 27.15.3"
Still not clear and grammatical. More grammatical would be maybe:
"Additional rate selection rules for HE_EXT_SU PPDUs are defined in Clauses 27.15.2 and 27.15.3"
But is that what you mean? Why are additional rules needed anyway?
- "high efficient (HE) beacon:
A BSS transmits beacons in HE_EXT_SU PHY format
to enable BSS discoverability and BSS operating parameters distribution in the
whole BSS coverage." is not a definition of a beacon, it's a definition of
behaviour. Furthermore, it's broken: a BSS doesn't transmit anything, an
AP does
[YG] Change to "high efficiency (HE) beacon: A Beacon frame carried in HE_EXT_SU PHY format to enable BSS discoverability and BSS operating parameters distribution in the entire BSS coverage"
Still some issues:
- what is "in HE_EXT_SU PHY format"? I think D1.0 is pretty inconsistent,
but at the least I'd delete the "PHY"
- everything from "to enable" onwards is tautological, because the beacons
define the BSS coverage. So a non-HE beacon also enables "BSS discoverability
and BSS operating parameters distribution in the entire BSS coverage"
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW:
http://www.samsung.com/uk
From: *** 802.11 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxx]
On Behalf Of Osama AboulMagd
Sent: 30 March 2017 19:07
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGAX] TGax Telecon 20170406
Hello All,
There is a TGax telecon scheduled for Thursday April 06
at 20:00 ET.
Please let me know if you plan a submission.
A tentative agenda is:
·
Call the meeting to order
·
IEEE 802 and 802.11 IPR policy and procedure
·
Attendance reminder. Please send an e.mail to Yasuhiko Inoue (Inoue.yasuhiko@xxxxxxxxxxxxx)
and/or Osama Aboul-Magd (Osama.aboulmagd@xxxxxxxxxx)
·
Announcements
·
Reminder of the May TGax ad hoc meeting in Seoul. Korea
·
https://mentor.ieee.org/802.11/dcn/17/11-17-0340-00-00ax-cr-for-11-1-3-10.docx
- Yonggang Fang
·
AoB
·
Adjourn.
Teleconferences are bound by the conditions stipulated by the documentation below. Please review them and bring up any questions/concerns you may have before proceeding with the teleconference
IEEE Patent Policy -
http://standards.ieee.org/board/pat/pat-slideset.ppt
Patent FAQ - http://standards.ieee.org/board/pat/faq.pdf
LoA Form - http://standards.ieee.org/board/pat/loa.pdf
Affiliation FAQ - http://standards.ieee.org/faqs/affiliationFAQ.html
Anti-Trust FAQ - http://standards.ieee.org/resources/antitrust-guidelines.pdf
Ethics - http://www.ieee.org/portal/cms_docs/about/CoE_poster.pdf
IEEE 802.11 Working Group Operations’ Manual – https://mentor.ieee.org/802.11/dcn/14/11-14-0629-16-0000-802-11-operations-manual.docx
To join the meeting:
https://join.me/IEEE802.11
Conference ID: 808-571-868
Regards;
Osama.
_______________________________________________________________________________
If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.
Instead, go to
http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX and then 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, do not send your request to this reflector - it will have no effect.
Instead, go to
http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX and then press the LEAVE button.
Further information can be found at:
http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________