Re: [STDS-802-11-TGBN] 回复: Motion request

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

Happy to Second the motions.

Please add supporting docs. 24/1883, 24/1884 to all the motions listed below.

Thanks,

Giovanni

From: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Sent: Wednesday, March 12, 2025 6:10 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] 回复: Motion request

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

Hi Alfred,

Could you please add the following motion into the motion list:

Move to add the following to the 11bn SFD

After the roaming preparation request/response exchange, there is an indicated timeout

If there is no successful transmission of the roaming execution request frame from the non-AP MLD within the indicated timeout, then the target AP MLD may delete all preparation information related to the non-AP MLD

NOTE - This includes security context, i.e., new derived TK if new TK is derived

if the roaming preparation request for a target AP MLD is accepted in the roaming preparation response, and the non-AP MLD sends a following roaming execution request for the target AP MLD received within the indicated timeout, then the roaming execution request shall be accepted in the roaming execution response
TBD on indication of the timeout

After the latest roaming preparation request/response exchange, the setup links with the target AP MLD is not modified until after the roaming execution request/response exchange is finished.

Supporting List: [24/1874r1]

SP results: no objection

Move to add the following to the 11bn SFD

- There is only one target AP MLD indicated in the roaming preparation request frame from a non-AP MLD

Supporting List: [24/1874r1]

SP results: no objection

Move to add the following to the 11bn SFD

The roaming preparation request frame includes Listen Interval field of the non-AP MLD for the target AP MLD
The roaming execution request frame includes Listen Interval field of the non-AP MLD for the target AP MLD if there is no roaming preparation request/response exchange beforehand
After the roaming execution request/response exchange with the current AP MLD, the non-AP MLD is by default in power save mode for all the setup links with the target AP MLD
After the roaming execution request/response exchange with the current AP MLD, during the TBD period to receive DL data from the current AP MLD, the non-AP MLD is not required to listen to any Beacon frames of the APs affiliated with the target AP MLD

Supporting List: [24/1874r1]

SP results: no objection

Move to add the following to the 11bn SFD

- After the roaming execution request/response exchange with the current AP MLD, the TBD period to receive DL data from the current AP MLD ends after the indicated timeout in the roaming execution response

Supporting List: [24/1874r1]

SP results: no objection

Best,

Po-Kai

From: liuchenchen <0000185315b29db3-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, March 12, 2025 5:57 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] 答复: [STDS-802-11-TGBN] 回复: Motion request

Hi Alfred:

Could you please add the following motion into the motion list:

l Move to add the following to the 11bn SFD

4xLTF sequence for DRU of 60MHz DBW is defined as follows：

