Re: [STDS-802-11-TGBN] (2) [STDS-802-11-TGBN] SP request (MAC) for MAPC

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

Hi Giovanni and Jay,

Thanks a lot Giovanni for taking our comments into account for the MAPC PDT.

We are aware that it may not be possible to incorporate everything before D1.0, but as the MAPC PoC, we would appreciate it if you could explore ways to accommodate our comments effectively at this stage.

@Jay,

Hi Jay, thanks for sharing your thoughts. I agree with many of your points, especially the point that there is ample room for future modifications and the fact that Giovanni and the MAPC TTTs have dedicated significant effort and time to the refinement and development of the MAPC PDT.

The proposals related to MAPC Info, Last MAPC Request fields, and the extension of MAPC Operation Type, in my opinion, are matters of field optimization.

However, our view on the addition of the Co-CR context into the MAPC PDT differs from yours.

MAPC PDT and P2P PDT have been discussed separately, but we believe that the Co-CR (Coordinated-Channel Recommendation) feature in the MAPC PDT should be addressed within the MAPC PDT along with the other MAPC schemes.

As you know, discussions on the P2P PDT itself in the IEEE 802.11bn happened quite recently.

Now that the content of the P2P PDT has been disclosed and discussed officially in May Interim meeting, we can see that the Co-CR aspect within the P2P PDT falls under the domain of AP coordination features, which has been developed as the MAPC.

Accordingly, we believe that the MAPC PDT should allocate capability and enablement bits and need to provide a container such as Co-CR profile to allow the detailed aspects of Co-CR to develop in the future within the MAPC domain.

In addition, we have the following Multi-AP motions:

[Motion #50]

• 11bn defines a common framework of a Multi-AP Coordination for various coordination schemes.

• Note - Coordination schemes such as (but not limited to): Co-SR (TXOP-based with power control), Co-BF, Co-TDMA, Co-RTWT, etc.

[Motion #184, [1]]

• 11bn enhances existing mechanism(s) to improve latency for a non-AP STA communication with another non-AP STA on the base channel and off-channel, respectively, by

• enhancing mechanism(s) to allow an AP to share a TXOP with multiple peer-to-peer (P2P) non-AP STAs(s)

• enhancing the baseline Channel Usage procedure to provide better recommendation on channel selection for P2P by enabling coordination between APs that do not belong to the same ESS so that the channels recommended for P2P operation sent by those APs are the same.

Note 1: the coordinated channel recommendation is an optional feature. Also, the responding AP has an option to reject the request for such coordination.

Note 2:

- Base channel is the channel where the AP associated with the non-AP STA is operating.

- A channel outside its associated AP’s operating BW is an off-channel for the non-AP STA.

We believe that MAPC should continue to be broadly defined for technologies that require coordination between APs.

In other words, it is necessary to explicitly specify in the specification that MAPC allocates bits to each scheme requiring coordination between APs, to avoid conflicts and ensure consistency.

At a minimum, allocating bits for Co-CR Supported and Co-CR Agreement Establishment Enabled in the MAPC Capabilities field and MAPC Parameter field, respectively, as well as assigning a Co-CR profile in the MAPC Scheme Type field, does not overturn the work done by Giovanni and MAPC TTTs over several months, nor does it change any agreed-upon points.

Rather, our suggestion is simply about incorporating the Co-CR context to achieve technical alignment while respecting the MAPC content that the MAPC TTTs have designed so far.

This is a matter of allocating reserved bits, and if such simple modifications are not accepted, it may not the issue related to what you mentioned about D1.0 not being perfect and that additions can be made even after D1.0.

If we were requesting a significant change, it might make sense, but rejecting these simple additions or modifications with the justification that they can be worked on after D1.0 is not fair.

Lastly, while it is acknowledged that these modifications and additions can be made after D1.0, no one can guarantee that they will indeed be implemented afterward.

Reflecting these changes at the current stage would help enhance technical consistency and efficiency.

This would facilitate smoother integration of Co-CR into the MAPC, and we expect it to have a positive impact on future P2P work as well.

Regards,

Jonghoe KOO

Communications Standards Research Team, Samsung Research

Samsung Electronics

From: Giovanni Chisci <00002b657bbbbed7-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Saturday, May 31, 2025 6:01 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] (2) [STDS-802-11-TGBN] SP request (MAC) for MAPC (25/0599) and Co-RTWT (25/0600) PDTs

Thank you all for the comments and suggestions,

I am taking the new suggestions into account for the next step. More time is needed to review the latest comments and determine how to accommodate. In the meantime I’ll request a deferral of the SP currently scheduled by the Chair for Monday.

Thanks,

Giovanni

From: Rubayet Shafin <r.shafin@xxxxxxxxxxx>
Sent: Thursday, May 29, 2025 10:43 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] (2) [STDS-802-11-TGBN] SP request (MAC) for MAPC (25/0599) and Co-RTWT (25/0600) PDTs

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

