Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
--- 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:
“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> --- 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>
--- 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.
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>
--- 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:
[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.
[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.
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 |