| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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:
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.
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.
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
Attachment:
11-25-0599-13-00bn-pdt-mac-mapc-signaling-and-protocol-aspects-Samsung-Co-CR.docx
Description: Binary data