Hi Jay,

What “new proposal” are you referring to?

Best

Rubayet

From: Jay Yang <yang.zhijie@xxxxxxxxxx>
Sent: Thursday, May 29, 2025 9:10 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] (2) [STDS-802-11-TGBN] SP request (MAC) for MAPC (25/0599) and Co-RTWT (25/0600) PDTs

Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Jonghoe,

General speaking, we should live with some flaws and approve the basic version in 802.11bn draft1.0, and then we could continue to improve it in next round. This is a general procedure in 802.11 standard developmet.

We can't expect all the stuff 100% perfect in one document.

I strong believe Giovanni spent quiet a lot of efforts to impove his PDT based on all kinds of comments from so many members in the past several months, and most of members agree on this. I'm afraid your new proposal will cause a lot of draw back of such job.

Thanks

Best Regards

Jay Yang (杨志杰)

Original

From: JonghoeKoo <jh89.koo@xxxxxxxxxxx>

To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>;

Date: 2025年05月30日 00:11

Subject: Re: [STDS-802-11-TGBN] (2) [STDS-802-11-TGBN] SP request (MAC) for MAPC (25/0599) and Co-RTWT (25/0600) PDTs

Hi Giovanni,

Thank you again for preparing the PDT on the MAPC general framework. We appreciate your hard work.

I would like to keep continuing the discussion on the MAPC PDT.

It would be appreciated if you review the comments below on the MAPC PDT:

1. The Co-CR feature, also defined as a multi-AP coordination scheme, will be using the MAPC general framework proposed by this PDT. However, the current MAPC PDT does not accommodate the necessary support/enablement fields corresponding to Co-CR. These need to be included.

2. As you shared your idea to my suggestion about the ‘MAPC Info’ field and the ‘Last MAPC Request’ field, we’d better to define per-scheme-defined MAPC Request sub-control field which can be further specified in each profile of MAPC schemes.

Then, as we already did, the ‘MAPC Info’ and the ‘Last MAPC Request’ fields are defined in the Co-RTWT profile to specify the 6-bits per-scheme-defined MAPC Request sub-control field.

3. A typical location of the Status code field (2 octets) is generally the main body of response management frames such as Association Response, Authentication frames etc. The Status Code field contains way more options, most of which are irrelevant to MAPC. For the MAPC element it is more efficient to simply encode the necessary response statuses within the MAPC Operation Type field. We can use 4 bits for MAPC Operation Type field and simply add the values for the responses: accept, reject, and alternate. We may not need 2 octets Status Code field only for this.

To assist your work, I am attaching the PDT document, which includes pointers to the suggested changes.

We would greatly appreciate it if you could consider these suggestions.

Regards,

Jonghoe

--------- Original Message ---------

Sender : 구종회 <jh89.koo@xxxxxxxxxxx> Connectivity표준Lab(SR)/삼성전자

Date : 2025-05-15 23:40 (GMT+9)

Title : Re: [STDS-802-11-TGBN] SP request (MAC) for MAPC (25/0599) and Co-RTWT (25/0600) PDTs

Hi Gionvanni,

Thanks for the response and feedback.

As you said, if you agree on my second suggestion regarding ‘MAPC Info field’ and ‘The Last MAPC Request field’, then please remove them from 25/599 (MAPC PDT) and incorporate them in 25/600.

