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

Re: [STDS-802-11-TGBN] CoBF SPs Request

Hello Sherief,


Thanks for your response.

Please see my further inline comments.


Regards,

Arik


From: Sherief Helwa <shelwa@xxxxxxxxxxxxxxxx>
Sent: Tuesday, March 11, 2025 7:06:21 AM
To: Arik Klein; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: CoBF SPs Request
 

Hi Arik,

 

Thanks for your detailed comments. Please see my responses inline.

 

The heart of my comments is that simplicity is the key in the proposed sequence. And on a high level, what we suggested is a basic sequence and your suggested modifications can be further discussed.

 

Regards,

Sherief

 

From: Arik Klein <arik.klein@xxxxxxxxxx>
Sent: Monday, March 10, 2025 6:57 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx; Sherief Helwa <shelwa@xxxxxxxxxxxxxxxx>
Subject: Re: CoBF SPs Request

 

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

Hello Shereif,

 

Thanks for sharing the SPs (based on 11-25/0412 submission).

 

Here are my concerns regarding the SP1 and SP2 (which refer to the proposed CoBF transmission sequences):

  1. The sequences include a sequential ICF/ICR frame exchanges across different BSSs within SIFS (i.e. first the ICF/ICR frame exchange in the Sharing AP's BSS followed by the ICF/ICR frame exchange in the Shared AP's BSS), which assume that the sharing AP has correctly received the ICR from its solicited STAs and that the shared AP has correctly received the ICR from its solicited STAs.
    a. Since CoBF usually occurs in an interfered environment, we must consider the case where the above assumption might not consistently happen.

[SH] True. And CoBF is proposed to organize transmissions within this high-interference environment using the initial handshake between the 2 APs.

b. In that "imperfect" case, the expected outcome of the sequence is unclear since no single AP runs the entire sequence and controls (or is accountable for) each of its "components", for instance:
 - What the shared AP does if the sharing AP has not correctly received the ICR from the solicited STA (how can the shared AP "know" if the ICR was correctly received by the sharing AP?)?
 - Would the sharing AP trigger the CoBF DL PPDU transmission if the ICR was not correctly received by the shared AP?
Since the described sequence should work in all practical cases (not only the "success-oriented" attitude), i.e., be more stable - you need to add "control points" for the sharing AP (especially in the frame exchanges taking place in the OBSS) so it has the full accountability on correctly running the entire sequence (see proposal below).

[SH] The failed ICR scenario won’t be solved by adding MU-RTS TXS/CTS/TXOP Return frames. Additionally, these are C-TDMA frame exchanges which means that in order to do CoBF, you’ll have to do C-TDMA within the CoBF sequence. So, for now, let’s keep the sequence as simple as possible.


[AK] My suggested solution does solve the raised problem of ICR frame's reception failure as follows:
1. The sharing AP initiates the ICf/ICR with its associated STA. In case the ICR is not correctly received by the sharing AP, it should not proceed to the next step of sending the MU-RTS TXS (and obviously will not initiate the DL Co-BF PPDU).
2. Once allocated a time, the shared AP will initiate the ICF/ICR with its associated STAs. In case the ICR is not correctly received by the shared AP, it may repeat the ICF/ICR if the allocated time suffices. Anyway, it will report its success/failure in the TXOP Report frame so the sharing AP can decide whether to initiate the DL Co-BF PPDU or not.   

I may agree that this is not the only solution for this problem, but given the Co-BF sequence you propose, it is the most adequate solution for the situation in concern (if you do have an alternative solution - please specify it). Your wish "to keep the sequence as simple as possible" is quite understood, but it does not solve the raised problem, so neglecting the raised concern (i.e. keeping the SP as is) results in an unstable sequence which leads to unexpected/undefined behavior.



