Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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