The MAPC PDT would have contain only general and common descriptions for all MAPC schemes.

It may not be fair to describe exceptional statement in 25/599 below due only to one particular MAPC scheme, Co-RTWT.

The MAPC Info field is reserved except when carried in a Co-RTWT profile. The MAPC Info field in a Co-RTWT profile is defined in 9.4.2.aa3.2.5 (Co-RTWT profile).

The Last MAPC Request field is reserved except when carried in a Co-RTWT profile. The Last MAPC Request field in a Co-RTWT profile is defined in 9.4.2.aa3.2.5 (Co-RTWT profile).

Unfortunately, 25/600 (Co-RTWT PDT) has dependency on 25/599. The text in 25/600 below is given as the baseline texts coming from 25/599.

	MAPC Operation Type	MAPC Info	Last MAPC Request
Bits:	2	5	1

Figure 9-K4— MAPC Request Control field format

The MAPC Info field is reserved except when carried in a Co-RTWT profile. The MAPC Info field in a Co-RTWT profile is defined in 9.4.2.aa3.2.5 (Co-RTWT profile).

The Last MAPC Request field is reserved except when carried in a Co-RTWT profile. The Last MAPC Request field in a Co-RTWT profile is defined in 9.4.2.aa3.2.5 (Co-RTWT profile).

Regards,

Jonghoe KOO

Communications Standards Research Team, Samsung Research

Samsung Electronics

From: Giovanni Chisci <00002b657bbbbed7-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, May 15, 2025 10:18 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] SP request (MAC) for MAPC (25/0599) and Co-RTWT (25/0600) PDTs

Dear Jonghoe, and Rubayet,

Thanks for your comments even though, let me be frank, come in at the very last minute.

Technically I even think these are fair points for discussion, and I am happy to reply and discuss. I just wish they came a little earlier than yesterday late night since they would have been easily addressable. Please help in making the work easier going forward.

That said, let’s work together on 25/0599, and for the time being move forward 25/0600r13.

Comments inline.

Best,

Giovanni Chisci (QC)

From: Jonghoe Koo <jh89.koo@xxxxxxxxxxx>
Sent: Wednesday, May 14, 2025 4:25 PM
To: Giovanni Chisci <gchisci@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Cc: 'Rubayet Shafin' <r.shafin@xxxxxxxxxxx>
Subject: RE: [STDS-802-11-TGBN] SP request (MAC) for MAPC (25/0599) and Co-RTWT (25/0600) PDTs

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

Hi Giovanni and all,

Could I ask whether following comments on MAPC PDT can be considered or not?

1) Why do we allocate the additional 4 bits for 'MAPC Scheme type' instead of allocating the corresponding bits for the subelement IDs of the MAPC Scheme Info field?"

If we allocate Co-TDMA profile, Co-RTWT profile, Co-BF profile, Co-SR profile and Co-CR profile with the value of 0,1,2,3, and 4 for subelement ID in Table 9-K0, respectively, then we can save 4 bits in MAPC Scheme Control field. Even though there is a way for more efficient field formatting, is there any reason to waste more than 200 IDs for SubelementID?
I know we try to follow Multi-Link element format structure, however, we do not follow all the philosophy of designing Multi-Link element but only accept the essential part for designing MAPC Scheme Info field.

Received comments from @li.yan16@xxxxxxxxxx and implemented since it made sense. The change was reflected in 25/0599r4 (April 16) and seemed to be stable since then. That said I am open to revert this part to r3 as we had until April 15.

Also received a comment from @Mark Rison to use the same Subelement ID for subelements that have the same format, which is going to be our case (see Figure 9-K1, which also you leave unmodified in your proposed edits below). You may want to check with Mark too.

Table 9-K0— Optional subelement IDs of the MAPC Scheme Info field

*Subelement ID*	*Subelement name*	*Extensible*
1	Co-BF profile	Yes
1	Co-CR profile
2	Co-SR profile
3	Co-RTWT profile
4	Co-TDMA profile
5-220	Reserved
221	Vendor Specific	Vendor defined

