Hi Mark,
You have highlighted that we are discussing two topics: Terminology (the name) and Requirements. I agree that it is good that we do not mix them up.
Terminology
I agree with Minyoung that multi-carrier on-off keying (MC-OOK) makes much more physical sense than wake-up radio on-off keying (WUR-OOK). Changing the name from “MC-OOK” to “WUR-OOK” does not affect the requirements topic
and only replaces a good name with a poor name.
In May Minyoung and I recommended the following comment resolution to address the comment which was on the Terminology.
|
CID |
Comment |
Proposed Change |
Resolution |
|
2346 |
MC-OOK is a strange definition. Is MC-OOK symbol different than regular OOK symbols, particularly the definition of MC-OOK OFF symbol sounds rather strange. |
please clarify how MC-OOK is different than regular OOK, and is the spec mandating this OOK symbol must be generated by Multiple Carrier? If not, consider removing this definition. |
REJECTED The commenter asks a question and does not provide specific recommended changes to the draft. To answer the question asked by the commenter: Unlike traditional on-off keying (OOK) IEEE 802.11ba uses multicarrier on-off keying (MC-OOK) where instead of using a single carrier the modulation uses multiple
carriers. In particular it uses 13 subcarriers as specified in the standard. The use of multiple subcarriers provides a 4 MHz bandwidth which is significantly wider than would result from using a single carrier. This is wider bandwidth is very beneficial
in regulatory domains (e.g. ETSI) which have power spectral density (PSD) regulations, since the wider bandwidth allows for higher transmit power, improving the link budget. The specification does not mandate a specific implementation of the MC-OOK waveform,
but provides several recommendations. The commenter seems to indicate that the standard should not include terms for features where the standard does not mandate a specific implementation. However, the standard includes many terms for features where the
method of implementation is not mandated in the standard. A simple example is the term “energy detection (ED)” which is used throughout the standard, but the standard does not mandate a specific implementation method for measuring the energy level measured
at the receiver. |
Requirements
You have brought up this different topic of requirements. I agree with Minyoung that the reason the Task Group did not place a “shall” requirement on the exact method of constructing the MC-OOK waveform is that it does
not affect interoperability. There is a “shall” requirement on the Spectral Mask in subclause 30.3.12.1, which is controlled by the MC-OOK waveform. There is a “shall” requirement on the on-off power ratio in subclause 30.3.12.4.
The original comment proposed to change the name “MC-OOK” which I oppose. I also do not see any need to add any other requirements since the standard covers the necessary requirements for interoperability.
Regards,
Steve
From: Minyoung Park <mpark.ieee@xxxxxxxxx>
Sent: Thursday, September 8, 2022 12: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