HI, Minyoung,
My major concern, and issue that I believe REVme could address, is that there don’t seem to be any specific, actual requirements that describe the waveform, which leaves me doubting how there can be interoperability (other than through extra-standard means, such as private agreements between vendors).
Can you explain how “if an implementer wants they can choose another options” results in implementations that do choose other options being interoperable?
Thanks. Mark
From: Minyoung Park <mpark.ieee@xxxxxxxxx>
Sent: Thursday, September 8, 2022 1:07 PM
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] Proposed resolution for 802.11me Rev 1.0, CID 2346 on MC-OOK
--- This message came from the IEEE 802.11 Working Group Reflector ---
Hello Mark,
Please see my opinions below.
Regards,
Minyoung
On Thu, Sep 8, 2022 at 1:29 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:
--- This message came from the IEEE 802.11 Working Group Reflector ---
> It seems to me MC-OOK represents the technical details of TGba much better than 'WUR OOK'. Clause 30 is based on the MC-OOK (using multi-carriers) to generate OOK waveform so I'm not sure it is a good idea to rename that to something unrelated.
OK, but the fundamental point remains:
What are the actual requirements for WUR waveforms? Are they required
to be generated (not just "based on") as shown in Annex AC (apparently not,
since this is informative), or can they be generated in some other way
(but in that case we need a specification for what the actual requirements
are).
[MP] With the 'should' , it is recommended to use the waveform designs shown in Annex AC but if an implementer wants they can choose another options. This doesn't create any interop issue so this was the consensus in TGba.
The proposal in 22/1035r1 resolves this in the direction of confirming
that Annex AC is informative, and that WUR waveforms don't have to be
generated using MC-OOK, but just need to have some specific underlying
characteristics. This seems to me to be a reasonable resolution.
I would certainly entertain an alternative resolution in which the
direction was to make Annex AC normative and clarify that WUR waveforms
shall be generated using MC-OOK, but in the absence of such a counterproposal
I think 22/1035r1 is a reasonable resolution.
> (also not sure if this type of change is in scope of 11me since TGba already spent a lot of time to get to this consensus).
TGme's raison d'être is to fix problems that were not noticed and fixed
earlier (well, that and folding in amendments).
[MP] Since the 'should' doesn't create any interop issue, I don't see what problem TGme is solving. Changing name from MC-OOK to WUR OOK doesn't seem to solve any problem. To me, it seems to create more confusion to readers.
> Reading the SP and motion results, it seems like there is no consensus in the group so better resolution should be 'REJECTED' and put the reason as 'the group couldn't reach consensus with the SP/motion results' and move on.
I'll repeat the comments I made yesterday. I do not think "the group couldn't reach consensus with the SP/motion results" is an appropriate resolution here.
For one, there was an explicit motion to reject, and it failed.
13/0230r5 (802.11 Comment Resolution – a Tutorial) indicates that a "no consensus" resolution can be used when:
– The CRC has considered one or more other resolutions that attempt to satisfy the comment, but no such resolution has received 75% approval.
– It should be recorded in the minutes what other resolution(s) have been considered, together with the results of any straw polls or motions on those alternative solutions so that the commenter can understand that this solution was used after due diligence to satisfy the comment.
11/1625r2 (802.11 Comment Resolution Guide) further clarifies that:
“cannot reach consensus” should be a resolution of last resort. It also fails the “responsiveness” test. It should be used only when other resolutions have been considered and debated and no consensus has been discovered for any other resolution. It should not be used as a shorthand for “we can’t be bothered to find a proper resolution” or “we don’t want to change the draft and won’t tell you why”. Over-use of this resolution is likely to lead to increased negative votes and hostile debate in the WG.
The WG chair has also confirmed by email that:
the “lack of consensus” resolution should be used very sparingly, and typically late in the recirculation process.
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: Minyoung Park <mpark.ieee@xxxxxxxxx>
Sent: Thursday, 8 September 2022 02:11
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] Proposed resolution for 802.11me Rev 1.0, CID 2346 on MC-OOK
--- This message came from the IEEE 802.11 Working Group Reflector ---
Hello Joseph,
Thanks for preparing the comment resolution.
It seems to me MC-OOK represents the technical details of TGba much better than 'WUR OOK'. Clause 30 is based on the MC-OOK (using multi-carriers) to generate OOK waveform so I'm not sure it is a good idea to rename that to something unrelated. (also not sure if this type of change is in scope of 11me since TGba already spent a lot of time to get to this consensus).
Regarding the following text, 'should' is a valid normative verb so I don't understand why you consider 'should' is not a typical normative verb.
The WUR PHY uses the multicarrier on-off keying (MC-OOK) modulation for (#1128)WUR-Sync and WUR-Data fields. MC-OOK is defined as an on-off keying, modulated with a multicarrier signal. The multicarrier signal should be generated using contiguous 13 subcarriers, cantered within a 20 MHz channel, with a subcarrier spacing of 312.5 kHz and the centre subcarrier (#1131)being null. The subcarrier coefficients may take values from the BPSK, QPSK, 16-QAM, 64-QAM, or 256-QAM constellation symbols.
Reading the SP and motion results, it seems like there is no consensus in the group so better resolution should be 'REJECTED' and put the reason as 'the group couldn't reach consensus with the SP/motion results' and move on.
Best regards,
Minyoung
On Wed, Sep 7, 2022 at 5:15 PM Joseph Levy <000019588066c6b7-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
--- This message came from the IEEE 802.11 Working Group Reflector ---
Sorry – the while the links are correct the document number provided in the previous email is wrong: should be 11-22/1035r1.
Regards
Joseph
From: Joseph Levy <000019588066c6b7-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, September 7, 2022 8:12 PM
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11] Proposed resolution for 802.11me Rev 1.0, CID 2346 on MC-OOK
--- This message came from the IEEE 802.11 Working Group Reflector ---
Dear All,
TGme has been working to resolve CID 2346 for several months.
A motion to reject the comment was made during the TGme Ad Hoc in NYC, April 2022, the motion failed (4y,6n,5a).
Details regarding this motion and the way forward are provided in the “Comment resolution history” in 11-22/0135r1 “Proposed TGme Comment Resolution CID 2346”.
When 11-22/0135r0 was discussed during the TGme Ad Hoc in San Diego, August 2022 the proposed resolution was requested to be updated based on comments made during the Ad Hoc and posted to the WG reflector (hence this post).
11-22/0135r1 provides detailed discussion on the issue, proposes a way forward, and provides a detailed text proposal to resolve the comment.
Please review and comment on this proposed way forward. This contribution will be discussed at the upcoming 802.11 September Interim meeting in Hawaii in TGme, please see the TGme agenda for the time of the discussion.
Also pre-meeting discussion may be had on this email thread.
Regards,
Joseph Levy
InterDigital
New York
o: +1.631.622.4139
m: +1.516.835.9353
To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1
To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1
To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1
To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1
To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1
To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1