222-253	Reserved
254	Fragment	No
255	Reserved

The format of the Per-Scheme Profile subelement is defined in Figure 9-K1 (Per-Scheme Profile subelement format).

	Subelement ID	Length	MAPC Scheme Control	MAPC Scheme Parameter Set	MAPC Scheme Request Set
Octets:	1	1	1	variable	variable

Figure 9-K1— Per-Scheme Profile subelement format

The format of the MAPC Scheme Control field is defined in Figure 9-K1b (MAPC Scheme Control field format).

	B0 B2	B3 B7
	~~MAPC Scheme Type~~	Reserved
Bits:	4	4

Figure 9-K1b— MAPC Scheme Control field format

The MAPC Scheme Type field indicates a value that identifies a MAPC scheme as defined in Table 9-K2 (MAPC Scheme Type field values).

Table 9-K2— ~~MAPC Scheme Type field values~~

*~~Value~~*	*~~Meaning~~*
0	~~Co-BF profile~~
1	~~Co-SR profile~~
2	~~Co-TDMA profile~~
3	~~Co-RTWT profile~~
~~4-15~~	~~Reserved~~

2) Deterministic 6 bits for ‘MAPC Info field and Last MAPC Request field in MAPC Request Control field’ and only having 2 bits for MAPC Operation Type are very bad for forward compatibility and not good for restricting any additional MAPC Operation Type in the future spec.

Currently, MAPC Info and Last MAPC Request field are only used by Co-RTWT. Then why we have to define those fields in general MAPC PDT?

I would suggest to have 2 bits MAPC Operation Type and 6 bits ‘Reserved’ or ‘TBD’ in order to make remaining 6 bits freely being used by other MAPC schemes.

[GC] perhaps we can define a subcontainer for the 6 MSBs of MAPC Request Control field format that is per-scheme-defined. This would allow us to have the current format for Co-RTWT and redefine the format for these 6 bits for the other schemes. Basically something similar to what you have below, debating whether reserving those 6 bits, or defining a per-scheme-defined 6-bits subfield is better.

If you really want to keep MAPC Info (frankly speaking, it is used for Co-RTWT ID) and Last MAPC Request, then we can define it in Co-RTWT PDT.

Please let all 6 bits freely being defined by other MAPC scheme and do not separately define 5-bit field and 1-bit field.

[GC] We can do something like this.

The MAPC Request Control field format is defined in Figure 9-K4 (MAPC Request Control field format).

	B0 B1	B2 B6	B7
	MAPC Operation Type	~~MAPC Info~~	~~Last MAPC Request~~
Bits:	2	5	1

Figure 9-K4— MAPC Request Control field format

The MAPC Info field is reserved except when carried in a Co-RTWT profile. The MAPC Info field in a Co-RTWT profile is defined in 9.4.2.aa3.2.5 (Co-RTWT profile).

The Last MAPC Request field is reserved except when carried in a Co-RTWT profile. The Last MAPC Request field in a Co-RTWT profile is defined in 9.4.2.aa3.2.5 (Co-RTWT profile).

Welcome to hear any feedback on my suggestion.

Regards,

Jonghoe KOO

Communications Standards Research Team, Samsung Research

Samsung Electronics

From: Giovanni Chisci <00002b657bbbbed7-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, May 14, 2025 5:31 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] SP request (MAC) for MAPC (25/0599) and Co-RTWT (25/0600) PDTs

MAC PDT: MAPC Signaling and Protocol Aspects]

[MAC PDT: Co-RTWT Signaling and Protocol Aspects]

Dear Alfred,

Could you please add the following motions to MAC motion list?

Motion 1:

Move to incorporate the proposed text changes in 11-25/0599r13 ‘PDT MAC MAPC Signaling and Protocol Aspects’, which resolves the following CIDs, to the latest TGbn draft.

CIDs list (28 CIDs): 148, 152, 153, 160, 161, 181, 669, 775, 1318, 1319, 1320, 1324, 1395, 1398, 1399, 1428, 1491, 1494, 1739, 1788, 1789, 2466, 3254, 3438, 3606, 3779, 3780, 3781

