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

Re: [STDS-802-11-TGBN] Request to queue SPs on Flexible MBSSID Set

Hi All,

Thank you for feedback on SP1 today in the TGbn PM2 session.

As it was asked, I have uploaded a presentation (that has been discussed offline with members) discussing the use cases and solutions for the flexible MBSSID set feature. 
https://mentor.ieee.org/802.11/dcn/25/11-25-1382-00-00bn-flexible-mbssid-set.pptx 

Please review and let me know if you have any further comments or questions, especially if you voted NO. 
I would like to bring back the SP after more offline discussions with members.

Thanks,
Binita


On Mon, Jul 28, 2025 at 7:12 AM Binita Gupta <bingupta.ieee@xxxxxxxxx> wrote:

Hi All,

 

Please share any feedback on these SPs. 

I am providing some further clarification on these SPs below for better understanding.

 

SP1: enables an MBSSID set with a mix of EHT and UHR BSSIDs. This is extremely desired in the field when BSSIDs are being upgraded over a period of time, so that MBSSID sets do not need to be manually regrouped as the upgrades happen. This automates the upgrade operation and reduces MBSSID related operational issues in the field, greatly simplifying the overall operation.

  • The main change here is to not inherit UHR Operation and other UHR elements for (no-UHR) EHT nonTX BSSID by listing in the  Non-Inheritance element in the nontransmitted BSSID profile

 

 

SP2: enables UHR BSSIDs in an MBSSID set to have different enable/disable status and/or different parameters. This is very much desired to allow deployment flexibility for these UHR modes in terms of enable/disable and setting parameters per BSSID (per SSID) in the MBSSID set. Main changes include:

  • Carry a BSSID specific UHR Operation element in the nontransmitted BSSID profile if enablement status for UHR OMs is different for a nonTx BSSID  – i.e. UHR Operation element is not inherited in this case.
  • UHR capabilities are always the same across all BSSIDs, so the UHR Capabilities element is always inherited.
  • Carry UHR OM parameters in a new UHR Operating Modes element, instead of in the UHR Operation element. Main reasons to split parameters in a separate element are:
    • If carried in UHR Operation, we need to define a presence bitmap for these parameters since parameters will be included in Probe Response, (Re)Association Response but not included in Beacon. This complicates the UHR Operation element.
    • We also need to define a flexible and extensible format for carrying parameters for different OMs – using a subelement ID and length provides a good format to carry these parameters. UHR Operation element does not need to be modified to include such format.
    • Note that the UHR Operating Modes parameter element will not be carried in the Beacon, hence we can design in a more flexible/extensible way w/o concerns for beacon bloating.

 

 

Thanks,

Binita


On Thu, Jul 24, 2025 at 8:27 PM Binita Gupta <bingupta.ieee@xxxxxxxxx> wrote:
Hi Alfred,

Could you please queue following two SPs on Flexible MBSSID set for tomorrow's MAC agenda:

SP1:
Do you support the following for a multiple BSSID Set in UHR?

  • A multiple BSSID set in UHR can consist of a UHR BSSID as the transmitted BSSID and one or more non-UHR EHT BSSID as a nontransmitted BSSID. For a non-UHR EHT nontransmitted BSSID, the UHR Operation element, the UHR Capabilities element and/or other UHR defined elements that are carried for the UHR transmitted BSSID, are listed in the Non-Inheritance element in the corresponding nontransmitted BSSID profile.

 

SP2:

Do you support the following for UHR defined operating modes for a multiple BSSID set in UHR?

  • The support for each UHR defined operating mode will be the same across all BSSIDs in a multiple BSSID set and shall be signaled in the UHR Capabilities element.
    • The UHR Capabilities element shall not be included within a nontransmitted BSSID profile (i.e. it is always inherited).
  • The following UHR defined operating modes shall have the same enablement status across all BSSIDs in a multiple BSSID set: AP PUO, DBE, DPS (for mobile AP).
  • The following UHR defined operating modes can be independently enabled by a UHR AP in a multiple BSSID set: NPCA, DSO, P-EDCA, LLI. 
  • The enablement status for UHR operating modes is carried in the UHR Operation element in Beacon, Probe Response and (Re)Association Response.
    • For a nontransmitted UHR BSSID, if the enablement status is different for one or more UHR operating modes than the transmitted BSSID, then the corresponding nontransmitted BSSID profile carries a UHR Operation element with the enablement status of UHR operating modes for that nontransmitted BSSID.
    • For a nontransmitted UHR BSSID, if the enablement status is same for all UHR operating modes as the transmitted BSSID, then the UHR Operation element is inherited for that nontransmitted BSSID.
  • The following UHR defined operating modes shall have the same parameters across all BSSIDs in a multiple BSSID set: NPCA, DSO, AP PUO, DBE 
  • The following UHR defined operating modes can have per-BSS specific parameters in a multiple BSSID set: P-EDCA, DUO.
  • Parameters for UHR defined operating modes are carried in a UHR Operating Modes element in Probe Response and (Re)Association Response frames.
    • For a nontransmitted UHR BSSID, if the parameters are different for one or more UHR operating modes than the transmitted BSSID, then the corresponding nontransmitted BSSID profile carries a UHR Operating Modes element with the BSS specific parameters for that nontransmitted BSSID.
    • For a nontransmitted UHR BSSID, if the parameters are same for all UHR operating modes as the transmitted BSSID, then the UHR Operating Modes element is inherited for that nontransmitted BSSID. 
    • For DBE, DBE bandwidth (3 bits) is carried in the UHR Operation element.

 


Thanks,

Binita

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