Re: [STDS-802-11-TGM] 11mc/D5.0 CID 7177 ("prefer not LDPC")

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

Sorry, suffered a glitch! Should have read:

> In other words, is this change transparent to “older” systems and can we be sure there will not be any issues with backwards compatibility?

I think so, because it's a "should (not)" not a "shall (not)":

A STA should not transmit a frame with the TXVECTOR parameter FORMAT set to HT_MF, HT_GF or VHT and the TXVECTOR parameter FEC_CODING set to LDPC_CODING if the RA of the frame corresponds to a STA from which it has received a frame containing an Extended Operating Mode field and the most recent Extended Operating Mode field it has received from that STA had the No LDPC field equal to 1.

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: ***** IEEE stds-802-11-tgm List ***** [mailto:STDS-802-11-TGM@xxxxxxxx] On Behalf Of Mark Rison
Sent: 23 February 2016 18:18
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] 11mc/D5.0 CID 7177 ("prefer not LDPC")

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

Hello Sigurd,

Thanks for the review.

> In other words, is this change transparent to “older” systems and can we be sure there will not be any issues with backwards compatibility?

I think so, because it's a "should" not a "may":

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: Sigurd Schelstraete [mailto:sschelstraete@xxxxxxxxxxxxx]
Sent: 23 February 2016 17:41
To: Mark Rison; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: RE: 11mc/D5.0 CID 7177 ("prefer not LDPC")

Mark,

Thanks for the summary. Is there any impact on systems that are built according to the 802.11ac-2013 Amendment? In other words, is this change transparent to “older” systems and can we be sure there will not be any issues with backwards compatibility?

Regards,

Sigurd

From: ***** IEEE stds-802-11-tgm List ***** [mailto:STDS-802-11-TGM@xxxxxxxx] On Behalf Of Mark Rison
Sent: Tuesday, February 23, 2016 1:40 AM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGM] 11mc/D5.0 CID 7177 ("prefer not LDPC")

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

The following resolution has been proposed in the BRC and accepted in

principle. Please email me or the reflector if you have any concerns,

or if you would like to see the signalling extended to support other

PPDU transmission options (e.g. STBC or SGI).

Identifiers

Comment

Proposed change

CID 7177

Mark RISON

10.16

1342.21

In order to reduce power consumption, there should be a dynamic mechanism to request to a peer that it not transmit to the requesting device using LDPC

Add a mechanism, based on extending Operating Mode Notification or otherwise

Discussion:

LDPC provides additional link margin, but is very computationally intensive on receive compared with BCC, and hence significantly less power-efficient. It is therefore desirable for a receiver to be able to indicate to a transmitter that LDPC need not be used.

This can be done by extending the Operating Mode Notification element. Unfortunately, this has no reserved bits left. Fortunately, this is extensible. Unfortunately, the Operating Mode Notification frame is not trivially extensible, as it uses the Operating Mode field rather than the Operating Mode Notification element, and it might be followed by VSIEs etc.

Proposed changes:

Change 9.4.2.166 as follows:

9.4.2.166 Operating Mode Notification element

~~The Operating Mode Notification element is used to notify STAs that the transmitting STA is changing its operating channel width, the maximum number of spatial streams it can receive, or both.~~ The format of the Operating Mode Notification element is defined in Figure 9-570 (Operating Mode Notification element).

Editor: In Figure 9-570—Operating Mode Notification element add a cell on the right saying “Extended Operating Mode” and show this as 0 or 1 octets.

The Element ID and Length fields are defined in 9.4.2.1 (General).

The Operating Mode field is defined in 9.4.1.53 (Operating Mode field).

The Extended Operating Mode field is defined in 9.4.1.53b (Extended Operating Mode field) and is optional.

Add a new Subclause 9.4.1.53b as follows:

9.4.1.53b Extended Operating Mode field

The Extended Operating Mode field is shown in Figure 9-117b (Extended Operating Mode field).

Editor: Insert a figure like Figure 9-117 but with just a b0 saying “No LDPC” and b1-b7 reserved.

The No LDPC field is set to 1 to indicate that the STA transmitting this field prefers not to receive LDPC-encoded PPDUs; it is set to 0 otherwise.

Add a new row to Table 9-76—Element IDs:

Extended Operating Mode Notification (see 9.4.2.166b (Extended Operating Mode Notification element))

<ANA>

Yes

Add a new Subclause 9.4.2.166b as follows:

9.4.2.166b Extended Operating Mode Notification element

The format of the Extended Operating Mode Notification element is defined in Figure 9-570b (Extended Operating Mode Notification element).

Editor: Copy Figure 9-570 as Figure 9-570b here, changing “Operating Mode” to “Extended Operating Mode”.

The Element ID and Length fields are defined in 9.4.2.1 (General).

The Extended Operating Mode field is defined in 9.4.1.53b (Extended Operating Mode field).

Change the start of 9.6.23.4 as follows:

9.6.23.4 Operating Mode Notification frame format

The Operating Mode Notification frame is an Action frame of category VHT. It is used to notify STAs that the transmitting STA is changing one or more of its operating channel width, the maximum number of spatial streams it can receive, ~~or both~~and its LDPC receive preference.

Add a row at the end of Table 9-417—Operating Mode Notification frame Action field format:

4	Zero or one Extended Operating Mode Notification element

Add the following as the penultimate paragraph of 10.16 LDPC operation:

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

_______________________________________________________________________________

IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.

SELF SERVICE OPTION: Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button.

Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________

This email, including its contents and any attachment(s), may contain confidential information of Quantenna Communications, Inc. and is solely for the intended recipient(s). If you may have received this in error, please contact the sender and permanently delete this email, its contents and any attachment(s).

_______________________________________________________________________________

IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.

Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________

IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.