Re: [STDS-802-11-TGBN] [EXT] Re: [STDS-802-11-TGBN] CR MAC Request

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

I'm sorry, I missed this thread among the deluge last week!

My concern, which may be similar to Rony's, is that in 25/0742(r4) we have:

If the STA reports in the Multi-STA Block Ack frame that at least one of the frames requiring an immediate response was not successfully received, then the STA shall set the In-Device Error Flag subfield to:
- 1 if at least one of the unsuccessful receptions is due to an in-device error that occurred during the reception of the PPDU containing these frame(s)
- 0 if either none of the unsuccessful receptions is due to an in-device error or the source of the error is unknown.

which means that:

a) If one unsuccessful frame rx was due to an IDC error, you set the bit

to say "IDC error", even if there were 99 other unsuccessful frame rxes

that were due to SNR or whatever. This will falsely suggest to the AP

that it should stick with the current MCS

b) It is not clear what to set the bit to if there was one frame with

an IDC error and another frame with an unknown error source, because both

1 if at least one of the unsuccessful receptions is due to an in-device error that occurred during the reception of the PPDU containing these frame(s)

and

0 if either none of the unsuccessful receptions is due to an in-device error or the source of the error is unknown.

apply (to different frames within the same A-MPDU).

Thanks,

Mark

Mark RISON, Standards Architect, WLAN English/Esperanto/Français

Samsung Cambridge Solution Centre Tel: +44 1223 434600

1 Cambridge Square, Cambridge CB4 0AE Fax: +44 1223 434601

ROYAUME UNI WWW: http://www.samsung.com/uk

From: Rony Ross <0000491f5321510d-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, 31 July 2025 18:23
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] [EXT] Re: [STDS-802-11-TGBN] CR MAC Request

Hi Sherief,

Please see my comments inline

Thanks,

Rony

From: Sherief Helwa <shelwa@xxxxxxxxxxxxxxxx>
Sent: Thursday, July 31, 2025 10:52 AM
To: Rony Ross <rony.ross@xxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: [EXT] Re: [STDS-802-11-TGBN] CR MAC Request

Hi Rony,

Thanks for your feedback! Please see my response inline.

Regards,

Sherief

From: Rony Ross <0000491f5321510d-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, July 29, 2025 10:51 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] [EXT] Re: [STDS-802-11-TGBN] CR MAC Request

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Sherief,

I’ve attached technical comments on 25/0742r2

Mainly:

The receiver cannot account for the failing MPDUs. It can only account for its ability to properly perform reception. Therefore, I suggest naming the bit “Receiver Performance Degradation”

[SH] I don’t mind revisiting the naming but I suggest we keep names as is for now to avoid confusion and last minutes changes that might make some members lose track.

[RR] The original name seems to be confusing. As mentioned in some comments, there are cases in which the receiver failures would not necessarily manifest as errors in the BACK

As condition for setting this bit I suggest using “experienced significant internal device-related performance degradation”. It is up to the device to decide what is considered “significant”. There is no need to specify additional rules.

[SH] I agree on the concept that this should be up to the device, i.e., the non-AP STA, to decide which is more significant. But sorry, didn’t get the first part of this point.

[RR] The STA knows that it experienced significant receiver performance degradation. It has no way of knowing how many MPDUs failed and how these failures manifest in the BACK. Therefore, “Receiver Performance Degradation” is the only thing that the STA can indicate in the BACK. The rules in the following section cannot be followed and should be removed:

“following the rules below:

If the STA reports in the Multi-STA Block Ack frame that all the frame(s) requiring an immediate response are successfully received, then the STA shall set the In-Device Error Flag subfield to 0.

If the STA reports in the Multi-STA Block Ack frame that at least one of the frames requiring an immediate response is not successfully received, then the STA shall set the In-Device Error Flag subfield to:

1 if at least one of the unsuccessful receptions is due to an in-device error that occurred during the reception of the PPDU containing these frame(s)

0 if either none of the unsuccessful receptions is due to an in-device error or the source of the error is unknown.”

As there are concerns regarding the impact of this bit on the AP’s rate selection algorithm, I also suggest replacing the following note

“If the AP receives an indication from the DUO STA that an in-device error has occurred during the reception of the soliciting PPDU, then the expectation is that the AP does not consider the failed reception of any of the frames that solicited an immediate response and contained in the soliciting PPDU as an input to the AP’s rate selection algorithm, which is by itself out of scope of the standard.”

with “If the AP receives an indication from the DUO STA that Receiver Performance Degradation occurred during reception of the soliciting PPDU, it is expected that the AP incorporate this indication into its rate selection algorithm. Specifically, the AP may attribute acknowledgment failures to internal receiver degradation rather than to adverse channel conditions.. The AP’s rate selection algorithm is out of scope of the standard.”

Thanks,

Rony

From: Sherief Helwa <00002dded7ae4daf-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, 1 May 2025 00:29
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] [EXT] Re: [STDS-802-11-TGBN] CR MAC Request

