|
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
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
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.
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)
Hi Alfred,
Could you add it to JOINT (or MAC) queue again?
I 'll revise and upload it after D1.5 is released.
Best Regards,
Kosuke (SONY)
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
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
|