送信: 2026 年 7 月 16 日 (木曜日) 0:05
宛先: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
件名: Re: [STDS-802-11-TGBN] On "26/0314 LB291 CR for Co-BF and Co-SR Error Recovery Sequence"
Date: Wednesday, 15. July 2026 at 16:56
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>; Mikhail Liubogoshchev (Nokia) <mikhail.liubogoshchev@xxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] On "26/0314 LB291 CR for Co-BF and Co-SR Error Recovery Sequence"
|
|
CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
|
送信: 2026 年 7 月 15 日 (水曜日) 23:38
宛先: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
件名: Re: [STDS-802-11-TGBN] On "26/0314 LB291 CR for Co-BF and Co-SR Error Recovery Sequence"
Date: Wednesday, 15. July 2026 at 03:21
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] On "26/0314 LB291 CR for Co-BF and Co-SR Error Recovery Sequence"
|
|
CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
|
-
Revised the proposed text from normative statements to informative NOTEs, reflecting the task group discussions.
-
Retained the second NOTE for the Co-SR sequence.
送信: 2026 年 7 月 14 日 (火曜日) 4:20
宛先: Sindhu Verma <sindhu.verma@xxxxxxxxxxxx>
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
件名: Re: [STDS-802-11-TGBN] On "26/0314 LB291 CR for Co-BF and Co-SR Error Recovery Sequence"
送信: 2026 年 7 月 12 日 (日曜日) 16:00
宛先: Aio, Kosuke (SEC)
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
件名: Re: [STDS-802-11-TGBN] On "26/0314 LB291 CR for Co-BF and Co-SR Error Recovery Sequence"
Hi Kosuke,
In view of your comments regarding the ambiguity of “may not” in the specification language, I have the following suggestion for your 1st paragraph. The 2nd sentence in that paragraph is not needed as the CBF-Trigger occurs after the ICF/ICR in the coordinated AP BSS and so, does not impact the sequence until the elapsing of ICF-ICR time
NOTE—If the Co-BF coordinating AP transmits an ICF to all of the non-AP STAs scheduled in the Co-BF Invite frame and does not receive an ICR frame from any of those non-AP STAs,
it may refrain from
is expected not to
transmitting a Co-BF Trigger frame
to the Co-BF coordinated AP until a new Co-BF Invite and Co-BF Response frame exchange is completed. If the coordinating AP does not transmit a Co-BF Trigger, Before If the Co-BF coordinating AP transmits any frame, it
is expected to wait for the end
of the ICF and ICR frame exchange between the Co-BF coordinated AP and its associated recipient STAs, if any. (#5116) before transmitting any other frame.
For your 2nd paragraph, I suggest removing it entirely, as it does not alter the CBF frame sequence in any manner.
NOTE—If the Co-BF coordinated AP transmits an ICF to all of the non-AP STAs scheduled in the Co-BF Response frame and does not receive an ICR frame from any of those non-AP
STAs, it is expected not to transmitting
a Co-BF PPDU in response to a Co-BF Trigger frame received from the Co-BF coordinating AP until a new Co-BF Invite and Co-BF Response frame exchange is completed. (#8551)
Regards,
Sindhu
Hi Junghoon,
Understood. I agree to defer the SP to next week’s Joint session.
Could you remove my SP(26/0314) in this MAC ad-hoc agenda and move to F2F JOINT agenda?
Best Regards,Kosuke (SONY)
差出人: Junghoon Suh <000017d35818e7c0-dmarc-request@xxxxxxxxxxxxxxxxx>
送信: 2026 年 7 月 9 日 (木曜日) 20:21
宛先: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
件名: Re: [STDS-802-11-TGBN] On "26/0314 LB291 CR for Co-BF and Co-SR Error Recovery Sequence"
Hi, Kosuke I did not hear the opinion from others, and want to have some offline discussion for the consensus. Could you defer the SP to the Joint session? Regards Junghoon Suh Mobile: +1-6137005790 Mail: junghoon. suh@ huawei. com From: Kosuke. Aio@ sony. comHi, KosukeI did not hear the opinion from others, and want to have some offline discussion for the consensus.
Could you defer the SP to the Joint session?
Regards
To:Junghoon Suh <Junghoon.Suh@xxxxxxxxxx>;STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>Date:2026-07-09 05:04:51Subject:Re: [STDS-802-11-TGBN] On "26/0314 LB291 CR for Co-BF and Co-SR Error Recovery Sequence"
Hi Junghoon,
Thank you for the excellent suggestions. I would be very glad to have an offline F2F discussion with you early next week.However, as long as it does not lead to a critical system failure, how about we discuss this termination issue in the context of the currently deferred CIDs?
Regarding your concern about the Coordinating AP silently dropping the Co-BF Trigger frame, I completely share your view.I have two deferred CIDs (along with #5960) that specifically address explicit signaling and transmission patterns from either the coordinating or coordinated AP.I believe your idea of adding an explicit termination option fits perfectly under the umbrella of those deferred CIDs. We can thoroughly discuss that solution during our F2F meeting.
For the current proposed spec (26/0314r8), if "not transmitting/not responding" is the expected baseline choice, we can keep the updated NOTEs to establish this baseline behavior, and then layer the explicit termination signaling option on top of it later through the deferred CIDs.
Given this approach, I would like to run the SP for these two NOTEs during the current MAC Ad-Hoc. Would this be acceptable to you?
Please let me know your thoughts.
Best regards,Kosuke (SONY)
差出人: Junghoon Suh <Junghoon.Suh@xxxxxxxxxx>
送信: 2026 年 7 月 9 日 (木曜日) 7:16
宛先: Aio, Kosuke (SEC) <Kosuke.Aio@xxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
件名: RE: [STDS-802-11-TGBN] On "26/0314 LB291 CR for Co-BF and Co-SR Error Recovery Sequence"
Hi, Kosuke Can we run this SP in the TGbn Joint session next week? This is a Joint topic, but some of us, especially PHY folks do not attend the MAC Ad-Hoc this week. If we extend the interpretation of the existing NOTE (the one regarding subsetHi, Kosuke
Can we run this SP in the TGbn Joint session next week? This is a Joint topic, but some of us, especially PHY folks do not attend the MAC Ad-Hoc this week.
If we extend the interpretation of the existing NOTE (the one regarding subset of STAs) to the Entire set just like Sindhu interpreted, then, we do not need your suggested second Note.
As for your suggested first Note, I am still concerned about Not sending the Co-BF Trigger Frame without any Termination bit. Can we have a little F2F offline discussion early next week before the Joint Session begins?
Regards
Junghoon Suh
From: Kosuke.Aio@xxxxxxxx [mailto:Kosuke.Aio@xxxxxxxx]
Sent: July 8, 2026 6:00 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] On "26/0314 LB291 CR for Co-BF and Co-SR Error Recovery Sequence"
Hi all,
(especially @Sindhu Verma @Sherief Helwa @You-Wei Chen
I have revised the contribution to convert the proposed text for CIDs #5116 and #8551 from normative statements to informative NOTEs, in line with the task group discussions.
Could you please review it again and share your feedback?
(SP is scheduled for tomorrow PM)
Best regards,
Kosuke (SONY)
差出人: n81147@xxxxxxxxx <n81147@xxxxxxxxx>
送信: 2026 年 7 月 7 日 (火曜日) 23:55
宛先: Aio, Kosuke (SEC) <Kosuke.Aio@xxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
件名: Re: [STDS-802-11-TGBN] On "26/0314 LB291 CR for Co-BF and Co-SR Error Recovery Sequence"
A third reason to not put "may not" (or "may", "shall" or "should") is that a note in text is informative, and may, shall and should are normative. FWIW Best regards Ben On 7/7/2026 1: 49 AM, Kosuke. Aio@ sony. com wrote: Hi Sindhu, Thank you for
A third reason to not put "may not" (or "may", "shall" or "should") is that a note in text is informative, and may, shall and should are normative.
FWIW
Best regards
Ben
On 7/7/2026 1:49 AM, Kosuke.Aio@xxxxxxxx wrote:
Hi Sindhu,
Thank you for your feedback. I agree with moving this to an informative NOTE to preserve implementation flexibility.
However, I would prefer to avoid using the phrase "may not" for two reasons:
- IEEE SA Style Manual: The exact phrase "may not" is strictly deprecated in IEEE standards because of its ambiguity (it can mean either "might not" or "must not").
- State-Machine Ambiguity: As Junghoon correctly pointed out earlier, leaving this as a pure option (e.g., "might not" or "may choose not to") leaves the baseline behavior undefined. This does not solve the fundamental issue of the Coordinated AP potentially waiting indefinitely for a Trigger.
To avoid a mandatory "shall not" while still providing clear guidance on the baseline fallback behavior, how about using descriptive language in the NOTE, such as "is expected not to transmit" or "typically does not transmit"?
This perfectly complies with the IEEE guidelines for informative NOTEs (no mandatory keywords) while clearly addressing the deadlock concern Junghoon mentioned.
Let me know if this wording is acceptable to you.
Best regards,
Kosuke (SONY)
差出人: Sindhu Verma
送信: 2026 年 7 月 7 日 (火曜日) 17:14
宛先: Aio, Kosuke (SEC)
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx; Junghoon Suh
件名: Re: [STDS-802-11-TGBN] On "26/0314 LB291 CR for Co-BF and Co-SR Error Recovery Sequence"
Hi Kosuke,
>>However, as we look into the physical operation, applying this interpretation to the current NOTE leaves significant ambiguity, as a Co-BF PPDU where all spatial streams have zero energy is technically nonsensical.
I don’t think it is “technically nonsensical” or “physically nonsensical” as you have been claiming. For example, not transmitting the CBF PPDU amounts to transmitting zero energy on all spatial streams too. Moreover, this is an optional behavior per the existing note which your text intends to make mandatory or recommended. Also, as mentioned earlier the fact that “partial set” was changed to “subset” should also indicate to you how others’ feedback and interpretations were taken into account in framing the original text..
>>For now, to avoid any potential conflict with the existing NOTE and move forward with consensus, I am willing to modify the first two proposed paragraphs to remove the mandatory "shall not" statements and change the language to "should not" or "is expected not to" (or convert them into an informative NOTE).
Changing an optional behavior to a recommended behavior is also something that needs wider discussion. If you add a note with “may not,” it will not contradict the original note and its interpretation and hence, is acceptable.
Regards,
Sindhu
On Mon, Jul 6, 2026 at 11:25 AM Kosuke.Aio@xxxxxxxx <Kosuke.Aio@xxxxxxxx> wrote:
Hi Sindhu and Junghoon,
Thank you for the follow-up discussion.
Thank you for clarifying the original intent of the NOTE. I completely agree with your exact concern regarding the Coordinating AP's behavior. If it receives zero ICRs, leaving the next step purely to implementation—such as silently aborting the sequence while the Coordinated AP is left expecting a Trigger—would cause a critical state-machine issue. This is exactly the deadlock scenario I want to prevent.
I understand your point and agree that from a purely logical or terminology standpoint, "subset" can be interpreted to include the case where 100% of the scheduled STAs fail to respond with an ICR.
However, as we look into the physical operation, applying this interpretation to the current NOTE leaves significant ambiguity, as a Co-BF PPDU where all spatial streams have zero energy is technically nonsensical. Since this also differs from the original author's (Junghoon's) intention, we will likely need further discussion on how to properly refine this text in a future revision.
For now, to avoid any potential conflict with the existing NOTE and move forward with consensus, I am willing to modify the first two proposed paragraphs to remove the mandatory "shall not" statements and change the language to "should not" or "is expected not to" (or convert them into an informative NOTE).
Would this modification resolve your concerns?
Best regards,
Kosuke (SONY)
差出人: Junghoon Suh <000017d35818e7c0-dmarc-request@xxxxxxxxxxxxxxxxx>
送信: 2026 年 7 月 3 日 (金曜日) 22:20
宛先: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
件名: Re: [STDS-802-11-TGBN] On "26/0314 LB291 CR for Co-BF and Co-SR Error Recovery Sequence"
Hi, Sindhu The original intention of the Note was only targeted to the partial set of eMLSR/DPS STAs not being responsive during the ICF/ICR exchanges. But, your interpretation does not change the behavior of APs so, it is also ok to me to leave
Hi, Sindhu
The original intention of the Note was only targeted to the partial set of eMLSR/DPS STAs not being responsive during the ICF/ICR exchanges.
But, your interpretation does not change the behavior of APs so, it is also ok to me to leave it as it is without adding further mandatory statement for the entire set not being responsive.
But, for the Co-BF Coordinating AP side, if it does not receive any ICR from any of its scheduled STAs, the behavior is not crystal clear, though we can leave it as a Coordinating AP’s implementation choice, sending the Co-BF Trigger frame only for the Coordinated AP or Not sending the Co-BF Trigger frame without notice when the Coordinated AP is expecting. Either way does not sound good to me.
Regards
Junghoon Suh
From: Sindhu Verma <sindhu.verma@xxxxxxxxxxxx>
Sent: Friday, July 3, 2026 5:17 AM
To: Junghoon Suh <Junghoon.Suh@xxxxxxxxxx>
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] On "26/0314 LB291 CR for Co-BF and Co-SR Error Recovery Sequence"
Hi Junghoon,
Thanks for your feedback. I have discussed this with one of the co-authors of the document 25/2033r4 which inserted the note and concluded that total failure is a valid interpretation of the note. Since the note was approved by consensus, I think the members' interpretation also needs to be considered. Actually, an earlier version 25/2033r2 mentioned "partial set," which was later changed to "subset". My agreement to the text was based on this interpretation.
The currently agreed note allows sufficient flexibility for an implementation in this scenario which is better than inserting a mandatory requirement.
Regards,
Sindhu
On Thu, Jul 2, 2026 at 7:33 PM Junghoon Suh <000017d35818e7c0-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Hi, Kosuke and Sindhu
Sorry to jump in to your discussion.
The NOTE was proposed by me and I can tell you that the NOTE was targeted to the subset (not the entire set) being non-responsive during the ICF/ICR exchanges.
For the entire set not being responsive, I have my proposal for the solution but open for further discussion.
Regards
Junghoon Suh
From: Kosuke.Aio@xxxxxxxx [mailto:Kosuke.Aio@xxxxxxxx]
Sent: July 1, 2026 5:52 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] On "26/0314 LB291 CR for Co-BF and Co-SR Error Recovery Sequence"
Hi Shindhu,
Thank you for your response.
I agree that logically, such as in the EMLSR link bitmap you mentioned, a "subset" can be all zeros (the entire set).
However, applying this "100% subset" interpretation to the Co-BF NOTE leads to a physical impossibility. If zero STAs respond with an ICR, the AP would be allowed to transmit a Co-BF PPDU where all spatial streams have zero energy. This is a physically nonsensical and meaningless operation.
If we consider "subset" to encompass the entire set, the specification must explicitly address how to handle this impossible transmission scenario. Otherwise, an AP might silently abort to avoid transmitting a dummy zero-energy PPDU, which leaves the Coordinated AP in a deadlock waiting for a Co-BF Trigger.
This proposed text simply provides the necessary normative rule for this 100% failure case to prevent state-machine deadlocks, without restricting the implementation flexibility for partial failures.
I kindly request your support in retaining these paragraphs.
Best Regards,
Kosuke (SONY)
差出人: Sindhu Verma
送信: 2026 年 7 月 1 日 (水曜日) 17:07
宛先: Aio, Kosuke (SEC)
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
件名: Re: On "26/0314 LB291 CR for Co-BF and Co-SR Error Recovery Sequence"
Hi Kosuke,
In a mathematical or technical context, a “subset” can also be an “improper subset” i.e. it can also be the entire set. This is valid for many instances in the specification unless explicitly clarified. For example, consider the EMLSR link bitmap field definition. The “subset of enabled links” does not mean that all the enabled links of a non-AP MLD cannot be part of the EMLSR link bitmap.
Members agreed to this note with the understanding that a subset can be the entire set. It allows ample implementation flexibility. It also contradicts your proposed first and second paragraphs.
Regards,
Sindhu
On Fri, Jun 26, 2026 at 9:40 PM Kosuke.Aio@xxxxxxxx <Kosuke.Aio@xxxxxxxx> wrote:
Hi Sindhu,
Thank you for your feedback
I would like to clarify that the cited NOTE and my proposed text address two entirely different scenarios, and therefore do not contradict each other:
- The existing NOTE handles a "partial failure" scenario where a subset of STAs do not respond. In this case, it makes sense to proceed with the remaining responsive STAs using zero-energy streams for the missing ones.
- My proposal handles a "total failure" scenario where none of the scheduled STAs respond. In this case, there are no valid recipients left, making a Co-BF PPDU transmission impossible and meaningless.
Without our proposed text, the total failure scenario remains undefined, which leads to the multi-AP state-machine deadlock.
Since my text complements the existing NOTE by closing this specific gap, I kindly request your support in retaining these paragraphs.
Best regards,
Kosuke (SONY)
差出人: Sindhu Verma
送信: 2026 年 6 月 26 日 (金曜日) 20:57
宛先: Aio, Kosuke (SEC)
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
件名: Re: On "26/0314 LB291 CR for Co-BF and Co-SR Error Recovery Sequence"
Hi Kosuke,
Thanks for your responses and agreeing to defer/reconsider your 3rd paragraph.
Even for your 1st and 2nd paragraphs, there is a conflict with provisions we already agreed to in the specification. The text below already accounts for the behavior in question along with the implementation flexibility that members agreed to allow. It was arrived at with consensus. Hence, I request you to point the commenters to this text rather than introduce language that contradicts it.
37.14.2.1.4 Co-BF transmission procedure: NOTE—For the case where a subset of non-AP STA(s) scheduled in the Co-BF Invite frame or the Co-BF Response frame did not respond with an ICR during the ICF/ICR exchanges taking place right after the Co-BF Invite frame and Co-BF Response frame exchanges, the Co-BF coordinating AP and (or) Co-BF coordinated AP might transmit zero energy on the spatial streams corresponding to the non-responsive STA(s) in the ensuing Co-BF PPDU transmission. If an AP chooses to transmit zero-energy streams, the zero-energy on the stream(s) spans the UHR-STF, UHR-LTF, and Data fields (including the Padding and FCS) of the Co-BF PPDU.(#7381, #8954)
Regards,
Sindhu
On Thu, Jun 25, 2026 at 7:15 PM Kosuke.Aio@xxxxxxxx <Kosuke.Aio@xxxxxxxx> wrote:
Hi Sindhu,
Thank you for your comments. I really appreciate your feedback.
Regarding the first two paragraphs, I see why you might consider the behavior obvious. However, since we received at least 10 CIDs asking for normative clarification on this issue, I believe we need to explicitly specify the behavior without over-constraining implementations.
From a protocol state machine perspective, D1.5 states that the Co-BF Trigger frame is transmitted "after the end of the PPDU carrying the ICR." If an ICR is not received, this condition is technically never satisfied. Introducing explicit normative text (like "shall not") is necessary to resolve this ambiguity, prevent potential deadlocks, and guarantee interoperability.
Nevertheless, I agree that we must avoid hindering the AP's implementation flexibility. If you have any concerns regarding the behavior itself, please let me know.
Finally, I completely agree with your comment on the last paragraph. I would like to consider this a bit further, so I am planning to mark the related comments as "Deferred" for the next SP.
Best regards,
Kosuke (SONY)
差出人: Sindhu Verma
送信: 2026 年 6 月 25 日 (木曜日) 18:23
宛先: Aio, Kosuke (SEC)
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
件名: On "26/0314 LB291 CR for Co-BF and Co-SR Error Recovery Sequence"
Hi Kosuke,
Your first 2 proposed paragraphs are trying to mandate that if none of the EMLSR/DPS non-APs of an AP respond with ICR and there were no other non-APs in the corresponding CBF-invite/response, the AP does not proceed with the CBF sequence. I think this is obvious behavior and any variations can be left to the AP implementation depending on its reaction time. If we do not trust that, we need to specify additional obvious behavior such as the coordinated AP not transmitting an MU-BAR if it does not transmit a CBF PPDU. Doesn’t the current CBF sequence already state that the frames must be exchanged in that particular order?
Your 3rd proposed paragraph ((#7382) When the Co-BF coordinating AP schedules to transmit another Co-BF Trigger frame within the current TXOP, the Co-BF coordinated AP may transmit a CF-End frame to the Co-BF coordinating AP in place of an MU-BAR Trigger frame to indicate the termination of its participation in the Co-BF transmission sequence if the Co-BF co-ordinated AP cannot participate in the previous transmission. When receiving the CF-End frame from the Co-BF coordinated AP, the Co-BF coordinating AP shall not transmit another Co-BF Trigger frame to the Co-BF coordinated AP until a new Co-BF Invite and Co-BF Response frame exchange is completed.) alters the currently specified CBF data sequence and conflicts with what has already been agreed in D1.5 on TXOP termination:
(#6530, 11447)The coordinating AP should transmit a CF-End frame at the end of the sequence to terminate it. The CF-End frame shall be transmitted by the coordinating AP 2×aSIFSTime plus the duration of the acknowledgment sequence between the Co-BF coordinated AP and its scheduled non-AP STAs indicated by the Ack Sequence Duration field in the Co-BF Response frame, after the end of the PPDU carrying the BlockAck or Multi-STA BlockAck frame(s) transmitted by the recipient non-AP STA(s) associated with the Co-BF coordinating AP. The frame sequence is shown in Figure 37-10 (The Co-BF transmission sequence including CF-End frames transmitted by the coordinating AP and optionally by the coordinated AP).
(#6530, 11447)The coordinated AP should transmit another CF-End frame aSIFSTime after the end of the first CF-End frame transmitted by the coordinating AP. The coordinated AP shall not transmit a CF-End frame unless the coordinating AP has already transmitted a CF-End frame. The CF-End frame transmission by the coordinated AP is also shown in Figure 37-10 (The Co-BF transmission sequence including CF-End frames transmitted by the coordinating AP and optionally by the coordinated AP).
(#6530)The non-AP STA(s) associated with the coordinating AP or the coordinated AP, and that is applying the extended timeout period may interrupt that extended timeout period and switch to either LC mode for DPS STAs or listen mode for EMLSR STAs once they receive any of the CF-End frames.
(#6530) NOTE 3—The CF-End frame serves as a Co-BF TXOP termination indication to the coordinated AP as well as the non-AP STAs associated to the coordinating and the coordinated APs.
In view of the above, I request that you withdraw your 3rd paragraph and modify the first two to possibly state expected behavior in the form of a note.
Regards,
Sindhu
On Wed, Jun 24, 2026 at 4:57 PM Kosuke.Aio@xxxxxxxx <Kosuke.Aio@xxxxxxxx> wrote:
Hi Alfred
I've uploaded the latest version. Could you add it to JOINT (or MAC) queue again?
26/0314 LB291 CR for Co-BF and Co-SR Error Recovery Sequence Kosuke Aio 19C
Hi TTT members,
Please let me know if you have any comments or feedback.
- Rev.5: Updated the Resolution text and the proposed spec text changes for CIDs #7382 and #5961 based on D1.5.
Changed the resolution status from “Revised” to “Rejected” for CIDs #5960, #7930 and #7935.
Editorial simplification of the proposed spec text for the other CIDs.
Best Regards,
Kosuke (SONY)
差出人: Aio, Kosuke (SEC) <Kosuke.Aio@xxxxxxxx>
送信: 2026 年 6 月 4 日 (木曜日) 8:24
宛先: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>; asterjadhi@xxxxxxxxx <asterjadhi@xxxxxxxxx>
件名: Re: [STDS-802-11-TGBN] Reminder: Planning towards July F2F
Hi Alfred,
Could you add it to JOINT (or MAC) queue again?
I 'll revise and upload it after D1.5 is released.
- 26/0314 LB291 CR for Co-BF and Co-SR Error Recovery Sequence Kosuke Aio 19C
Best Regards,
Kosuke (SONY)
差出人: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
送信: 2026 年 6 月 3 日 (水曜日) 2:05
宛先: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
件名: [STDS-802-11-TGBN] Reminder: Planning towards July F2F
Hello all, Please consider this as a gentle reminder for the deadline below: " Please make sure that you send a CR submission request no later than June 5th, 2026, anywhere on earth (AOE) If the submission is not uploaded when the CR submission
Hello all,
Please consider this as a gentle reminder for the deadline below:
"
Please make sure that you send a CR submission request no later than June 5th, 2026, anywhere on earth (AOE)
- If the submission is not uploaded when the CR submission request is sent then please provide an ETA as to when the CR is ready to be presented (making sure that the CR submission is uploaded at least 24 hours prior to that meeting slot)
"
Regards,
Alfred
On Fri, May 29, 2026 at 8:36 AM Alfred Asterjadhi <asterjadhi@xxxxxxxxx> wrote:
Hello all,
I am extending the announcement we made during the May 28th meeting and setting some deadlines so that we can plan for the next couple of months.
- Planning:
- Prioritization of CRs will continue as usual, except that temporarily expanded the time allocated to MAC normal CR queue to one hour
- Green tagging will continue as usual, except that-when possible, green tagging will be performed also on CRs from normal MAC queue.
- Joint meeting slots will continue to dedicate time for prioritized MAC CRs
- Call for prioritized submissions and submissions from top 40 assignees:
- There is limited number of CR submissions with ≥10 CIDs.
- Please submit CRs with ≥10 CIDs so that they can be prioritised
- There is a limited number of CR submissions from the top 20 assignees.
- Please submit CRs (preferably with ≥10 CIDs) and send requests/upload them as soon as possible (upload at least 24 hours in advance of the scheduled meeting slot).
- Alternatively provide ETAs as to when ready to present.
In summary, if you are planning a CR submission (the items below are highly recommended for MAC CR submissions, and advisory for PHY/Joint CR submission):
- Please make sure that you send a CR submission request no later than June 5th, 2026, anywhere on earth (AOE)
- If the submission is not uploaded when the CR submission request is sent then please provide an ETA as to when the CR is ready to be presented (making sure that the CR submission is uploaded at least 24 hours prior to that meeting slot)
- Please share the CR submissions with the TGbn group via the reflector as early as possible to seek early feedback from members.
Let me know if you have any questions.
Regards,
Alfred
--
Alfred Asterjadhi, PhD
IEEE802.11 TGbe/TGbn Chair,
Qualcomm Technologies Inc.
Cell #: +1 858 263 9445
Office #: +1 858 658 5302
--
Alfred Asterjadhi, PhD
IEEE802.11 TGbe/TGbn Chair,
Qualcomm Technologies Inc.
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
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
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
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
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
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
Benjamin A. Rolfe
Blind Creek Associates
Ben@xxxxxxxxxxxxxx
+1 408 332 0725 (Mobile)
Virus-free.www.avast.com
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
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
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
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
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
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
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