Hi Alfred,

Can you please add the following documents to the MAC queue?

25/742 MAC-PDT-CR-37_12_2-internal-error-indication
25/743 MAC-PDT-CR-37_12_4-PUO
25/744 MAC-PDT-CR-37_12_5-parameter-update

Regards,

Sherief

From: Liwen Chu <liwen.chu@xxxxxxx>
Sent: Wednesday, April 16, 2025 1:11 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] [EXT] Re: [STDS-802-11-TGBN] CR MAC Request

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Alfred,

Please add the following CR document to the MAC queue:

https://mentor.ieee.org/802.11/dcn/25/11-25-0669-00-00bn-cr-cc50-mac-cids-in-clause-37-9-1.docx

Best Regards,

Liwen

From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Sent: Thursday, April 3, 2025 11:07 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [EXT] Re: [STDS-802-11-TGBN] CR MAC Request

Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button

Hi Alfred,

Please add the following (presented) CR doc to agenda for MAC queue for SP:

https://mentor.ieee.org/802.11/dcn/25/11-25-0479-01-00bn-cr-for-cid-1378.docx

Regards,

Dibakar

From: Eunsung Park <esung.park@xxxxxxx>
Sent: Thursday, April 3, 2025 7:47 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] CR PHY request

Hi Alfred,

Could you please add the following CR documents to the PHY queue?

11-25-0525-00-00be-cc50-cr-for-38-3-15-10-1-and-38-3-15-10-5
11-25-0547-00-00be-cc50-cr-for-38-3-15-10-2-uhr-stf-for-drus

Best regards,

Eunsung

From: Eunsung Park [mailto:esung.park@xxxxxxx]
Sent: Wednesday, April 2, 2025 10:18 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] CR PHY request

Hi Alfred,

Could you please add the following CR document to the PHY queue?

11-25-0524-00-00bn-cc50-cr-for-38-3-15-10-3-csd-for-dru-transmission

Best regards,

Eunsung

From: Eunsung Park [mailto:esung.park@xxxxxxx]
Sent: Monday, March 31, 2025 8:10 AM
To: 'STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx' <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>; 'asterjadhi@xxxxxxxxx' <asterjadhi@xxxxxxxxx>
Cc: hg.cho@xxxxxxx
Subject: CR PHY request

Hi Alfred,

Could you please add the following CR document to the PHY queue?

11-25-0522-00-00be-cc50-cr-for-38-3-3-ru-mru-restrictions-for-20-mhz-operation

Best regards,

Eunsung

From: Eunsung Park [mailto:esung.park@xxxxxxx]
Sent: Wednesday, March 26, 2025 12:39 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] TGbn MAC/PHY Teleconference of Monday, 24 March 2025

Hi Alfred,

Please add the following CR documents to the PHY agenda?

11-25-0518-00-00bn-cc50-cr-for-38-3-15-2-2-cyclic-shift-for-uhr-modulated-fields
11-25-0520-00-00bn-cc50-cr-for-38-3-15-10-4-csd-index-assignment-for-dru-uhr-stf-transmission

Best regards,

Eunsung

From: Eugene Baik [mailto:0000419888923000-dmarc-request@xxxxxxxxxxxxxxxxx]
Sent: Saturday, March 22, 2025 6:37 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] TGbn MAC/PHY Teleconference of Monday, 24 March 2025

Hi Alfred,

Can you add

11-25-0509-00-00bn – CC50 CID resolutions for 38.1

to the agenda, if it’s not too late?

Thanks,

Eugene

From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Sent: Thursday, March 20, 2025 4:42 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] TGbn MAC/PHY Teleconference of Monday, 24 March 2025

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hello all,

We have a MAC/PHY teleconference scheduled for Monday 24 March 2025, and I am finalizing the agenda (planned to be posted tomorrow). Currently there is only one PHY submission in the queue so I would like to ask members to send me additional requests for PHY CR submissions asap and no later than tomorrow, Friday 17:00 ET. This way we can use the teleconferences in an efficient way and start the comment resolution process.

Guidelines for scheduled PHY conf calls:

· Members are invited to send submission requests to be added to the PHY submissions queue.

· Requests may explicitly indicate if the requestor prefers to discuss his/her submission at a particular PHY conf call. If there is no such explicit indication then the submission will be added by default to the PHY submissions queue and will be scheduled for presentation in a subsequent PHY conference call during which there are at least 3 submissions available for discussion.

· A scheduled PHY conference call will be cancelled if the planned PHY agenda for that particular conference call does not have at least 3 queued presentations or at least one queued presentation with an explicit request.

Regards,

Alfred

Alfred Asterjadhi, PhD

IEEE802.11 TGbe/TGbn Chair,

Qualcomm Technologies Inc.

asterjadhi@xxxxxxxxx

aasterja@xxxxxxxxxxxxxxxx

Cell #: +1 858 263 9445

Office #: +1 858 658 5302

To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1

Image removed by sender.

To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1