Hi Minyoung,
I don’t agree with your statement that these changes make the specification more unclear.
I also don’t agree it is a problem that implementers can use any method they choose to generate the OOK waveform specified in Clause 30.2.12.
To my knowledge the 802.11 specification does not specify methods of generating over the air waveforms, it only specifies the requirements for the waveforms. Clause 30.2.12 provides the necessary waveform specifications. Are you saying
that only waveforms that have been generated using the MC-OOK method are allowed? Such a statement is dictating implementation and does not belong in the 802.11 specification. If there are additional waveform requirement beyond what is currently in Clause
30.2.12 that are necessary to meet the PAR requirements they should have been included in the 802.11ba amendment. Mandating an implementation is not something 802.11 generally does to specify the characteristics of waveforms.
Lastly, how can the method used to generate the transmitted OOK signal in the AP have a detrimental impact on the power consumption of the OOK receiver in the non-AP STA?
Regards,
Joseph
From: Minyoung Park <mpark.ieee@xxxxxxxxx>
Sent: Friday, September 9, 2022 1:26 PM
To: Joseph Levy <Joseph.Levy@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] Proposed resolution for 802.11me Rev 1.0, CID 2346 on MC-OOK
Joseph,
The changes in your proposal are making the specification more unclear since the spec is now suggesting implementers to use any OOK waveform without any guarantee on performance. The implementers will assume
they can use any OOK waveform, which might lead to a bad performance that doesn't meet the PAR requirement (either higher power consumption than 1 mW (PAR requirement) or not good enough receive sensitivity). I don't think this is what 802.11WG wants with
the already published amendment.
MC-OOK was carefully evaluated in TGba to meet the PAR. The spec should be written so that implementers use MC-OOK unless they have better alternative OOK waveform. The current proposed resolution is not doing
that but creating more confusion.
Regards,
Minyoung
On Fri, Sep 9, 2022 at 9:39 AM Joseph Levy <000019588066c6b7-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
--- This message came from the IEEE 802.11 Working Group Reflector ---
Mark – Thank you for your support of the proposed resolution. The nature of the OOK signal used by WUR is clearly specified in the PHY clause: 30.3.12 which provides all the parameters necessary to describe an OOK signal: transmit spectrum mask, spectral flatness, transmit center frequency and symbol clock frequency tolerance, and transmit on and off symbols power ratio.
Steve – The resolution you are re-proposing was the resolution that was motioned and failed, mentioned in the email at the start of this thread: “A motion to reject the comment was made during the TGme Ad Hoc in NYC, April 2022, the motion failed (4y,6n,5a).” This failed motion instigated the comment being assigned and marked submission required.
Regarding the concept of a “good” name vs a “bad” name is concerned: I am fine with using any name you want as long as it is clear that WUR uses OOK signaling and that one possible technique for producing the specified OOK signal is the MC-OOK technique. Calling both the:
- OOK waveform which is specified in the PHY clause and
- a suggested technique to generate the wave form
“MC-OOK” is confusing and is not good specification practice, as doing so makes the specification unclear.
The OOK waveform specified in clause 30.2.12 is complete and will support interoperability. There should be no requirement in the specification that dictate how the OOK waveform is generated, as that is implementation. In the proposed resolution these signals are referred to as “WUR OOK”. If a different name is preferred I am open to that, as long as it is not “MC-OOK”, as “MC-OOK” is used in the specification to describe a technique for generating the “WUR OOK” waveform. Reserving the name “MC-OOK” to be used only to refer to the suggested technique of generating these “WUR OOK” waveforms will increase the clarity of the specification.
Regards,
Joseph
From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Friday, September 9, 2022 3:29 AM
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 ---
> 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.
OK, so what/where are the normative requirements (i.e. "shall"s) on
"the MC-OOK waveform" (or "an MC-OOK signal", term used in the spec)?
Are you saying that
30.3.12.4 Transmit On and Off Symbols power ratio
For each input bit of the WUR-Data field transmitted at WUR HDR, the ratio between the averaged power
of the On Symbol and the averaged power of the Off Symbol of the transmit signal in the WUR-Data field
shall be at least 20 dB.
For each input bit of the WUR-Data field transmitted at WUR LDR, the ratio between the averaged power
over On Symbols and the averaged power over Off Symbols of the transmit signal in the WUR-Data field
shall be at least 20 dB.
For the WUR-Sync field transmission, the ratio between the averaged power over all On Symbols and the
averaged power over all Off Symbols in the WUR-Sync field shall be at least 20 dB.
and the various shalls in
30.3.12.1 Transmit spectrum mask
For operation using 20 MHz channel spacing, the transmitted spectrum of the L-STF, L-LTF, L-SIG, BPSK-
Mark1, and BSPK-Mark2 fields shall have a 0 dBr (dB relative to the maximum spectral density of the
signal) bandwidth not exceeding 18 MHz, –20 dBr at 11 MHz frequency offset, –28 dBr at 20 MHz
frequency offset, and the maximum of –40 dBr and –53 dBm/MHz at 30 MHz frequency offset and above.
The transmitted spectral density of the L-STF, L-LTF, L-SIG, BPSK-Mark1, and BPSK-Mark2 fields of the
transmitted signal shall fall within the spectral mask, as shown in Figure 17-13 (Transmit spectrum mask for
20 MHz transmission).
For operation using 20 MHz channel spacing, the transmitted spectrum of the WUR-Sync and WUR-Data
fields shall have a 0 dBr (dB relative to the maximum spectral density of the signal) bandwidth not
exceeding 4.5 MHz, –15 dBr at 3.5 MHz frequency offset, –20 dBr at 11 MHz frequency offset, –28 dBr at
20 MHz frequency offset, and the maximum of –40 dBr and –53 dBm/MHz at 30 MHz frequency offset and
above.
The transmitted spectral density of the WUR-Sync and WUR-Data fields of the transmitted signal shall fall
within the spectral mask, as shown in Figure 30-11 (Transmit spectrum mask for WUR-Sync and WUR-
Data fields of WUR Basic PPDU transmission(11ba)).
[etc.]
are sufficient to define a valid waveform?
What if say I transmitted an On Symbol with random energy at one edge
of the mask like this (energy shown in red):
and transmitted an Off Symbol as no energy -- would that be a valid
waveform that a WUR receiver needs to be able to handle? It meets
the spectral mask (normative requirement in 30.3.12.1), and there's
more than 20 dB more power in On than in Off (normative requirement
in 30.3.12.4).
I think Joe has done an admirable job in 22/1035 of trawling through
the spec to find the actual normative requirements, and it does
appear to me that these are lacking. So at this stage I am minded to
support the resolution proposed in 22/1035 and oppose a resolution
to reject the comment.
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: Steve Shellhammer <sshellha@xxxxxxxxxxxxxxxx>
Sent: Thursday, 8 September 2022 22:28
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 ---
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
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