=[0 1 1 -1 -1 -1 1 0 1 1 -1 -1 1 -1 0 -1 1 -1 -1 1 -1 0 1 -1 1 -1 -1 1 0 1 -1 -1 -1 -1 1 0 -1 -1 1 -1 1 1 1 1 1 -1 -1 1 -1 1 1 -1 -1 1 -1 -1 1 1 -1 1 1 1 1 1 -1 -1 -1 -1 1 -1 1 -1 -1 -1 1 1 -1 1 -1 1 1 1 1 1 -1 1 1 1 1 -1 1 -1 1 -1 1 -1 1 1 1 -1 -1 -1 1 -1 1 -1 1 1 -1 -1 -1 -1 -1 -1 1 1 -1 -1 1 1 1 -1 1 1 -1 -1 1 1 1 -1 1 1 -1 1 1 -1 1 1 -1 1 -1 1 -1 -1 1 -1 -1 -1 -1 1 1 1 1 1 1 -1 -1 -1 -1 1 -1 1 1 1 -1 1 -1 1 -1 -1 1 1 -1 -1 1 -1 -1 1 -1 1 -1 -1 1 -1 1 1 1 1 -1 1 1 -1 -1 -1 -1 1 -1 -1 1 1 -1 1 1 1 -1 -1 1 1 -1 -1 1 1 1 -1 1 1 -1 1 1 -1 -1 1 -1 1 -1 1 -1 1 1 1 -1 1 1 -1 -1 -1 1 1 1 -1 -1 1 -1 -1 1 1 1 -1 1 -1 1 -1 1 -1 -1 1 -1 -1 -1 -1 -1 1 1 -1 -1 1 -1 1 -1 -1 1 -1 1 1 -1 -1 1 1 1 1 -1 -1 1 1 -1 -1 -1 -1 -1 -1 -1 1 -1 -1 -1 -1 -1 -1 1 1 -1 -1 -1 -1 1 1 1 1 1 1 -1 -1 1 1 1 1 1 -1 -1 -1 -1 -1 1 1 -1 1 -1 -1 1 1 -1 -1 1 1 -1 1 1 1 1 1 1 1 1 -1 -1 1 1 1 -1 1 -1 1 1 1 -1 -1 1 -1 1 -1 1 -1 -1 1 -1 -1 -1 -1 1 -1 -1 -1 1 1 1 -1 1 1 1 -1 -1 1 -1 1 -1 1 1 1 -1 -1 -1 1 -1 -1 -1 -1 1 -1 1 1 -1 1 1 -1 1 -1 1 -1 -1 -1 -1 -1 -1 1 -1 -1 1 -1 1 1 -1 1 1 -1 1 1 1 1 -1 1 1 1 -1 1 -1 -1 -1 -1 1 -1 1 1 -1 1 1 -1 -1 -1 1 -1 1 -1 1 -1 1 1 -1 1 -1 -1 -1 1 1 1 -1 -1 -1 1 1 1 -1 -1 1 1 1 -1 1 1 1 1 1 -1 1 0 -1 1 1 1 -1 -1 0 1 1 1 1 -1 1 0 0 0 0 0 0 0 0 1 1 -1 -1 1 1 0 1 1 1 -1 1 1 0 1 -1 -1 -1 1 1 1 -1 -1 -1 -1 1 -1 -1 1 1 1 1 1 -1 1 1 -1 -1 1 -1 1 1 1 1 1 1 1 -1 -1 1 1 1 -1 -1 -1 -1 -1 1 1 -1 1 -1 -1 1 1 1 1 -1 -1 -1 1 1 1 -1 -1 -1 -1 -1 1 1 -1 1 -1 1 1 1 -1 1 1 -1 -1 1 -1 1 1 1 1 -1 -1 1 -1 -1 1 1 1 1 1 1 1 -1 1 1 1 -1 1 -1 1 1 -1 -1 -1 1 -1 1 1 1 -1 1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 1 1 1 -1 -1 -1 -1 1 1 -1 1 -1 1 -1 1 1 1 -1 1 -1 1 1 -1 1 -1 1 -1 1 1 -1 -1 -1 -1 -1 -1 -1 1 -1 -1 -1 1 -1 1 1 1 1 1 -1 -1 -1 1 -1 1 1 -1 -1 -1 1 -1 1 -1 -1 -1 1 1 1 1 -1 1 1 -1 0 1 -1 -1 -1 1 1 0 -1 -1 -1 1 1 -1 0 -1 1 1 1 1 -1 0 -1 -1 -1 -1 -1 -1 0 1 1 1 -1 -1 1 0 0 0 0 0]

Supporting List: [25/0394r0]

SP results: no objection

Thanks

Best regards

Chenchen Liu

发件人: Yujian (Ross Yu) <00001792b51ef4ea-dmarc-request@xxxxxxxxxxxxxxxxx>
发送时间: 2025年3月12日 20:27
收件人: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGBN] 答复: [STDS-802-11-TGBN] 回复: Motion request

Hi Alfred,

Please add the following motion into the motion list:

•Move to make the following changes to the 802.11bn SFD:

–Mandatory support MCSs of QPSK with code rate 2/3; 16QAM with code rate 2/3; 16QAM with code rate 5/6; 256QAM with code rate 2/3.

