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

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

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
Please send all new (old ones already processed) submission requests to the reflector with "Submission Request - <DCN title> [total CIDs/TBDs resolved]
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).
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