Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Gaurang, Thanks a lot for the PDT document. Please find my comments in the following. 1) Regarding the Mode Tuple field, I don’t think 4 bits are enough for the Mode ID field. This enablement framework is generic and could be reused by future generations, but 16 Mode IDs can be exhausted quickly as we have already used 10
at this time. Including more bits in this Mode ID field would provide better forward compatibility and save the unnecessary efforts in defining sub-Mode IDs in the future. In fact, the Mode Length field is necessary only when the non-AP STA enables/updates
a mode with parameters, otherwise we don’t have to include it. Considering this, one way to optimize the Mode Tuple field is to use the following structure:
If a non-AP STA intends to disable a mode, or enable a mode without parameters, it will set Parameter Presence field to 0, and no Mode Length or Mode Parameter field will
be included; if it intends to enable or update a mode with parameters, it can set Parameter Presence to 1, and Mode Length will indicate the length of Mode Parameters field.
In such a way, when a non-AP STA doesn’t need to indicate parameters of the mode (i.e., when Mode Length is 0 or 15 in current design), it still uses 1 octet to indicate the enablement/disablement information. The benefits are: i) we have
6 bits for Mode ID which allows more modes to be enabled/disabled/updated under this framework; ii) no special rules for decoding Mode Length are required, and enablement/disablement is explicitly indicated with a dedicated bit. In addition, since the Mode
Length field is not in the first octet any more, we can consider allocating more bits to this field to address people’s concern on 4-bit length indication not being enough. 2) I see that Reconfiguration Operation Type equal to 5 is defined for UHR mode update, does it mean a UHR mode cannot be enabled simultaneously with link addition? I assume it would be helpful to reduce the overhead if a non-AP STA is
able to add link and enable some modes with a single frame. Maybe another type (e.g., 6) can be defined for a non-AP STA to add a link and enable modes on this link using the same Per-STA Profile. 3) The current version specifies that all fields in the STA Control fields other than Link ID and Reconfiguration Operation Type shall be set to 0. However, according to the baseline, if Complete Profile field of STA Control field in Reconfiguration
Multi-Link element is set to 0, the STA Profile field is not included. I assume we need to add an exceptional rule such that if the frame or Reconfig ML element is used for UHR mode update, STA Profile can be included with mode update info even if Complete
Profile is set to 0. 4) Regarding the discussion on whether EMLMR can be enabled/updated using the generic framework, I don’t have a strong preference, though it seems to me a cleaner approach that UHR non-AP STAs uses this framework for both EMLSR and EMLMR
enablement/update. Regards, Zhenpeng From: Gaurang Naik <0000305a2f8ce933-dmarc-request@xxxxxxxxxxxxxxxxx>
Hello all, Could you please use this thread to provide your feedback/comments on document 882r9? Thanks, Gaurang From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx> Hello all, 11-25/882r8 is
now on mentor. Thanks, Gaurang From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx> Hello all, 11-25/882r7 is
now on mentor. Thanks, Gaurang From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx> Hello all, Uploaded
11-25/882r6 based on received offline feedback. Thanks, Gaurang From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx> Hello all, I have uploaded a
rev5 of the document 882. This addresses feedback that I received during the teleconference and over email. It also now resolves the following CIDs:
Please let me know if you have any feedback or suggestions. Thanks, Gaurang From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx> Hi Alfred, Could you please queue 11-25/882, PDT on generic enablement, to the MAC queue? It resolves ~30 TBDs in D0.2. All, please review and let me know if you have any feedback. Thanks, Gaurang 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 |