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

Re: [STDS-802-11-TGBN] Reminder: PHY Ad-hoc Thursday AM1

Hi Alfred,

 

Unfortunately, the SPs I queued below were put last in the PHY ad-hoc AM1 session, so they didn’t make it and as per your guidance, I am kindly requesting to allocate some time during the joint sessions for the SPs and possibly for the PDT I queued as well.

 

An updated list of SPs is as follows (updated order):

 

SP1:

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 STA.
        • 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 frame preceding the data PPDUs sent by the two APs simultaneously.
      • Frame sequence for Ack information polling is TBD.
    • Whether the CBF-invite and ICF1 can be merged and CBF-response and ICF2 can be merged as below is TBD.

 

SP2:

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 replaced with a basic trigger that is aggregated with the 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.

A computer screen shot of a black screen AI-generated content may be incorrect.

 

SP3:

If an eMLSR non-AP MLD that receives an ICF addressed to one of its affiliated STAs during CoBF sequences and if the affiliated STA responds with an ICR, then the eMLSR non-AP MLD shall follow the eMLSR procedure defined in 35.3.17, except that the STA shall use an extended time-out period prior to switching back upon inactivity:

    • The duration of the extended time-out period shall be sufficient to cover any inactivity period within the COBF sequence, e.g. (but not limited to), from the end of the ICR to the beginning of the data PPDU, or from the DL PPDU until the beginning of the MU-BAR frame from the shared AP for STAs associated with the shared AP
    • The duration of the extended timeout period(s) is explicitly indicated to the STA in the ICF frame sent by its associated AP.
      • Whether there is more than one extended timeout period is TBD
    • The signaling and derivation of these timeout periods to the STA are TBD.
    • Once the eMLSR STA(s) switch back to listen mode, they start using the default time-out period (aSIFSTime + aSlotTime + aRxPHYStartDelay) in future TXOPs unless otherwise indicated in the ICF.
    • This is applicable to CoBF transmission sequence

 

SP4:

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

    • The RTS frame shall not be used as an ICF for DPS in the CoBF Transmission sequence even when the DPS STA does not have any DPS padding required

NOTE: The RTS frame cannot be modified to include the extended timeout period usage and the extended timeout period duration indications.

 

SP5:

Do you agree that an AP shall use the BSRP GI3 Trigger frame variant for the Sounding Invite frame

    • The Sounding Response frame shall be M-BA
    • TBD whether there’s another frame variant allowed for the Sounding Invite/Response frame

 

SP6:

Do you agree that an AP shall use the BSRP GI3 Trigger frame variant for the CoBF Invite frame

    • The CoBF Response frame shall be M-BA
    • TBD whether there’s another frame variant allowed for the CoBF Invite/Response frame

 

SP7:

Do you support that if a CoBF sounding sequence within a TxOP includes Cross-BSS and In-BSS sounding, then the Cross-BSS sounding portion shall come first?

    • If In-BSS sounding fails, it can be redone using legacy sounding without any involvement of the other AP.

 

SP8:

Do you agree that an AP MLD that receives an ICR from a STA affiliated with an EMLSR non-AP MLD during CBF data frame exchange does not attempt to transmit to the eMLSR non-AP MLD on another link during the extended time-out periods, per baseline behavior. 

 

SP9:

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

 

 

From: Sherief Helwa
Sent: Wednesday, May 14, 2025 10:27 AM
To: asterjadhi@xxxxxxxxx; dongguk.lim@xxxxxxx; Sigurd Schelstraete <sschelstraete@xxxxxxxxxxxxx>; tianyu@xxxxxxxxx
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx; George Cherian <gcherian@xxxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-11-TGBN] Reminder: PHY Ad-hoc Thursday AM1

 

Hi Alfred and all,

 

Can we allocate some time to run the CoBF SPs that I queued earlier (Some of them were queued almost a month ago)? SPs listed below for reference.

 

Also, can we allocate some time for the following PDT? It’s also queued already.

  • 25/942 MAC-PDT-37_8_2_1-CoBF

 

List of SPs:

 

SP1:

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 STA.
        • 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 frame preceding the data PPDUs sent by the two APs simultaneously.
      • Frame sequence for Ack information polling is TBD.
    • Whether the CBF-invite and ICF1 can be merged and CBF-response and ICF2 can be merged as below is TBD.

 

SP2:

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.

A computer screen shot of a black screen AI-generated content may be incorrect.

 

SP3:

If an eMLSR non-AP MLD that receives an ICF addressed to one of its affiliated STAs during CoBF sequences and if the affiliated STA responds with an ICR, then the eMLSR non-AP MLD shall follow the eMLSR procedure defined in 35.3.17, except that the STA shall use an extended time-out period prior to switching back upon inactivity:

    • The duration of the extended time-out period shall be sufficient to cover any inactivity period within the COBF sequence, e.g. (but not limited to), from the end of the ICR to the beginning of the data PPDU, or from the DL PPDU until the beginning of the MU-BAR frame from the shared AP for STAs associated with the shared AP
    • The duration of the extended timeout period(s) is explicitly indicated to the STA in the ICF frame sent by its associated AP.
      • Whether there is more than one extended timeout period is TBD
    • The signaling and derivation of these timeout periods to the STA are TBD.
    • Once the eMLSR STA(s) switch back to listen mode, they start using the default time-out period (aSIFSTime + aSlotTime + aRxPHYStartDelay) in future TXOPs unless otherwise indicated in the ICF.
    • This is applicable to CoBF transmission sequence

 

SP4:

Do you agree that an AP MLD that receives an ICR from a STA affiliated with an EMLSR non-AP MLD during CBF data frame exchange does not attempt to transmit to the eMLSR non-AP MLD on another link during the extended time-out periods, per baseline behavior. 

 

SP5:

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.

 

SP6:

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

    • The RTS frame shall not be used as an ICF for DPS in the CoBF Transmission sequence even when the DPS STA does not have any DPS padding required

NOTE: The RTS frame cannot be modified to include the extended timeout period usage and the extended timeout period duration indications.

 

SP7:

Do you agree that an AP shall use the BSRP GI3 Trigger frame variant for the Sounding Invite frame

    • The Sounding Response frame shall be M-BA
    • TBD whether there’s another frame variant allowed for the Sounding Invite/Response frame

 

SP8:

Do you agree that an AP shall use the BSRP GI3 Trigger frame variant for the CoBF Invite frame

    • The CoBF Response frame shall be M-BA
    • TBD whether there’s another frame variant allowed for the CoBF Invite/Response frame

 

SP9:

Do you support that if a CoBF sounding sequence within a TxOP includes Cross-BSS and In-BSS sounding, then the Cross-BSS sounding portion shall come first?

    • If In-BSS sounding fails, it can be redone using legacy sounding without any involvement of the other AP.

 

 

Regards,

Sherief

 

From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Sent: Wednesday, May 14, 2025 6:53 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] Reminder: PHY Ad-hoc Thursday AM1

 

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

Hello all,

 

A gentler reminder that PHY ad-hoc has scheduled some discussions on CBF/CSR tomorrow, so if you like to participate in those discussions please attend the PHY ad-hoc meeting slot of Thursday AM1. I have allocated submissions from PHY and Joint queues so far.

 

Regards,

 

Alfred 

 

--

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