•Support for 256QAM with code rate 2/3 for 20MHz only devices is ~~TBD~~ optional.

–[Motion #216, [264] and [274, 275]]

regards

Ross Jian Yu

Huawei

发件人: Liangxiao Xin <xlx20190808@xxxxxxxxx>
发送时间: 2025年3月12日 11:05
收件人: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBN] 回复: Motion request

Hi Alfred,

May I update the motion text as shown below? Compared with the passed SP, we add a third note.

11bn defines a mechanism for non-AP STA to provide the delay report of LL buffered data to its AP.

o note: this feature is optional.

o note: the container carrying such information is TBD.

o note: the delay report is the expiration time of the TBD MPDU/MSDU. The _expression_ of the delay report is TBD.

Supporting List: [24/1692, 23/0885r0, 24/264r1, 23/45r1, 24/863r0]

The passed SP is

SP1: Liangxiao Xin – Low Latency

Do you support to include the following in SFD?

· 11bn defines a mechanism for non-AP STA to provide the delay report of LL buffered data to its AP.

o note: this feature is optional.

o note: the container carrying such information is TBD.

Supporting List: [24/1692, 23/0885r0, 24/264r1]

Result: 65%Y, 12%N, 23%A (101 votes).

Thank you!

Regards,

Liangxiao

On Sat, Mar 8, 2025 at 9:59 PM Liangxiao Xin <xlx20190808@xxxxxxxxx> wrote:

Hi Alfred,

Could you please add the following motion to the agenda? Thank you!

SP1: Liangxiao Xin – Low Latency

Do you support to include the following in SFD?

·       11bn defines a mechanism for non-AP STA to provide the delay report of LL buffered data to its AP.

o   note: this feature is optional.

o   note: the container carrying such information is TBD.

Supporting List: [24/1692, 23/0885r0, 24/264r1]

Result: 65%Y, 12%N, 23%A (101 votes).

Regards,

Liangxiao

On Tue, Feb 25, 2025 at 11:59 AM liuchenchen <0000185315b29db3-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

Hi Alfred,

Can you please add the following two motions on DRU for 60MHz DBW to the TGbn agenda for voting?

Do you support that the Data and pilot subcarrier indices for DRUs in an 60 MHz DBW are defined in following table:

Data and pilot subcarrier indices for Distributed-tone RUs (DRU) in a 60 MHz UHR TB PPDU

DRU type

DRU index and subcarrier range

52-tone DRU
i=1:12

DRU1

[-499:14:-23, 5:14:229]

DRU2

[-492:14:-16, 12:14:236]

DRU3

[-496:14:-20, 8:14:232]

DRU4

[-489:14:-13, 15:14:239]

DRU5

[-498:14:-22, 6:14:230]

DRU6

[-491:14:-15, 13:14:237]

DRU7

[-495:14:-19, 9:14:233]

DRU8

[-488:14:-12, 16:14:240]

DRU9

[-497:14:-21, 7:14:231]

DRU10

[-490:14:-14, 14:14:238]

DRU11

[-494:14:-18, 10:14:234]

DRU12

[-487:14:-11, 17:14:241]

106-tone DRU
i=1:6

DRU1
[-499:7:-9, 5:7:243]

DRU2
[-496:7:-6, 8:7:246]

DRU3
[-498:7:-8, 6:7:244]

DRU4
[-495:7:-5, 9:7:247]

DRU5
[-497:7:-7, 7:7:245]

DRU6
[-494:7:-4, 10:7:248]

242-tone DRU
i=1:3

DRU1

[-499:7:-9, 5:7:243, -496:7:-6, 8:7:246, -458:21:-38, 25:21:193]

DRU2

[-498:7:-8, 6:7:244, -495:7:-5, 9:7:247, -451:21:-31, 32:21:200]

DRU3

[-497:7:-7, 7:7:245, -494:7:-4,10:7:248, -444:21:-24, 39:21:207]

Do you support that the Pilot subcarrier indices for DRUs in an 60 MHz DBW are defined in following table?