BTW, the same comment applies for the MU-BAR/BACK frame exchange illustrated in SP2.

  1. When an AP or STA obtains a TXOP - it is the only entity that can initiate a transmission within this TXOP (basic fairness of the backoff mechanism for EDCA) - according to the rules in 802.11REVme D7.0 section 10.23.2.4.

[SH] This applies to all MAP coordination schemes which, by definition, involve multiple APs. So this is the expectation for all these schemes.

[AK] as long as you keep the rule of being a TXOP holder as the only entity that can initiate transmission in the TXOP you obtain - you still keep the fairness issue.
This is kept in the Co-TDMA proposed sequences in TGbn D0.1, but unfortunately, it does not occur in the Co-BF transmission proposed in SP1 and SP2, and hence I've suggested a way to solve it.

However, in the suggested sequences (SP1 and SP2), there are several transmissions initiated by the shared AP (i.e. the AP that has not obtained the TXOP) without being allocated any time for this by the sharing AP (which has obtained the TXOP).

For instance: 

 - ICF-ICR  exchange before the DL Co-BF PPDU transmission that is done by the Shared AP with its associated STAs.

 - MU-BAR - Multi-STA BACK exchange after the DL Co-BF PPDU transmission that is done by the Shared AP with its associated STAs.

 

Therefore, I suggest to modify the sequences in SP1 and SP2 as depicted below. This will address both the concerns raised above:

For SP1, the following modification is suggested:

For SP2, the following modification is suggested:

 

 

Any comments are appreciated.

 

Regards,

Arik

From: Sherief Helwa <00002dded7ae4daf-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, March 10, 2025 15:15
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] CoBF SPs Request

 

Hi Alfred,

 

Would you please add the following CoBF SPs to the MAC queue?

 

  • Do you agree to use the following CoBF transmission sequence to support STAs requiring ICF/ICR before data frame exchanges?
    • The frame sequence consists of:
      • A CoBF Invite/CoBF Response frame exchange between the sharing and shared APs.
      • Follows ICF/ICR frame exchanges between the APs and their associated STAs happening sequentially across the two APs; sharing AP then shared AP.
        • The presence of the ICF/ICR frame exchange from each AP is conditional on the CoBF PPDU being addressed to one or more STAs.
        • The presence of the ICF/ICR frame exchange from each AP is indicated in the CoBF Invite/Response frames.
        • ICF1-ICR1 are exchanged between the sharing AP and its STAs
        • ICF2-ICR2 are exchanged between the shared AP and its STAs
      • Finally, a CoBF Trigger/Sync frame preceding the data PPDUs sent by the two APs simultaneously.
      • Frame sequence for Ack information polling is TBD.
      • Whether the CoBF-invite and ICF1 can be merged and/or CoBF-response and ICF2 can be merged is TBD.

 

 

 

  • Do you agree to use the following sequence for acknowledgement information polling from STAs scheduled in a CoBF transmission sequence
    • MU-BAR/BA frame exchanges are used by each AP separately, i.e., sequentially.

NOTE1: The first MU-BAR frame (transmitted by the sharing AP) can be embedded in the preceding DL PPDU as in baseline.

NOTE2: The frame sequence for eliciting simultaneous ACKs from clients of both sharing and shared APs if agreed in PHY is TBD.

 

 

 

 

  • Do you agree that:

–         For DPS non-AP STA(s) scheduled with CoBF in high capability mode, the same switch-back behavior as for eMLSR with extended time-out period is used.

 

 

 

  • Do you support that any CoBF sounding sequence that includes Cross-BSS CSI collection shall be initiated by a two-way handshake between the two APs participating in the sequence

–         The two-way handshake exchange consists of a Sounding Invite frame and a Sounding Response frame.

–         The Sounding Invite/Response frame exchange is used to:

•       Confirm the availability of both APs for CSI collection.

•       TBD for indication whether each AP will include ICF/ICR exchanges with its client or not.

•       Further information to be exchanged is TBD.

 

 

Regards,

Sherief

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