Hi All,
I presented CR doc 11-23/458 (which resolves 17 remaining CIDs) during last week’s IEEE meetings. During offline discussions, I found out that some of the members who didn’t support the SP did not fully understand the motivation behind the changes. I have already initiated offline discussions with some members but also wanted to reach out to a wider audience to help everyone understand the purpose of the document.
- The document is not proposing a new feature. It is simply providing the next-level details for an existing feature in D3.0 as a resolution to several comments.
- D3.0 already requires that TxBSSID provide information of the rTWT schedules for each nonTxBSSID (including co-hosted bssid case).
- The Restricted TWT Schedule Info (RTSI) subfield is set to 3 for such cases.
- The document provides signaling details on how the (above) information is advertised
- Specifically, the TWT IE outside the Multiple BSSID element in the TxBSSID’s Beacon or Probe Response frame carries rTWT schedules for itself and that belonging to all the nonTxBSSIDs in the set
- the information is advertised even if the nonTxBSSID profile is not carried in the Multiple BSSID element (i.e., the frame carries partial list of profiles).
- Each nonTxBSSID carries TWT IE containing rTWT parameter set(s) of only its own BSS
- Since the elements of the TxBSSID are common to all associated STAs (of any BSSID in the set), any STA associated with any AP will be able to determine and respect the rTWT of all BSSIDs in the set.
- This approach is most efficient and effective.
- The document provides similar details for co-hosted BSSID set and also provides details on the behavior at a non-AP side associated with any BSSID.
- Again, this is consistent with what is already defined in D3.0 and specifies next-level details missing in D3.0
- Another aspect that the document clarifies is the setting of bTWT ID field for an rTWT parameter set corresponding to another AP
- Since 11ax non-AP STAs view rTWT parameter set as a bTWT parameter set (and don’t understand the RTSI field), the transmitting AP needs a mechanism to differentiate the rTWT parameter set of another AP and those meant for its own BSS
- By using value 31, the AP can reject any TWT setup request directed towards the rTWT schedule matching another AP.
- Without the above rule, APs in the multiple BSSID set will need to share bTWT ID space which will greatly limit the number of bTWT IDs available per AP.
- The document also adds missing rules related to critical updates procedure.
Hope the above explanation makes sense. I plan to re-run the SP during an upcoming telco. Would you please reach out to me if you have any questions or need further explanation?
Attached is an updated document r9 (available on server as well).
Regards,
Chunyu
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1