Pilot indices for DRU transmission over 60MHz DBW

DRU size

Pilot indices

52-tone DRU
i=1:12

{-373 -219 -65 159}, {-450 -296 -142   82}, {-412 -258 -104 120}, {-335 -181 -27 197},

{-386 -232 -78 146}, {-463 -309 -155   69}, {-425 -271 -117 107}, {-348 -194 -40 184},

{-399 -245 -91 133}, {-476 -322 -168   56}, {-438 -284 -130   94}, {-361 -207 -53 171},

106-tone DRU
i=1:6

{-450 -296 -142   82}, {-335 -181 -27 197}, {-463 -309 -155   69}, {-348 -194 -40 184},

{-476 -322 -168   56}, {-361 -207 -53 171},

242-tone DRU
i=1:3

{-450 -335 -296 -181 -142 -27   82 197}, {-463 -348 -309 -194 -155 -40   69 184},

{-476 -361 -322 -207 -168 -53   56 171},

Supporting List: [25/0154r0]

SP result in PHY ad-hoc: unanimous.

Best regards

Chenchen Liu

发件人: Das, Dibakar <dibakar.das@xxxxxxxxx>
发送时间: 2025年2月22日 2:00
收件人: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBN] Motion request

Hi Alfred,

Can you please add the following motion on CTDMA/TXOP sharing to the TGbn agenda for voting?

Do you agree that:

The maximum time allocated by a sharing AP in a TXOP to all shared AP for CTDMA is not larger than the TXOP limit it advertised for the minimum between AC_VI TxOP limit and the TxOP Limit of the AC it obtains the TxOP with to its associated STAs.

If TXOP limit for an AC is 0, there is no CTDMA in a TXOP obtained using that AC.

The sharing AP shall use at least a TBD portion of the obtained TXOP for data communication with its own associated STAs.

Note: similar consideration will apply for TXS mode 2

Supporting List: [24/0093]

SP result in MAC ad-hoc: unanimous.

Regards,

Dibakar

From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Sent: Wednesday, January 15, 2025 9:48 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] Motion request

Hi Alfred,

Could you please queue the following motion on CTDMA/TXOP sharing to the TGbn agenda for voting?:

Do you agree to define a mechanism as part of the procedure of time sharing during a TXOP (e.g. C-TDMA, TXS, …) to support fairness to neighboring STAs (APs and non-APs)?

Exact mechanism is TBD
Supporting documents: 11-24-93, 11-25-86r0

SP Result: (don’t recall) think it was 144Y/27N

Regards,

Dibakar

From: Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx>
Sent: Wednesday, January 15, 2025 12:34 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] Motion request

Dear Alfred,

Could you please queue the following motion on P EDCA to the TGbn agenda for voting?:

[M1] Do you agree to define HIP EDCA in UHR where a STA with Low Latency traffic may be allowed, based on TBD conditions, to send a Defer Signal (it is TBD whether CTS or RTS is used) to start a protected short contention for pending LL data

Conditions to be allowed to send a Defer Signal is TBD
STA in HiP EDCA always use RTS/CTS as initial frame exchange and retry.
Duration of protected short contention is TBD.
Access parameters (AIFSN, CW and the expansion rules) used to transmit the Defer Signal are TBD. The retry count where the Defer Signal is allowed to be sent is TBD
Contention parameters for the protected short contention are TBD. The STAs that transmitted a Defer Signal but did not win the protected short contention will initiate a new retry.
Low Latency traffic is treated as AC_VO traffic. Other cases are TBD.
The solution would provide control on the degree of collisions that may occur while using it and, allows for autonomous randomness or/and controlled by the AP
No new mandatory synchronization requirement on STA side
HIP EDCA is used by the STAs in a BSS only when this feature is enabled by the AP

Supporting doc: 24/1144r1

SP Result: 150Y, 14N, 70A

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

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

--

Liangxiao Xin

OPPO

Liangxiao Xin

OPPO

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