Hi Jonghoe,
I'm sorry for missing your discussion on MAPC. Just one comment for clarification:
As you propose a new MAPC operation type (5, alternate), i'm wondering the use case for this type, such as :
1) AP1 requests for RTWT1/2/3, but AP2 informs that only RTWT1/2 is acceptable, so AP2 responses with MAPC operation type set to 5 and RTWT1/2 in the MAPC Request Parameter Set
2) AP1 requests for RTWT1, but AP2 informs that the adjusted/modified RTWT1 is acceptable, so AP2 reponses with MAPC operation type set to 5 and the adjusted/modified RTWT1
3) cases for other MAPC schemes except Co-RTWT
Basically i find most of your suggestions come from the TWT/RTWT formate design, do you think it's applicable for other schemes except Co-RTWT?
What's your thought on this?
Best Regards！
Yan Li
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]]
• 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>
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 |
|
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)
|
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?
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
The format of the Per-Scheme Profile subelement is defined in Figure 9-K1 (Per-Scheme Profile subelement format).
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).
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
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).
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.
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:
Thanks to everyone that contributed for the great collaboration resulting in good progress for MAPC and Co-RTWT!
Best, Giovanni
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
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
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