[SP result: 92Y, 24N, 47A]

Motion 2:

Move to incorporate the proposed text changes in 11-25/0600r13 ‘PDT MAC Co-RTWT Signaling and Protocol Aspects’, which resolves the following CIDs, to the latest TGbn draft.

CIDs list (76 CIDs): 202, 277, 439, 714, 742, 780, 781, 830, 832, 880, 901, 994, 1050, 1321, 1322, 1381, 1408, 1409, 1410, 1411, 1412, 1413, 1414, 1415, 1416, 1417, 1418, 1419, 1420, 1435, 1436, 1439, 1562, 1599, 1715, 1716, 1717, 1718, 1719, 1720, 1721, 1806, 1832, 1867, 1910, 2117, 2118, 2119, 2519, 2674, 3175, 3176, 3177, 3178, 3179, 3180, 3181, 3257, 3258, 3259, 3420, 3445, 3446, 3447, 3448, 3449, 3450, 3582, 3710, 3795, 3854, 3884 ,3885, 3886, 3887, 3888.

[SP result: 84Y, 21N, 43A]

To all, 25/0599r13 ad 25/0600r13 according to the agreed changes during TGbn session are uploaded on Mentor:

https://mentor.ieee.org/802.11/dcn/25/11-25-0599-13-00bn-pdt-mac-mapc-signaling-and-protocol-aspects.docx

https://mentor.ieee.org/802.11/dcn/25/11-25-0600-13-00bn-pdt-mac-co-rtwt-signaling-and-protocol-aspects.docx

Thanks to everyone that contributed for the great collaboration resulting in good progress for MAPC and Co-RTWT!

Best,

Giovanni

From: Giovanni Chisci <00002b657bbbbed7-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, May 12, 2025 1:28 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] SP request (MAC) for MAPC (25/0599) and Co-RTWT (25/0600) PDTs

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

Alfred,

One more version (r12) with small editorials.

Best,

Giovanni

https://mentor.ieee.org/802.11/dcn/25/11-25-0599-12-00bn-pdt-mac-mapc-signaling-and-protocol-aspects.docx

https://mentor.ieee.org/802.11/dcn/25/11-25-0600-12-00bn-pdt-mac-co-rtwt-signaling-and-protocol-aspects.docx

SP1: Do you agree to incorporate the proposed text changes in 11-25/0599r12 ‘PDT MAC MAPC Signaling and Protocol Aspects’, which resolves the following CIDs, to the latest TGbn draft?

CIDs list (29 CIDs): 148, 152, 153, 160, 161, 181, 669, 775, 1318, 1319, 1320, 1324, 1395, 1398, 1399, 1428, 1491, 1494, 1739, 1788, 1789, 2466, 3254, 3438, 3606, 3735, 3779, 3780, 3781

SP2: Do you agree to incorporate the proposed text changes in 11-25/0600r12 ‘PDT MAC Co-RTWT Signaling and Protocol Aspects’, which resolves the following CIDs, to the latest TGbn draft?

From: Giovanni Chisci <gchisci@xxxxxxxxxxxxxxxx>
Sent: Monday, May 12, 2025 12:06 PM
To: Giovanni Chisci <gchisci@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Cc: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Subject: RE: SP request (MAC) for MAPC (25/0599) and Co-RTWT (25/0600) PDTs

Dear Alfred,

Current version of PDTs is now r11 (minor edits, adjustment of some comment resolutions).

https://mentor.ieee.org/802.11/dcn/25/11-25-0599-11-00bn-pdt-mac-mapc-signaling-and-protocol-aspects.docx

https://mentor.ieee.org/802.11/dcn/25/11-25-0600-11-00bn-pdt-mac-co-rtwt-signaling-and-protocol-aspects.docx

Provided below updated SP text with resolved CIDs.

SP1: Do you agree to incorporate the proposed text changes in 11-25/0599r11 ‘PDT MAC MAPC Signaling and Protocol Aspects’, which resolves the following CIDs, to the latest TGbn draft?

CIDs list (29 CIDs): 148, 152, 153, 160, 161, 181, 669, 775, 1318, 1319, 1320, 1324, 1395, 1398, 1399, 1428, 1491, 1494, 1739, 1788, 1789, 2466, 3254, 3438, 3606, 3735, 3779, 3780, 3781

SP2: Do you agree to incorporate the proposed text changes in 11-25/0600r11 ‘PDT MAC Co-RTWT Signaling and Protocol Aspects’, which resolves the following CIDs, to the latest TGbn draft?

Best,

Giovanni

From: Giovanni Chisci <00002b657bbbbed7-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Friday, May 9, 2025 6:39 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] SP request (MAC) for MAPC (25/0599) and Co-RTWT (25/0600) PDTs

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

Dear Alfred,

PDTs for MAPC (25/0599r10) and Co-RTWT (25/0600r10) are now stable.

https://mentor.ieee.org/802.11/dcn/25/11-25-0599-10-00bn-pdt-mac-mapc-signaling-and-protocol-aspects.docx

https://mentor.ieee.org/802.11/dcn/25/11-25-0600-10-00bn-pdt-mac-co-rtwt-signaling-and-protocol-aspects.docx

Could you please help queueing SPs below for PDTs approval to the MAC queue?

SP1: Do you agree to incorporate the proposed text changes in 11-25/0599r10 ‘PDT MAC MAPC Signaling and Protocol Aspects’ to the latest TGbn draft (TGbn D0.2)?

SP2: Do you agree to incorporate the proposed text changes in 11-25/0600r10 ‘PDT MAC Co-RTWT Signaling and Protocol Aspects’ to the latest TGbn draft (TGbn D0.2)?

Best,

Giovanni

From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Sent: Friday, May 9, 2025 12:14 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] Another General Reminder

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

Hello all,

Another reminder is that it has been a while since we have transitioned to the drafting phase for TGbn, during which we are focusing on CR/PDT documents.

Hence, presentations of technical submissions has been de-prioritized, i.e., default allocation of agenda time will focus on the following cases:

- CR/PDT queue is empty and the pending SPs queue is empty

- Technical submission helps in converging on a specific subject related to a CID or TBD in the draft.

In view of the above, please note that while I am still keeping track of received submissions requests for technical submissions, it is highly encouraged that members follow the PDTs/CRs track which is aligned with the current phase of the TG.

Regards,

Alfred

On Fri, May 9, 2025 at 11:28 AM Alfred Asterjadhi <asterjadhi@xxxxxxxxx> wrote:

Hello all,

Please see some general reminders/suggestions in preparation for next week's F2F:

·        Please follow the guidelines (in particular item 6) and more specifically

a.    Please send all new (old ones already processed) submission requests to the reflector with "Submission Request - <DCN title> [total CIDs/TBDs resolved]
b.    For ease of identification, all submissions to begin with “PDT-TBDs” or “PDT-CRs”, and the topic classification (MAC/PHY/JOINT)” (e.g., 11-20-0999-00bn-PDT-TBDs-MAC-MLO-Power Save).
c.    Please share the submissions when ready via the reflector so that members can review and provide feedback in advance.
·        If you are a POC please make sure that the CIDs/TBDs in the subject you are a POC are appropriately resolved and if there are any issues or assistance is needed please let the TG leadership know so that we can help.
·        If there are any SPs that are needed in order to make progress on certain CIDs/TBDs, for which there are differences in opinion, please let me know so that we can dedicate some agenda time as early as possible (as default priority is given to CRs/PDTs that resolve CIDs and/or TBDs).
Please let me know if there are any questions and/or suggestions and looking forward to seeing you in Warsaw.

Regards,

Alfred

--
Alfred Asterjadhi, PhD

IEEE802.11 TGbe/TGbn Chair,

Qualcomm Technologies Inc.

asterjadhi@xxxxxxxxx

aasterja@xxxxxxxxxxxxxxxx

Cell #: +1 858 263 9445

Office #: +1 858 658 5302

Alfred Asterjadhi, PhD

IEEE802.11 TGbe/TGbn Chair,

Qualcomm Technologies Inc.

asterjadhi@xxxxxxxxx

aasterja@xxxxxxxxxxxxxxxx

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